RDP-Port: 3389 über TCP und UDP, die RD-Gateway-Ports und wie du sie prüfst

Kurz gesagt: Remotedesktop (RDP) hört standardmäßig auf TCP-Port 3389, und auf aktuellen Windows-Versionen zusätzlich auf UDP-Port 3389. TCP ist Pflicht; UDP ist ein optionaler, schnellerer Transport, und ist er blockiert, bleibt RDP einfach bei TCP. Ein RD-Gateway, falls du eines betreibst, nutzt stattdessen TCP 443 und UDP 3391 – sonst braucht ein Client nichts (weder 135, 139 noch 445), um einen Server zu erreichen.

Die IANA listet 3389 unter dem Dienstnamen ms-wbt-server für TCP und UDP, weshalb Tools wie nc und Nmap diesen Namen statt „RDP“ ausgeben. Die Zahl ist nur der Standardwert: Ein Administrator kann sie ändern, und dann muss jeder Client den neuen Port angeben. Hier geht es darum, welche Ports im Spiel sind, wie du sie prüfst und wie du sie absicherst.

Läuft RDP über TCP oder über UDP?

Über beide, in fester Reihenfolge. Der Client öffnet immer zuerst TCP 3389. Über diese Verbindung bietet der Server einen zweiten Transport über UDP an, mit TLS oder DTLS gesichert, und sobald das UDP-Handshake klappt, wandert der Großteil des Traffics – vor allem die Bildschirmaktualisierungen – auf UDP, während die TCP-Verbindung offen bleibt. Das hat zwei praktische Folgen:

• UDP 3389 blockieren – RDP funktioniert trotzdem. Es fällt einfach auf TCP zurück, was auf verlustreichem WLAN oder Mobilfunk langsamer wirkt, sonst aber identisch ist.
• TCP 3389 blockieren – nichts funktioniert mehr. UDP allein kann keine Sitzung starten, eine Firewall-Regel nur für UDP bringt also nichts.

Der UDP-Transport kam mit RDP 8.0 in Windows 8 und Windows Server 2012 (Windows 7 SP1 bekam ihn per Update). Auf aktuellen Windows-Server- und Windows-Client-Versionen ist er standardmäßig auf beiden Seiten an. Eine Gruppenrichtlinie kann ihn abschalten: auf dem Server ist das „RDP-Transportprotokolle auswählen“ unter Computerkonfiguration → Administrative Vorlagen → Windows-Komponenten → Remotedesktopdienste → Remotedesktop-Sitzungshost → Verbindungen.

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' -Name SelectTransport -ErrorAction SilentlyContinue

Keine Ausgabe bedeutet, die Richtlinie ist nicht gesetzt und UDP ist erlaubt. SelectTransport : 1 erzwingt „Nur TCP verwenden“ (0 und 2 erlauben UDP). Auch ein Client kann UDP selbst ablehnen: Die Clientrichtlinie „UDP auf dem Client deaktivieren“ setzt fClientDisableUDP. Auf dem Server protokolliert jede angenommene Verbindung ihren Transport und die Adresse des Clients:

Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational'; Id = 131 } -MaxEvents 10 |
    Format-List TimeCreated, Message

Welche Ports braucht RDP nicht?

Viele „RDP-Port“-Listen führen zusätzlich TCP 135, 139 und 445 für die Weiterleitung von Druckern und Laufwerken an. So funktioniert die Weiterleitung aber nicht: Laufwerke, Drucker, Zwischenablage, Audio und Smartcards laufen als virtuelle Kanäle innerhalb der RDP-Verbindung auf 3389, ein Client mit nur 3389 erreicht also alle davon. Die RPC- und SMB-Ports gehören zum Traffic zwischen den Servern einer kompletten Remotedesktopdienste-Farm – auf einem einzelnen Windows-Server, den du von zu Hause erreichst, öffnen sie nur SMB und RPC ins Internet, was du nie willst.

Dasselbe gilt für ICMP: Ping ist praktisch zur Diagnose, aber RDP nutzt es nicht, und ein Server, der Ping ignoriert, kann trotzdem Remotedesktop-Verbindungen annehmen.

