- Port 3389 offen im Internet wird laufend von Bots abgeklopft – nicht ob, sondern wann jemand anklopft.
- Network Level Authentication (NLA) ist die wichtigste Einzelmaßnahme und in wenigen Minuten aktiviert.
- Am sichersten bleibt: RDP gar nicht erst öffentlich erreichbar machen, sondern über VPN oder Firewall-Whitelist absichern.
Ein Windows-Server mit offenem Remote Desktop ist wie ein Haus mit einer Tür, die jeder von der Straße aus sehen kann. Es dauert nicht Tage, es dauert oft Minuten, bis automatisierte Scanner den offenen Port 3389 finden und mit dem Durchprobieren von Zugangsdaten beginnen. Wer einen Windows-VPS betreibt und RDP für den Zugriff nutzt, sollte diesen Zugang nicht dem Zufall überlassen.
Der Reiz ist verständlich: RDP direkt aus dem Internet erreichbar zu machen ist bequem, kein VPN-Client, kein Tunnel, einfach IP eingeben und verbinden. Genau diese Bequemlichkeit ist aber auch das Problem. In diesem Beitrag zeigen wir, wie du den Zugang absicherst, ohne dir selbst den Weg zum eigenen Server zu verbauen.
Warum offenes RDP so gefährlich ist
RDP-Angriffe laufen fast immer nach demselben Muster: Credential-Stuffing und Brute-Force gegen bekannte oder erratene Benutzernamen wie Administrator oder admin. Gelingt der Login, hat der Angreifer eine vollwertige grafische Sitzung auf dem Server – kein Umweg über eine Webshell nötig, keine Rechteausweitung, sofort vollen Zugriff. Genau deshalb ist ein kompromittierter RDP-Zugang häufig der erste Schritt zu Ransomware auf dem gesamten System.
Ein offener RDP-Port ohne zusätzliche Absicherung ist keine Frage von "vielleicht", sondern von "wann" – automatisierte Scanner kennen jede öffentliche IPv4-Adresse.
Administrator für den Login. Ein Angreifer, der den Benutzernamen schon kennt, muss nur noch das Passwort erraten – das halbiert seine Arbeit.Die drei Wege im Vergleich
Es gibt nicht die eine richtige Lösung, sondern verschiedene Absicherungsgrade, die sich kombinieren lassen.
| Methode | Schutzwirkung | Aufwand |
|---|---|---|
| Nur NLA + starkes Passwort | Reduziert automatisierte Angriffe, schützt nicht vor gezielten | Gering |
| Firewall-Whitelist auf feste IP | Blockt fast alle Scanner komplett | Mittel, bricht bei wechselnder IP |
| VPN statt offenem RDP | Port 3389 ist von außen gar nicht sichtbar | Höher, aber am robustesten |
Schritt für Schritt: RDP absichern
- Network Level Authentication aktivieren. NLA verlangt die Authentifizierung schon vor Aufbau der vollen RDP-Sitzung und blockt damit einen großen Teil automatisierter Angriffe.
Get-WmiObject -Class Win32_TSGeneralSetting -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'" | Set-WmiInstance -Arguments @{UserAuthenticationRequired=1} - Standard-Port ändern. Das hält keine gezielten Angreifer ab, verschwindet aber aus den meisten automatisierten Scans nach Port 3389.
Danach den Server neu starten und die Windows-Firewall-Regel für den neuen Port anpassen.New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber -Value 33890 -PropertyType DWORD -Force - Kontosperrung nach Fehlversuchen aktivieren. Verhindert endloses Durchprobieren von Passwörtern.
net accounts /lockoutthreshold:5 /lockoutduration:30 /lockoutwindow:30 - Firewall auf bekannte IP-Adressen einschränken. Wenn du von einer festen IP oder einem festen Bereich aus arbeitest, lass nur diese zu.
New-NetFirewallRule -DisplayName "RDP nur Buero" -Direction Inbound -LocalPort 33890 -Protocol TCP -RemoteAddress 203.0.113.0/24 -Action Allow - Windows-Updates aktuell halten. Kritische RDP-Schwachstellen wie BlueKeep haben gezeigt, dass ungepatchte Systeme auch ohne gestohlenes Passwort übernehmbar sind. Automatische Updates aktivieren oder regelmäßig manuell prüfen.
Der robusteste Weg: RDP hinter ein VPN legen
Alle Maßnahmen oben reduzieren die Angriffsfläche, aber der Port bleibt sichtbar. Wer wirklich sichergehen will, macht Port 3389 von außen gar nicht erst erreichbar und lässt den Zugriff nur über ein VPN zu. Auf einem VPN-Server baust du dir ein eigenes Gateway, verbindest dich dort zuerst hinein und erst danach per RDP auf den eigentlichen Server – aus dem öffentlichen Internet ist RDP dann schlicht nicht sichtbar.
- Port 3389 taucht in keinem Portscan von außen auf
- Ein zusätzlicher Login-Schritt vor dem eigentlichen RDP-Login
- Funktioniert auch bei wechselnder IP-Adresse unterwegs
- Zusätzlicher Dienst, der gepflegt werden muss
- VPN-Client auf jedem Gerät nötig, das zugreifen soll
- Bei VPN-Ausfall ist auch der RDP-Zugang weg
Prüfen, ob es geklappt hat
Nach der Umstellung solltest du von außen testen, dass der Server sich wie erwartet verhält:
- Port-Check von außen: Ein Portscan (z. B. mit
Test-NetConnectionvon einem anderen Rechner) gegen Port 3389 sollte keine Antwort mehr liefern, gegen den neuen Port nur von erlaubten IPs aus. - NLA-Status prüfen:
Get-WmiObject -Class Win32_TSGeneralSetting -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'"sollteUserAuthenticationRequired: 1zurückgeben. - Ereignisanzeige kontrollieren: Unter Windows-Protokolle → Sicherheit tauchen fehlgeschlagene Anmeldeversuche (Ereignis-ID 4625) auf – nach der Umstellung sollte deren Zahl spürbar sinken.
Wer den Server ohnehin überwacht, bekommt einen ungewöhnlichen Anstieg an fehlgeschlagenen Logins oder einen unerwarteten Ausfall auch automatisch gemeldet – dazu mehr im Beitrag zu Monitoring bei Prepaid-Host. Und falls der Server ohnehin ansteht, ein Betriebssystem-Upgrade nachzuholen: Auch für Linux-Rootserver mit RDP-ähnlichen Fernzugriffsszenarien lohnt sich ein Blick auf aktuelle Systemversionen, etwa im Beitrag zum Upgrade von Debian 12 auf Debian 13.
Kurz zusammengefasst für den Alltag
Die Minimal-Kombination, die auf jedem Windows-Server mit RDP-Zugang stehen sollte: NLA aktiviert, Kontosperrung nach wenigen Fehlversuchen, ein geänderter Port und eine Firewall-Regel, die nur bekannte Adressen durchlässt. Wer mehr Sicherheit will oder muss, etwa weil sensible Daten auf dem Server liegen, baut sich zusätzlich ein VPN davor. Der eigene Rootserver gibt dir dafür die volle Kontrolle über Firewall und Netzwerkkonfiguration – anders als bei gemanagten Umgebungen, wo solche Anpassungen oft gar nicht möglich sind.
_6a4f6e96d67aa.png)