Używanie protokołu Remote Desktop Protocol (RDP) do logowania się na serwerze Windows

Remote Desktop Protocol (RDP) to zastrzeżony protokół sieciowy firmy Microsoft, który umożliwia zaszyfrowany, pełny graficzny dostęp do zdalnej maszyny z systemem Windows przez port TCP 3389. Przesyła dane wyjściowe wyświetlacza z serwera do klienta oraz dane wejściowe klawiatury/myszy od klienta z powrotem do serwera, zapewniając w efekcie aktywną, interaktywną sesję na maszynie, przy której fizycznie nie jesteś obecny.

Dla administratorów serwerów RDP jest podstawową metodą zarządzania instancją Windows Server — niezależnie od tego, czy serwer jest maszyną bare-metal w centrum danych, środowiskiem VPS Hosting, czy Serwerem Dedykowanym z systemem Windows Server 2019, 2022 lub nowszym. Ten przewodnik obejmuje kompletny przepływ pracy: włączanie RDP, zabezpieczanie go przed rzeczywistymi wektorami ataków, łączenie się z systemów Windows, macOS i Linux oraz diagnozowanie błędów, które zaskakują administratorów.

Jak działa RDP od środka

Zanim zmienisz jakiekolwiek ustawienie konfiguracyjne, zrozumienie architektury protokołu przyniesie korzyści podczas rozwiązywania problemów.

RDP działa przez TCP (i opcjonalnie UDP do przekierowania multimediów) i używa TLS 1.2/1.3 do szyfrowania transportu we wszystkich nowoczesnych wydaniach Windows Server. Stos sesji składa się z kilku kanałów wirtualnych, które jednocześnie przenoszą różne typy danych:

• Kanał graficzny — skompresowane aktualizacje wyświetlacza przy użyciu akceleracji RemoteFX lub GDI
• Kanał wejściowy — zdarzenia klawiatury i myszy
• Kanał schowka — dwukierunkowe udostępnianie schowka
• Kanały przekierowania dysków/drukarek — mapowanie zasobów lokalnych do sesji zdalnej
• Kanał audio — przekierowanie zdalnego odtwarzania i nagrywania dźwięku

Każdy kanał jest multipleksowany przez jedno połączenie TCP do portu 3389 domyślnie. Komponent po stronie serwera to TermService (Remote Desktop Services), a nasłuchiwaniem zarządza RDPWinST.sys na poziomie jądra. Gdy zmieniasz port nasłuchiwania, modyfikujesz wartość rejestru, którą ten sterownik odczytuje podczas uruchamiania usługi.

Network Level Authentication (NLA) dodaje warstwę uwierzytelniania przed sesją przy użyciu CredSSP (Credential Security Support Provider). Gdy NLA jest włączone, klient musi uwierzytelnić się przy użyciu prawidłowych poświadczeń, zanim serwer przydzieli pełną sesję pulpitu, co znacznie zmniejsza powierzchnię ataku dla ataków typu denial-of-service i brute-force na ekran logowania.

Lista wymagań wstępnych

Przed próbą nawiązania połączenia potwierdź każdy z poniższych punktów:

• Instancja Windows Server (2016, 2019 lub 2022) z włączonym RDP
• Publiczny adres IPv4 lub rozwiązywalna nazwa hosta serwera
• Prawidłowe konto na poziomie administratora na serwerze
• Klient RDP zainstalowany na komputerze lokalnym
• Port 3389 (lub niestandardowy port) otwarty zarówno w zaporze systemu operacyjnego, jak i w każdej nadrzędnej zaporze sieciowej lub grupie zabezpieczeń
• Obsługa NLA po stronie klienta (domyślnie włączona we wszystkich nowoczesnych klientach RDP dla Windows, macOS i Linux)

Krok 1: Włącz RDP na Windows Server

RDP jest domyślnie wyłączone na świeżych instalacjach Windows Server. Istnieją dwie niezawodne metody jego włączenia.

Metoda A: GUI (Właściwości systemu)

1. Otwórz Menedżer serwera lub naciśnij Win + R, wpisz sysdm.cpl i naciśnij Enter.
2. Przejdź do zakładki Zdalny.
3. W sekcji Pulpit zdalny wybierz Zezwalaj na zdalne połączenia z tym komputerem.
4. Upewnij się, że zaznaczona jest opcja Zezwalaj na połączenia tylko z komputerów z uruchomionym Pulpitem zdalnym z uwierzytelnianiem na poziomie sieci.
5. Kliknij OK.