Wie finde ich heraus, auf welchem Port RDP lauscht?

Die Registry hält den konfigurierten Port, die Socket-Tabelle zeigt, was gerade wirklich lauscht. Prüfe beides, in der Konsole oder in einer bereits offenen RDP-Sitzung:

# der konfigurierte Port (eine Dezimalzahl)
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber

# was wirklich lauscht, TCP und UDP
Get-NetTCPConnection -LocalPort 3389 -State Listen
Get-NetUDPEndpoint -LocalPort 3389

Zeigt PortNumber einen anderen Wert, nutze diese Zahl in den nächsten beiden Befehlen. Widersprechen sich Registry und Socket-Tabelle, wurde der Port geändert, aber die Remotedesktopdienste wurden noch nicht neu gestartet – die Socket-Tabelle zeigt, was Clients tatsächlich erreicht. Keine TCP-Zeile bedeutet, Remotedesktop ist aus oder sein Dienst läuft nicht.

netstat -ano | findstr :3389
tasklist /svc /fi "SERVICES eq TermService"

Die letzte Spalte von netstat ist die Prozess-ID, und tasklist bestätigt, dass sie zu TermService gehört, dem Dienst der Remotedesktopdienste, der in einem svchost.exe-Prozess läuft. Dann prüfe, welche Ports die Firewall tatsächlich durchlässt:

Get-NetFirewallRule -DisplayGroup "Remote Desktop" |
    Where-Object Enabled -eq True |
    Get-NetFirewallPortFilter |
    Format-Table Protocol, LocalPort

Wie teste ich den RDP-Port von außen?

Ein Port, der auf dem Server lauscht, kann unterwegs trotzdem blockiert sein. Teste von deinem eigenen Rechner, YOUR_SERVER_IP durch die öffentliche Adresse des Servers ersetzt und 3389 durch seinen Port:

Test-NetConnection YOUR_SERVER_IP -Port 3389
# Kurzform, nur für 3389:
Test-NetConnection YOUR_SERVER_IP -CommonTCPPort RDP

nc -vz -G 5 YOUR_SERVER_IP 3389

nc -vz -w 5 YOUR_SERVER_IP 3389

• TcpTestSucceeded : True, oder eine nc-Zeile, die mit [tcp/ms-wbt-server] succeeded! endet: Der Weg ist offen. Scheitert der Login trotzdem, liegt es an Zugangsdaten, NLA oder dem Client.
• Connection refused (nc antwortet sofort): Der Server hat geantwortet, aber auf diesem Port lauscht niemand. Remotedesktop ist aus, während die Firewall-Regel noch offen ist, oder er lauscht auf einem anderen Port.
• Timed out (nc wartet die vollen fünf Sekunden): Irgendetwas verwirft die Pakete. Das ist eine Firewall auf dem Server oder beim Provider, eine falsche IP, oder dein eigenes Netzwerk blockiert ausgehend Port 3389 – in Hotels und Firmennetzwerken häufig.

Ohne Terminal testet der Open-Port-Checker (engl.) denselben TCP-Test von unserem Server in Amsterdam aus gegen jede öffentliche IP-Adresse (keinen Hostnamen) und jeden Port. Keines dieser Werkzeuge kann einen offenen UDP-Port beweisen: UDP hat kein Handshake, Stille sieht also gleich aus, egal ob der Port offen oder gefiltert ist. Bei einem fehlgeschlagenen Test und einer vollständigen Checkliste hilft Remotedesktop verbindet sich nicht (engl.) der Reihe nach weiter.

Wie verbinde ich mich mit einem nicht standardmäßigen Port?

Jeder Client nimmt den Port nach der Adresse, durch einen Doppelpunkt getrennt. Ohne Angabe versucht der Client 3389.

mstsc /v:YOUR_SERVER_IP:13389

# Debian 12: xfreerdp (FreeRDP 2) · Debian 13, Ubuntu 24.04: xfreerdp3
xfreerdp3 /v:YOUR_SERVER_IP:13389 /u:Administrator

