Auf welchen Port sollte ich RDP verlegen?

Auf einen beliebigen freien über 10000 — 34519, 47820, was frei ist. Meiden Sie Ports bekannter Dienste, da Scanner genau die gezielt prüfen, und meiden Sie 3390, das Erste, was jeder nach 3389 probiert. Prüfen Sie vorher mit Get-NetTCPConnection, dass dort nichts lauscht.

Bricht ein geänderter RDP-Port Remote-Desktop-Clients?

Nein, aber jeder Client muss den Port nun nennen: server:34519 im Computerfeld oder mstsc /v:server:34519. Gespeicherte .rdp-Dateien und Verbindungsmanager behalten den alten Port und scheitern, bis sie aktualisiert sind. Firmenfirewalls, die ausgehend 3389 erlauben, blockieren den neuen Port womöglich ganz — die häufigste Beschwerde nach der Umstellung.

Ist RDP auf einem abweichenden Port sicher?

Genauso sicher wie auf 3389, nur mit weniger Hintergrundrauschen. Der Port ist keine Zugriffskontrolle: Der Dienst ist an seinem Handshake erkennbar, und Shodan indiziert RDP auf abweichenden Ports fortlaufend. Sicherheit entsteht daraus, was die Versuche behandelt, nicht daraus, wo sie ankommen.

Soll ich den Port ändern oder einfach angreifende IPs sperren?

Das Sperren ist die Abwehr; der Portwechsel ist Hygiene, die Ihr Protokoll lesbar macht. Wenn Sie nur eines tun, sperren Sie. Beides ist besser als eines: Es kommen weniger Versuche an, und die, die ankommen, werden gestoppt, bevor Windows etwas dafür aufwendet.

RDP-Port von 3389 ändern: was es behebt und was nicht

RDP vom Standardport wegzunehmen senkt das Angriffsvolumen drastisch und schützt vor fast nichts. Beide Hälften sollte man verstehen, bevor man es tut.

6 Min. LesezeitAktualisiert 2026-08-26

Die ehrliche Zusammenfassung

RDP von 3389 wegzuziehen senkt Ihr Volumen fehlgeschlagener Anmeldungen über Nacht um etwa 90%. Es ist zugleich keine Sicherheitsmaßnahme, und es als solche zu behandeln ist die Art, wie Server von Administratoren kompromittiert werden, die dachten, sie seien fertig.

Beide Aussagen stimmen, weil sie verschiedene Fragen beantworten. Der Volumenrückgang ist real, messbar und nützlich. Der Schutz liegt nahe null gegenüber jedem, der dreißig Sekunden mit Nachsehen verbringt.

Lohnt es sich? Meist ja — als Rauschunterdrückung, zusätzlich zu einer Abwehr, niemals statt einer.

Was es tatsächlich stoppt

Der überwiegende Teil des RDP-Angriffsverkehrs stammt von ungezielten Scannern, die eines tun: sich über große IP-Bereiche mit Port 3389 verbinden und Passwörter probieren, wo etwas antwortet. Sie scannen keine Ports. 65.535 Ports pro Adresse zu scannen kostet Größenordnungen mehr als einen zu prüfen, und es gibt genug Maschinen auf 3389, dass es sich nicht lohnt.

Ziehen Sie auf 34519 um, und Sie fallen komplett aus dieser Population heraus. Die Kurve bricht ein, das Sicherheitsprotokoll rotiert nicht mehr alle paar Stunden, und ein echtes Ereignis darin zu finden wird wieder möglich.

Dieser letzte Punkt wird unterschätzt. Ein lesbares Ereignisprotokoll ist während eines Vorfalls bares Geld wert, und bei dreitausend Fehlschlägen am Tag haben Sie keines.

Was es nicht stoppt

Wer den gesamten Portbereich scannt, findet Sie in Minuten. RDP ist an seinem Handshake trivial identifizierbar, egal auf welchem Port es sitzt, ein Scanner also, der alle Ports durchgeht und Antworten fingerabdruckt, benennt Ihren Dienst beim ersten Mal korrekt.

Shodan und Censys tun genau das fortlaufend, über das ganze Internet, und veröffentlichen die Ergebnisse als durchsuchbaren Index. Ihr abweichender RDP-Port steht dort, für jeden auffindbar, binnen Tagen nach dem Öffnen.

Gegen einen ungezielten Bot funktioniert der Portwechsel also. Gegen jemanden, der Sie ausgewählt hat — einen Wettbewerber, einen ehemaligen Mitarbeiter, einen Ransomware-Betreiber, der eine Branchenliste abarbeitet —, kostet er ein paar Minuten. Und er ändert gar nichts an schwachen Passwörtern, offenem SMB, einem ungepatchten Host oder anderswo geleakten Zugangsdaten.