Metoda B: PowerShell (preferowana do automatyzacji)

W przypadku wdrożeń bezgłowych lub skryptowych PowerShell jest szybszy i umożliwia tworzenie skryptów:

# Enable RDP
Set-ItemProperty -Path 'HKLM:SystemCurrentControlSetControlTerminal Server' `
    -Name "fDenyTSConnections" -Value 0

# Enable NLA
Set-ItemProperty -Path 'HKLM:SystemCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp' `
    -Name "UserAuthentication" -Value 1

# Allow RDP through Windows Firewall
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

# Confirm the service is running
Set-Service -Name TermService -StartupType Automatic
Start-Service TermService

Weryfikacja reguły zapory

Wbudowana grupa reguł zapory „Pulpit zdalny” obejmuje niezbędne reguły ruchu przychodzącego. Zweryfikuj za pomocą:

Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object DisplayName, Enabled, Direction

Jeśli korzystasz z grupy zabezpieczeń dostawcy chmury (powszechne w środowiskach VPS z cPanel lub zarządzanych VPS), musisz również otworzyć port 3389 w zewnętrznym panelu zapory dostawcy — sama zapora systemu operacyjnego nie jest wystarczająca.

Krok 2: Znajdź publiczny adres IP serwera

Z konsoli serwera

Otwórz wiersz polecenia z podwyższonymi uprawnieniami i uruchom:

ipconfig /all

Poszukaj adresu IPv4 pod aktywną kartą sieciową. Na serwerze z wieloma kartami sieciowymi (powszechne na sprzęcie dedykowanym) zidentyfikuj kartę podłączoną do sieci publicznej, odwołując się do domyślnej bramy.

Aby uzyskać bardziej przejrzyste dane wyjściowe, użyj PowerShell:

Get-NetIPAddress -AddressFamily IPv4 | Where-Object { $_.IPAddress -notlike "127.*" } |
    Select-Object InterfaceAlias, IPAddress

Z panelu kontrolnego hostingu

Jeśli serwer został udostępniony przez dostawcę hostingu, publiczny adres IP jest wymieniony w panelu kontrolnym. W przypadku Serwerów Dedykowanych AlexHost adres IP jest wyświetlany natychmiast po udostępnieniu w obszarze klienta.

Ważny przypadek brzegowy: Jeśli serwer znajduje się za NAT (np. prywatna chmura lub hiperwizor z siecią wewnętrzną), adres IP wyświetlany przez ipconfig będzie prywatnym adresem RFC 1918. Będziesz musiał połączyć się z publicznym adresem IP bramy NAT i skonfigurować przekierowanie portów na prywatny adres IP serwera na porcie 3389.

Krok 3: Połącz się z serwerem przez RDP

Z systemu Windows

Wbudowany klient to mstsc.exe (Microsoft Terminal Services Client). Uruchom go z okna Uruchom (Win + R) lub menu Start:

mstsc /v:YOUR_SERVER_IP:3389

Dla sesji pełnoekranowej z wyłączonym przekierowaniem dysków (domyślne ustawienie uwzględniające bezpieczeństwo):

mstsc /v:YOUR_SERVER_IP /f /nodrives

W GUI:

1. Wprowadź adres IP serwera w polu Komputer.
2. Kliknij Pokaż opcje, aby wstępnie wypełnić nazwę użytkownika, co pozwala uniknąć dodatkowego monitu o poświadczenia.
3. W zakładce Środowisko wybierz odpowiednią prędkość połączenia, aby zoptymalizować renderowanie.
4. Kliknij Połącz, zaakceptuj ostrzeżenie o certyfikacie przy pierwszym połączeniu (zweryfikuj odcisk palca certyfikatu, jeśli bezpieczeństwo jest krytyczne) i wprowadź hasło.

Z systemu macOS

Oficjalna aplikacja Microsoft Microsoft Remote Desktop (dostępna bezpłatnie w Mac App Store) jest zalecanym klientem.

1. Otwórz aplikację i kliknij przycisk +, a następnie Dodaj komputer.
2. Wprowadź adres IP serwera w polu Nazwa komputera.
3. W sekcji Konto użytkownika kliknij Dodaj konto użytkownika i wprowadź swoje poświadczenia.
4. Opcjonalnie skonfiguruj ustawienia Wyświetlacza i przekierowania Urządzeń i dźwięku.
5. Kliknij dwukrotnie zapisane połączenie, aby zainicjować sesję.

Z systemu Linux

W systemie Linux dostępne są dwie dojrzałe opcje:

Remmina (oparta na GTK, zalecana dla środowisk graficznych):

sudo apt install remmina remmina-plugin-rdp   # Debian/Ubuntu
sudo dnf install remmina remmina-plugin-rdp   # RHEL/Fedora

Uruchom Reminę, utwórz nowe połączenie, wybierz RDP jako protokół, wprowadź adres IP serwera, poświadczenia i połącz się.

FreeRDP (wiersz poleceń, idealny do skryptów lub klientów bezgłowych):

sudo apt install freerdp2-x11
xfreerdp /v:YOUR_SERVER_IP /u:Administrator /p:'YourPassword' /cert:ignore /dynamic-resolution

Flaga /cert:ignore pomija ostrzeżenie o certyfikacie — dopuszczalne w kontrolowanym środowisku, ale w środowisku produkcyjnym należy zastąpić ją właściwym przypinaniem certyfikatów.

Porównanie klientów RDP

Krok 4: Zabezpieczanie RDP przed rzeczywistymi zagrożeniami

RDP jest jedną z najaktywniej atakowanych usług w internecie. Shodan konsekwentnie indeksuje miliony narażonych punktów końcowych RDP, a zautomatyzowane kampanie brute-force działają 24/7. Poniższe środki nie są opcjonalne dla żadnego serwera produkcyjnego.

Zmień domyślny port nasłuchiwania

Zmiana z 3389 na niestandardowy port eliminuje zdecydowaną większość automatycznych skanerów. Edytuj rejestr:

$newPort = 54321  # Replace with your chosen port
Set-ItemProperty -Path 'HKLM:SystemCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp' `
    -Name "PortNumber" -Value $newPort -Type DWord

# Update firewall rule
New-NetFirewallRule -DisplayName "RDP Custom Port" -Direction Inbound `
    -Protocol TCP -LocalPort $newPort -Action Allow

# Disable the default rule
Disable-NetFirewallRule -DisplayName "Remote Desktop - User Mode (TCP-In)"

Restart-Service TermService

Pamiętaj, aby zaktualizować grupę zabezpieczeń chmury, aby zezwolić na nowy port i zablokować 3389.

Ogranicz dostęp według adresu IP

Jeśli Twoja stacja robocza administratora ma statyczny adres IP, ogranicz RDP tylko do tego adresu IP:

Set-NetFirewallRule -DisplayName "RDP Custom Port" `
    -RemoteAddress "YOUR_ADMIN_IP"

Wymuszaj zasady blokady konta

Zapobiegaj atakom brute-force, konfigurując próg blokady konta. W zasadach grupy (gpedit.msc):

• Próg blokady konta: 5 nieprawidłowych prób
• Czas trwania blokady konta: 30 minut
• Resetuj licznik blokady konta po: 15 minutach

Lub przez PowerShell:

net accounts /lockoutthreshold:5 /lockoutduration:30 /lockoutwindow:15

Wdróż VPN lub tunel SSH jako bramę

Najbardziej niezawodnym podejściem jest nieudostępnianie RDP w publicznym internecie w ogóle. Umieść RDP za VPN (WireGuard lub OpenVPN) lub tunelem SSH. Administratorzy najpierw łączą się z VPN, a następnie przez RDP z prywatnym adresem IP serwera. Całkowicie eliminuje to powierzchnię ataku.

Włącz Windows Defender Credential Guard

W systemie Windows Server 2016 i nowszych Credential Guard izoluje skróty poświadczeń w enklawie zabezpieczeń opartej na wirtualizacji, zapobiegając atakom pass-the-hash, które mogą być przeprowadzane z przejętej sesji RDP.

Audytuj i rejestruj sesje RDP

Włącz audytowanie przez zasady grupy w sekcji Konfiguracja komputera > Ustawienia systemu Windows > Ustawienia zabezpieczeń > Zaawansowana konfiguracja zasad inspekcji > Logowanie/Wylogowanie. Rejestruj zarówno zdarzenia pomyślne, jak i nieudane. Przekazuj dzienniki do SIEM lub przynajmniej regularnie przeglądaj Event ID 4624 (pomyślne logowanie) i Event ID 4625 (nieudane logowanie) w Podglądzie zdarzeń.

Krok 5: Rozwiązywanie typowych błędów połączenia RDP

Odmowa połączenia (kod błędu 0x204 / „Nie można osiągnąć komputera zdalnego”)

Jest to prawie zawsze problem z zaporą lub routingiem.

# Test from the client machine (replace with your server IP and port)
Test-NetConnection -ComputerName YOUR_SERVER_IP -Port 3389

Jeśli TcpTestSucceeded zwraca False, port jest zablokowany. Sprawdź:

1. Zaporę systemu operacyjnego na serwerze (Get-NetFirewallRule -DisplayGroup "Remote Desktop")
2. Grupę zabezpieczeń lub ACL dostawcy chmury
3. Wszelkie pośrednie zapory sprzętowe między klientem a serwerem

Błąd uwierzytelniania („Wystąpił błąd uwierzytelniania. Żądana funkcja nie jest obsługiwana.”)

Zazwyczaj oznacza to, że klient nie obsługuje wersji Credential Security Support Provider (CredSSP) wymaganej przez serwer, co często pojawia się po aktualizacji zabezpieczeń systemu Windows (poprawka CVE-2018-0886). Napraw na serwerze:

# Temporary workaround — update the client instead when possible
Set-ItemProperty -Path 'HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters' `
    -Name "AllowEncryptionOracle" -Value 2 -Type DWord