• Remotedesktopverbindung (Windows): gib YOUR_SERVER_IP:13389 im Feld „Computer“ ein. Eine gespeicherte .rdp-Datei hält das als full address:s:YOUR_SERVER_IP:13389 fest.
• macOS, iPhone, iPad, Android: Microsofts Windows App, die Microsoft Remote Desktop abgelöst hat. + → Add PC wählen und YOUR_SERVER_IP:13389 als PC-Namen eingeben.
• Remmina (Linux): neues RDP-Profil, Server YOUR_SERVER_IP:13389.
• IPv6: die Adresse in eckige Klammern setzen, [2001:db8::10]:13389, damit die Doppelpunkte der Adresse nicht als Port-Trennzeichen gelesen werden.

Port 3389 auf deine eigene IP beschränken

Ein offener 3389 wird schnell von Scannern gefunden, die das gesamte Internet durchsuchen, und bekommt danach rund um die Uhr Passwort-Rateversuche. Die wirksamste Maßnahme ist, nur deine eigenen Adressen durchzulassen. Deine aktuelle öffentliche Adresse zeigt das Tool Meine IP-Adresse (engl.).

# durch deine eigene Adresse ersetzen; Bereiche wie 192.0.2.0/24 funktionieren auch
Set-NetFirewallRule -DisplayGroup "Remote Desktop" -RemoteAddress YOUR_IP

# Ergebnis prüfen
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Get-NetFirewallAddressFilter |
    Format-Table RemoteAddress

Das engt beide eingebauten Regeln gemeinsam ein, TCP und UDP. Zwei Dinge können das unbemerkt aufheben: eine zweite Regel, die denselben Port für alle öffnet, und eine separate Blockier-Regel, die in der Windows-Firewall jede Freigabe-Regel übertrumpft – auch deine. Engere die Freigabe-Regel ein, füge keine zusätzliche Blockier-Regel hinzu.

Macht die Portänderung RDP sicher?

Nein. Ein anderer Port bringt dich nur aus dem Blickfeld der faulsten Bots, und das Log wird ruhiger. Ein Scan aller 65.535 Ports findet den lauschenden Socket trotzdem und erkennt ihn als RDP, und ein schwaches Passwort ist auf Port 13389 genauso schwach. Was einen RDP-Server wirklich schützt:

• Eine Allowlist für Quelladressen, wie oben. Sie nimmt das Raten von Passwörtern von fremden Adressen komplett aus dem Spiel.
• Gar kein öffentlicher Port. Erreiche RDP über ein VPN oder einen SSH-Tunnel zu 127.0.0.1:3389 auf dem Server, oder über ein RD-Gateway auf 443, und schließe 3389 nach außen.
• Netzwerkebenenauthentifizierung (NLA) an. Sie ist standardmäßig an und lässt den Client sich authentifizieren, bevor Windows einen Anmeldebildschirm aufbaut.
• Eine Kontosperrrichtlinie. net accounts zeigt die aktuellen Werte. Installationen mit den Updates von Oktober 2022 oder neuer sperren ein Konto schon nach 10 Fehlversuchen für 10 Minuten; falls nicht, setze es mit net accounts /lockoutthreshold:10 /lockoutwindow:10 /lockoutduration:10.
• Updates. Mehrere ernste RDP-Lücken brauchten gar kein Passwort: BlueKeep (CVE-2019-0708) ließ jeden, der 3389 erreichte, Code auf ungepatchten Windows 7- und Server-2008-R2-Maschinen ausführen.

Protokollierung, Zertifikate und der Rest der Absicherung stehen in wie du einen Windows-RDP-Server absicherst (engl.).

Wenn du einen Windows-Server willst, bei dem du das alles selbst einstellst, gibt dir ein Windows VPS das Administrator-Konto mit Remotedesktop auf dem Standardport 3389, und die Windows-RDP-Tarife laufen in Amsterdam (RDP Niederlande) und Frankfurt (RDP Deutschland), mit einer VNC-Konsole im Panel für den Moment, in dem eine Firewall-Regel danebengeht.

Häufige Fragen