Es gibt auch einen aktiven Nachteil: Ungewöhnliche Ports brechen Dinge. Firmenfirewalls, die ausgehend 3389 erlauben, blockieren ausgehend 34519 — und Sie erfahren das von einem Nutzer, der nicht arbeiten kann.

Umstellen, ohne sich auszusperren

Der Port steht in der Registry, und die Windows-Firewall muss davon wissen, bevor Sie den Dienst neu starten — in dieser Reihenfolge, sonst trennen Sie sich von einer Maschine, die Sie nur über RDP erreichen.

Wählen Sie einen ungenutzten Port über 10000, prüfen Sie, dass er frei ist, öffnen Sie ihn und ändern Sie erst dann:

powershell

$NewPort = 34519

# 1. Bestätigen, dass dort noch nichts lauscht.
Get-NetTCPConnection -LocalPort $NewPort -ErrorAction SilentlyContinue

# 2. Ihn ZUERST in der Firewall öffnen — bevor der Dienst umzieht.
New-NetFirewallRule -DisplayName "RDP-$NewPort" -Direction Inbound `
  -Protocol TCP -LocalPort $NewPort -Action Allow

# 3. Terminal Services auf den neuen Port zeigen lassen.
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name PortNumber -Value $NewPort

# 4. Dienst neu starten (trennt Ihre aktuelle Sitzung).
Restart-Service TermService -Force

Danach

Verbinden Sie sich mit explizitem Port — mstsc /v:server:34519 — und aktualisieren Sie alles, was den alten gespeichert hat: RDP-Dateien, Verbindungsmanager, Monitoring-Prüfungen, Jump-Host-Konfigurationen, die Dokumentation Ihres Teams. Entfernen oder verengen Sie dann die alte 3389-Freigaberegel, sonst haben Sie nichts gewonnen.

Löschen Sie die alte Regel nicht, bevor Sie bestätigt haben, dass der neue Port von außerhalb Ihres Netzes funktioniert. Im LAN funktioniert beides — und genau so überzeugen sich Leute davon, dass alles in Ordnung ist.

Womit es zu kombinieren ist

Ein Portwechsel reduziert Rauschen. Irgendetwas muss die ankommenden Versuche trotzdem behandeln — und nach einem Portwechsel sind die ankommenden Versuche die von jemandem, der gezielt nach Ihnen gesucht hat, also genau die, die Sie interessieren.

Das heißt dieselben drei Dinge wie zuvor: fehlgeschlagene Anmeldungen beobachten, Quellen über dem Schwellwert sperren und nie selbst in eine Sperre laufen. RDP Protector ermittelt den tatsächlichen RDP-Port aus der Registry und den lauschenden Sockets, statt 3389 anzunehmen — ein verlegter Server ist also ohne jede Konfiguration abgedeckt, und die Regeln werden automatisch neu gebaut, wenn sich der Port erneut ändert.

Ändern Sie den Port für ein lesbares Protokoll. Behalten Sie eine Abwehr für den Verkehr, der Sie trotzdem findet.

FAQ

Auf welchen Port sollte ich RDP verlegen?: Auf einen beliebigen freien über 10000 — 34519, 47820, was frei ist. Meiden Sie Ports bekannter Dienste, da Scanner genau die gezielt prüfen, und meiden Sie 3390, das Erste, was jeder nach 3389 probiert. Prüfen Sie vorher mit Get-NetTCPConnection, dass dort nichts lauscht.
Bricht ein geänderter RDP-Port Remote-Desktop-Clients?: Nein, aber jeder Client muss den Port nun nennen: server:34519 im Computerfeld oder mstsc /v:server:34519. Gespeicherte .rdp-Dateien und Verbindungsmanager behalten den alten Port und scheitern, bis sie aktualisiert sind. Firmenfirewalls, die ausgehend 3389 erlauben, blockieren den neuen Port womöglich ganz — die häufigste Beschwerde nach der Umstellung.
Ist RDP auf einem abweichenden Port sicher?: Genauso sicher wie auf 3389, nur mit weniger Hintergrundrauschen. Der Port ist keine Zugriffskontrolle: Der Dienst ist an seinem Handshake erkennbar, und Shodan indiziert RDP auf abweichenden Ports fortlaufend. Sicherheit entsteht daraus, was die Versuche behandelt, nicht daraus, wo sie ankommen.
Soll ich den Port ändern oder einfach angreifende IPs sperren?: Das Sperren ist die Abwehr; der Portwechsel ist Hygiene, die Ihr Protokoll lesbar macht. Wenn Sie nur eines tun, sperren Sie. Beides ist besser als eines: Es kommen weniger Versuche an, und die, die ankommen, werden gestoppt, bevor Windows etwas dafür aufwendet.