Trwałą poprawką jest aktualizacja klienta RDP do poprawionej wersji obsługującej zaktualizowany protokół CredSSP.

„Sesja zdalna została rozłączona, ponieważ nie są dostępne żadne serwery licencji Pulpitu zdalnego”

Dzieje się tak, gdy rola Remote Desktop Session Host (RDSH) jest zainstalowana na serwerze, ale nie skonfigurowano serwera licencji RD. W przypadku prostego dostępu administracyjnego (nie wdrożeń RDSH dla wielu użytkowników) usuń rolę RDSH lub skonfiguruj 120-dniowy okres karencji:

# Check licensing mode
(Get-WmiObject -Namespace root/CIMV2/TerminalServices -Class Win32_TerminalServiceSetting).LicensingType

Wartość 2 oznacza Na urządzenie, 4 oznacza Na użytkownika. W przypadku dostępu tylko dla administratorów wartość powinna wynosić 5 (nieskonfigurowane / okres karencji).

Czarny ekran po zalogowaniu

Czarny ekran podczas połączenia RDP zazwyczaj wskazuje na jedną z trzech przyczyn:

• Awaria Explorer.exe: Naciśnij Ctrl + Alt + End, aby otworzyć Menedżera zadań, a następnie uruchom explorer.exe z menu Plik > Uruchom nowe zadanie.
• Konflikt sterownika wyświetlacza: Wyłącz akcelerację sprzętową w sesji RDP przez zasady grupy.
• Problem z zdalnym GPU: Na serwerach z dedykowanymi GPU (dotyczy obciążeń GPU Hosting) upewnij się, że adapter RemoteFX vGPU jest prawidłowo skonfigurowany.

Wolna lub opóźniona sesja RDP

Zoptymalizuj wydajność, dostosowując ustawienia środowiska połączenia w mstsc:

mstsc /v:YOUR_SERVER_IP /f

W zakładce Środowisko wybierz LAN (10 Mbps lub szybciej) i wyłącz Tło pulpitu, Wygładzanie czcionek i Kompozycję pulpitu, aby uzyskać maksymalną responsywność przy połączeniach o dużych opóźnieniach.

RDP a alternatywne protokoły zdalnego dostępu

W przypadku administracji Windows Server RDP pozostaje najlepszym wyborem pod względem wydajności, natywnej integracji i głębokości funkcji. SSH jest preferowanym protokołem dla środowisk VPS Hosting opartych na systemie Linux.

Zarządzanie wieloma sesjami RDP i zapisanymi poświadczeniami

Zapisywanie plików połączeń RDP

mstsc obsługuje pliki konfiguracyjne .rdp, które są plikami tekstowymi, które można kontrolować wersją:

full address:s:YOUR_SERVER_IP:3389
username:s:Administrator
prompt for credentials:i:1
audiomode:i:0
redirectdrives:i:0
redirectclipboard:i:1

Zapisz jako server.rdp i kliknij dwukrotnie, aby uruchomić, lub wywołaj przez:

mstsc server.rdp

Menedżer poświadczeń

W systemie Windows zapisane poświadczenia RDP są przechowywane w Menedżerze poświadczeń (control keymgr.dll). W przypadku zautomatyzowanych skryptów lub potoków CI/CD wymagających dostępu RDP użyj narzędzia cmdkey:

cmdkey /generic:YOUR_SERVER_IP /user:Administrator /pass:YourPassword
mstsc /v:YOUR_SERVER_IP
cmdkey /delete:YOUR_SERVER_IP

Usuń poświadczenia natychmiast po użyciu, aby uniknąć trwałego narażenia poświadczeń.

Praktyczna lista kontrolna kluczowych wniosków

Użyj jej jako macierzy weryfikacyjnej przed wdrożeniem i po incydencie:

Konfiguracja początkowa

• RDP włączone przez fDenyTSConnections = 0 w rejestrze
• NLA wymuszone (UserAuthentication = 1)
• TermService ustawione na Automatyczny i uruchomione
• Reguła zapory aktywna dla właściwego portu

Sieć i kontrola dostępu

• Domyślny port 3389 zmieniony na niestandardowy port
• Grupa zabezpieczeń chmury zaktualizowana w celu odzwierciedlenia nowego portu
• Lista dozwolonych adresów IP skonfigurowana w regule zapory
• RDP nieudostępnione bezpośrednio w internecie (preferowana brama VPN)

Uwierzytelnianie i wzmacnianie zabezpieczeń

• Skonfigurowane zasady blokady konta (5 prób / 30-minutowa blokada)
• Silne, unikalne hasło dla wszystkich kont z dostępem RDP
• Credential Guard włączony w systemie Windows Server 2016+
• Dostęp RDP ograniczony do wbudowanej grupy Administratorzy lub dedykowanej grupy RDP

Monitorowanie

• Zasady audytu włączone dla zdarzeń logowania/wylogowania
• Alerty Event ID 4625 skonfigurowane dla powtarzających się błędów
• Dzienniki sesji przeglądane okresowo lub przekazywane do SIEM

Po stronie klienta

• Klient RDP zaktualizowany do najnowszej wersji
• Pliki .rdp przechowywane bezpiecznie i niezatwierdzane do publicznych repozytoriów
• Zapisane poświadczenia w Menedżerze poświadczeń regularnie przeglądane i usuwane

Często zadawane pytania

Jakiego portu używa RDP i czy można go zmienić?

RDP domyślnie nasłuchuje na porcie TCP 3389. Możesz go zmienić, modyfikując wartość DWORD PortNumber w kluczu HKLM:SystemCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp i restartując usługę TermService. Zaktualizuj reguły zapory, aby były zgodne.

Czym jest Network Level Authentication (NLA) i czy powinno być zawsze włączone?

NLA wymaga od klienta uwierzytelnienia przez CredSSP przed utworzeniem przez serwer pełnej sesji pulpitu. Zapobiega to dotarciu nieuwierzytelnionych użytkowników do ekranu logowania systemu Windows, znacznie zmniejszając narażenie na ataki credential-stuffing i denial-of-service. Powinno być zawsze włączone na serwerach produkcyjnych, chyba że istnieje konkretny wymóg zgodności ze starszym klientem.

Dlaczego moje połączenie RDP rozłącza się po okresie bezczynności?

Limity czasu sesji są kontrolowane przez zasady grupy w sekcji Konfiguracja komputera > Szablony administracyjne > Składniki systemu Windows > Usługi pulpitu zdalnego > Host sesji pulpitu zdalnego > Limity czasu sesji. Odpowiednie zasady to Ustaw limit czasu dla rozłączonych sesji i Ustaw limit czasu dla aktywnych, ale bezczynnych sesji Usług pulpitu zdalnego. Ustaw je zgodnie z wymaganiami operacyjnymi, zamiast pozostawiać wartości domyślne.

Czy wielu użytkowników może jednocześnie łączyć się z Windows Server przez RDP?

Standardowa instalacja Windows Server obsługuje dwie jednoczesne administracyjne sesje RDP. W przypadku większej liczby jednoczesnych użytkowników potrzebna jest rola Remote Desktop Session Host (RDSH) i ważne licencje dostępu klienta Usług pulpitu zdalnego (RDS CAL). Bez odpowiedniego licencjonowania serwer wchodzi w 120-dniowy okres karencji, po którym odmawia połączeń.

Czy bezpieczne jest bezpośrednie udostępnianie RDP w publicznym internecie?

Nie. Bezpośrednie udostępnianie RDP na porcie 3389 w internecie naraża na zautomatyzowane ataki brute-force, kampanie dostarczania ransomware (RDP jest wiodącym wektorem początkowego dostępu dla ransomware) oraz wykorzystywanie niezałatanych luk. Zawsze umieszczaj RDP za VPN, ogranicz dostęp według adresu IP, zmień domyślny port i wymuszaj NLA oraz zasady blokady konta jako minimalne podstawowe zabezpieczenia.