RDP absichern: Windows Server gegen Angriffe schützen

Ein Windows-Server, der mit offenem Port 3389 ins Netz geht, wird nicht irgendwann angegriffen, sondern innerhalb weniger Minuten. Die Scanner laufen permanent, sie kennen jeden IPv4-Adressbereich und probieren stumpf Benutzernamen und Kennwörter durch. Fast jeder Ransomware-Vorfall bei kleinen Servern beginnt an genau dieser Stelle: ein Konto namens Administrator, ein Kennwort, das jemand für ausreichend hielt, und keine Sperre nach dem tausendsten Fehlversuch.

Diese Anleitung geht die Maßnahmen in der Reihenfolge ihrer tatsächlichen Wirkung durch, nicht in der Reihenfolge, in der sie in den meisten Beiträgen stehen. Alle Befehle laufen in einer PowerShell-Sitzung mit Administratorrechten auf Windows Server 2016 bis 2025.

Warum RDP das meistangegriffene Tor ist

RDP ist kein schlechtes Protokoll. Das Problem ist, dass es ein vollwertiges Anmeldeformular ins offene Internet stellt und dass Windows dieses Formular standardmäßig unbegrenzt oft ausfüllen lässt. Ein Angreifer braucht keine Lücke, er braucht nur Geduld und eine Kennwortliste.

Wie stark dein Server betroffen ist, kannst du in einer Zeile nachsehen. Zähle die fehlgeschlagenen Anmeldungen der letzten 24 Stunden:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-1)} -ErrorAction SilentlyContinue | Measure-Object | Select-Object -ExpandProperty Count

Ein interner Server ohne Interneterreichbarkeit liegt typischerweise im niedrigen zweistelligen Bereich pro Tag, meist vergessene Kennwörter und alte Dienstkonten. Ein Server mit offenem 3389 liegt schnell im vier- bis fünfstelligen Bereich. Diese Zahl ist deine Messlatte: Nach den Maßnahmen unten sollte sie um Größenordnungen fallen. Kommt Get-WinEvent mit der Meldung "Es wurden keine Ereignisse gefunden, die den angegebenen Auswahlkriterien entsprechen" zurück, protokolliert dein Server fehlgeschlagene Anmeldungen gar nicht. Das reparieren wir weiter unten.

Vor der ersten Änderung: den Rückweg sichern

Jede der folgenden Maßnahmen kann dich aussperren. Bei einem Server, den du nur über RDP erreichst, ist das das Ende der Sitzung und der Beginn eines langen Abends. Drei Vorkehrungen kosten fünf Minuten und verhindern genau das.

Erstens: Prüfe, ob du eine Konsole hast, die unabhängig von RDP funktioniert. Bei KVM-Rootservern von KernelHost findest du im Kundenbereich eine VNC-Konsole, die direkt auf den Bildschirm der virtuellen Maschine schaut. Sie funktioniert auch dann noch, wenn Firewall, Netzwerk und RDP-Dienst gemeinsam kaputt sind. Öffne sie einmal testweise, bevor du etwas änderst, nicht danach.

Zweitens: Lege ein zweites Administratorkonto an, damit eine gesperrte Kennung nicht gleichbedeutend mit einem verlorenen Server ist. Die Gruppennamen sind sprachabhängig, deshalb arbeiten wir mit den festen SIDs (S-1-5-32-544 ist die lokale Administratorengruppe, S-1-5-32-555 die Remotedesktopbenutzer):

New-LocalUser -Name 'kh-adm' -Password (Read-Host -AsSecureString -Prompt 'Kennwort') -FullName 'Wartungskonto' -PasswordNeverExpires
Add-LocalGroupMember -SID 'S-1-5-32-544' -Member 'kh-adm'
Add-LocalGroupMember -SID 'S-1-5-32-555' -Member 'kh-adm'

Die dritte Zeile ist streng genommen überflüssig, weil Mitglieder der lokalen Administratorengruppe ohnehin per RDP hereinkommen. Sie schadet aber nicht und macht die Absicht sichtbar, falls du das Konto später aus der Administratorengruppe nimmst.

Drittens: Lass die RDP-Sitzung, in der du arbeitest, während der gesamten Umstellung offen und teste jede Änderung mit einer zweiten, neuen Verbindung. Eine bestehende Sitzung wird von neuen Firewallregeln nicht sofort getrennt, eine neue Verbindung scheitert dagegen sofort. So merkst du den Fehler, solange du ihn noch zurücknehmen kannst.

Netzwerkebenen-Authentifizierung erzwingen

Ohne Netzwerkebenen-Authentifizierung (englisch Network Level Authentication, kurz NLA) baut der Server zuerst eine Sitzung auf, zeichnet einen Anmeldebildschirm und fragt danach nach den Zugangsdaten. Jeder anonyme Verbindungsversuch kostet damit Arbeitsspeicher und CPU, und der gesamte Code hinter dem Anmeldebildschirm ist vor jeder Authentifizierung erreichbar. Genau dort saßen die schweren RDP-Lücken der Vergangenheit.

Mit NLA prüft der Server die Zugangsdaten über CredSSP, bevor überhaupt eine Sitzung entsteht. Ein Bot, der keine gültigen Daten hat, bekommt nichts als eine abgewiesene TLS-Verbindung.

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -Value 1
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'SecurityLayer' -Value 2

SecurityLayer auf 2 erzwingt TLS für die Aushandlung. Der Wert 1 (Aushandeln) lässt einen Client notfalls auf die alte RDP-Sicherheitsschicht zurückfallen, 0 ist die alte Schicht ohne TLS. Prüfen:

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' | Select-Object UserAuthentication, SecurityLayer

Ein Neustart ist nicht nötig, die Werte gelten für jede neu aufgebaute Verbindung. Bestehende Sitzungen laufen unverändert weiter, was praktisch ist, falls du dir gerade einen Client aussperrst.

Wenn danach niemand mehr hereinkommt

Zwei Fehlerbilder tauchen nach dem Einschalten von NLA regelmäßig auf.

"Der Remotecomputer erfordert eine Authentifizierung auf Netzwerkebene, die von Ihrem Computer nicht unterstützt wird. Wenden Sie sich an den Systemadministrator oder an den technischen Support." Der Client ist zu alt oder spricht kein CredSSP. Aktuelle Windows-Clients können das seit Jahren. Unter Linux verlangt FreeRDP den Schalter /sec:nla, Remmina die Einstellung des Sicherheitsprotokolls auf NLA, und sehr alte macOS-Clients scheitern grundsätzlich. Die Lösung ist immer der neuere Client, nicht das Abschalten von NLA.

Anmeldung schlägt mit korrektem Kennwort fehl. Das ist die Falle, die die meisten Anleitungen verschweigen: Ist bei einem Konto "Benutzer muss Kennwort bei der nächsten Anmeldung ändern" gesetzt oder das Kennwort abgelaufen, kann sich dieses Konto mit aktivem NLA gar nicht mehr anmelden. CredSSP kennt keinen Kennwortwechsel, das ist so vorgesehen. Der Server meldet je nach Version einen Authentifizierungsfehler oder schlicht falsche Anmeldeinformationen. Der Ausweg führt über die Konsole im Kundenbereich, oder du nimmst Wartungskonten von der Ablauffrist aus:

Set-LocalUser -Name 'kh-adm' -PasswordNeverExpires $true

Kontosperrung: der wirksamste einzelne Schalter

Ein starkes Kennwort schützt gegen Raten, eine Kontosperrung schützt gegen unbegrenztes Raten. Ohne sie darf ein Angreifer Millionen Versuche pro Woche unternehmen, mit ihr sind es zehn pro Viertelstunde. Setze Schwellenwert, Sperrdauer und Beobachtungsfenster in einem Aufruf, sonst lehnt Windows die Dauer ab, solange der Schwellenwert noch bei 0 steht:

net accounts /lockoutthreshold:10 /lockoutduration:15 /lockoutwindow:15

Die Sperrdauer muss immer größer oder gleich dem Beobachtungsfenster sein. Ergebnis kontrollieren:

net accounts

Neuere Windows-Versionen bringen bereits eine Vorgabe in dieser Größenordnung mit, ältere Installationen und viele Anbieter-Abbilder nicht. Prüfen kostet nichts.

Das eingebaute Administratorkonto einbeziehen

Historisch war genau das Konto, das jeder Angreifer zuerst probiert, von der Sperre ausgenommen. Dafür gibt es die Richtlinie "Sperrung des Administratorkontos zulassen". Sie setzt allerdings einen neueren Stand voraus, nämlich Windows 11 22H2 beziehungsweise Windows Server 2025. Auf einem Windows Server 2022 (Build 20348) enthält der Export der Sicherheitsrichtlinie die Zeile AllowAdministratorLockout überhaupt nicht, im Abschnitt [System Access] stehen dort nur Werte wie LockoutBadCount und MinimumPasswordLength. Prüfe deshalb zuerst, was dein System tatsächlich exportiert:

secedit /export /cfg C:\secpol.inf
Select-String -Path C:\secpol.inf -Pattern 'AllowAdministratorLockout'

Kommt hier keine Fundstelle zurück, kennt dein Build die Richtlinie nicht, und dieser Abschnitt ist für dich erledigt. Genau hier liegt die Falle, die die meisten Anleitungen erzeugen: Der übliche Einzeiler mit -replace ersetzt eine Zeichenkette, die es in der Datei gar nicht gibt, meldet aber keinen Fehler, und das anschließende secedit /configure quittiert mit Erfolg. Du glaubst danach, die Administrator-Sperre sei aktiv, obwohl sich nichts geändert hat.

Auf einem Build, der die Richtlinie kennt, änderst du die Zeile, falls vorhanden, und fügst sie sonst ein. Diese Fassung deckt beide Fälle ab:

$c = Get-Content C:\secpol.inf
if ($c -notmatch 'AllowAdministratorLockout') { $c = $c -replace '(LockoutBadCount = \d+)', "`$1`r`nAllowAdministratorLockout = 1" } else { $c = $c -replace 'AllowAdministratorLockout = 0','AllowAdministratorLockout = 1' }
$c | Set-Content C:\secpol.inf -Encoding Unicode

Das -Encoding Unicode ist Pflicht und kein Detail: Die INF-Datei muss UTF-16 LE mit Byte-Order-Mark sein. Set-Content schreibt in Windows PowerShell 5.1 sonst ANSI, und secedit verweigert die Annahme. Vor dem Zurückschreiben prüft secedit /validate C:\secpol.inf die Datei, danach:

secedit /configure /db C:\Windows\security\local.sdb /cfg C:\secpol.inf /areas SECURITYPOLICY

Und danach unbedingt gegenlesen, denn ein erfolgreicher secedit-Lauf beweist an dieser Stelle nichts. Exportiere die Richtlinie erneut in eine zweite Datei und sieh nach, ob der Wert wirklich mit 1 drinsteht.

Auf einem Domänencontroller greifen diese lokalen Einstellungen nicht. Dort gehört die Sperrrichtlinie in die Default Domain Policy unter Computerkonfiguration, Windows-Einstellungen, Sicherheitseinstellungen, Kontorichtlinien.

Die Kehrseite und wie du wieder hereinkommst

Eine Kontosperrung ist auch eine Waffe gegen dich: Wer deinen Benutzernamen kennt, kann ihn dauerhaft gesperrt halten, indem er alle 15 Minuten zehn falsche Kennwörter schickt. Genau deshalb ist die Sperre nur die zweite Verteidigungslinie, die erste ist die IP-Beschränkung im nächsten Abschnitt.

Ist ein lokales Konto gesperrt, meldet der Client sinngemäß "Das verwendete Konto ist gesperrt und kann für die Anmeldung nicht verwendet werden". Der einfachste Weg zurück ist Abwarten, denn nach Ablauf der Sperrdauer entsperrt Windows von selbst. Wer nicht warten will, entsperrt über die Konsole:

$u = [ADSI]"WinNT://./kh-adm,user"; $u.IsAccountLocked = $false; $u.SetInfo()

Im Active Directory geht es kürzer mit Unlock-ADAccount -Identity kh-adm.

Kennwörter, die eine Sperre erst sinnvoll machen

Zehn Versuche pro Viertelstunde sind nur dann eine Hürde, wenn das Kennwort nicht auf Platz drei jeder Liste steht. Mindestlänge und Komplexität setzt du so:

net accounts /minpwlen:14

Die Komplexitätsregel liegt wieder in der Sicherheitsrichtlinie, Abschnitt [System Access], Schlüssel PasswordComplexity = 1. Der Weg ist derselbe wie oben mit secedit.

Zwei Punkte aus der Praxis: Erstens bringt erzwungener Kennwortwechsel alle 30 Tage nachweislich wenig und erzeugt in Kombination mit NLA genau das Anmeldeproblem aus dem vorigen Abschnitt. Lange, einmalig gesetzte und in einem Kennwortmanager abgelegte Kennwörter sind besser. Zweitens gilt die Richtlinie nur für neu gesetzte Kennwörter. Ein bestehendes sechsstelliges Kennwort bleibt gültig, bis du es änderst.

Zugriff auf bekannte IP-Adressen begrenzen

Das ist die Maßnahme, die den Angriffsverkehr wirklich beendet, und zwar vollständig. Alle Regeln der Remotedesktop-Gruppe lassen sich auf eine Adressliste einschränken. Verwende die sprachneutrale Gruppenkennung, damit das Skript auch auf englischen Installationen funktioniert:

Get-NetFirewallRule -Group '@FirewallAPI.dll,-28752' | Select-Object Name, DisplayName, Enabled, Profile

Set-NetFirewallRule -Group '@FirewallAPI.dll,-28752' -RemoteAddress @('203.0.113.10','198.51.100.0/24')

Erwarte dabei mehr Treffer, als du Regeln erwartest. -Group fasst alle Regeln der Gruppe an, auf einem Testsystem waren das sechs Stück, inklusive der Schattenregeln und zusätzlicher, GUID-benannter Kopien im Profil Public. Das ist so gewollt und richtig, denn sonst bliebe eine der Kopien offen. Die vorangehende Auflistung mit Get-NetFirewallRule zeigt dir vorher, was betroffen sein wird.

Kontrolle, welche Adressen tatsächlich gespeichert wurden:

Get-NetFirewallRule -Group '@FirewallAPI.dll,-28752' | Get-NetFirewallAddressFilter

Hast du den Port geändert, greifen die eingebauten Regeln nicht mehr, denn sie sind fest auf 3389 gebunden. Dann brauchst du eine eigene Regel:

New-NetFirewallRule -DisplayName 'RDP eingeschraenkt' -Direction Inbound -Protocol TCP -LocalPort 34567 -RemoteAddress '203.0.113.10' -Action Allow -Profile Any

Der Rettungsanker gegen die eigene Firewallregel

Wer seine IP-Adresse falsch abtippt oder eine dynamische Adresse eingetragen hat, sperrt sich zuverlässig aus. Lege deshalb vorher eine Aufgabe an, die die Einschränkung nach zehn Minuten selbsttätig zurücknimmt:

Set-Content -Path C:\rdp-rettung.ps1 -Value "Set-NetFirewallRule -Group '@FirewallAPI.dll,-28752' -RemoteAddress Any"

Register-ScheduledTask -TaskName 'RDP-Rettung' -Action (New-ScheduledTaskAction -Execute 'powershell.exe' -Argument '-ExecutionPolicy Bypass -File C:\rdp-rettung.ps1') -Trigger (New-ScheduledTaskTrigger -Once -At (Get-Date).AddMinutes(10)) -User 'SYSTEM' -RunLevel Highest

Funktioniert die neue Verbindung, entfernst du die Aufgabe wieder:

Unregister-ScheduledTask -TaskName 'RDP-Rettung' -Confirm:$false

Hast du keine feste IP-Adresse, ist die saubere Lösung, RDP gar nicht ins Internet zu stellen, sondern über ein VPN zu erreichen. Wie du das aufsetzt, steht in unserer Anleitung zum WireGuard-VPN-Server. Der Server hört dann nur noch auf der VPN-Adresse, und Port 3389 verschwindet komplett aus dem Internet.

Den Port ändern und was das wirklich bringt

Ein anderer Port ist keine Sicherheitsmaßnahme, sondern eine Lärmschutzmaßnahme. Die große Masse der Bots scannt ausschließlich 3389 und findet dich danach nicht mehr, was deine 4625-Zahl in der Regel drastisch senkt und die Ereignisprotokolle wieder lesbar macht. Wer gezielt sucht, findet den Dienst trotzdem: Suchmaschinen für offene Dienste erkennen RDP am Protokoll-Fingerabdruck, unabhängig vom Port, und ein voller Portscan über 65535 Ports dauert Sekunden.

Der Portwechsel ist also sinnvoll als Ergänzung, aber niemals als Ersatz für NLA, Kontosperrung und Adressbeschränkung. Die praktische Umsetzung inklusive des Teils, den fast alle Anleitungen falsch machen, nämlich ohne Neustart, haben wir separat beschrieben: RDP-Port ohne Neustart ändern. Denk in jedem Fall daran, für den neuen Port eine Firewallregel anzulegen, bevor du den Dienst umstellst.

Anmeldeprotokolle auswerten

Zuerst muss die Protokollierung überhaupt eingeschaltet sein. Die Unterkategorienamen von auditpol sind übersetzt, ein englischer Befehl scheitert auf einem deutschen System mit "Fehler 0x00000057 aufgetreten: Der Parameter ist falsch." Die GUID funktioniert dagegen auf jeder Sprachfassung:

auditpol /set '/subcategory:{0CCE9215-69AE-11D9-BED3-505054503030}' /success:enable /failure:enable

auditpol /get '/subcategory:{0CCE9215-69AE-11D9-BED3-505054503030}'

Die einfachen Anführungszeichen um den ganzen Parameter sind kein Schönheitsfehler, sondern zwingend. PowerShell deutet die geschweiften Klammern sonst als Skriptblock und entfernt sie, aus einem Argument werden drei, und auditpol bricht mit Error 0x00000057 occurred: The parameter is incorrect. und Exitcode 87 ab, gefolgt vom Hilfetext. In cmd.exe funktioniert die Schreibweise ohne Anführungszeichen, in PowerShell nicht. Mit Anführungszeichen läuft beides mit Exitcode 0 durch, die Kontrollabfrage antwortet dann mit Logon Success and Failure.

Unter Beschuss rollt das Sicherheitsprotokoll in wenigen Stunden über und überschreibt genau die Einträge, die du brauchst. Gib ihm mehr Platz:

wevtutil sl Security /ms:1073741824

Danach die häufigsten Quell-Adressen der letzten Woche, sortiert nach Anzahl. Die Variante über die XML-Struktur ist die robuste, weil sie nicht von der Feldreihenfolge abhängt:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-7)} -ErrorAction SilentlyContinue | ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data | Where-Object { $_.Name -eq 'IpAddress' } | Select-Object -ExpandProperty '#text' } | Group-Object | Sort-Object Count -Descending | Select-Object -First 15 Count, Name

Das -ErrorAction SilentlyContinue gehört an jeden dieser Aufrufe. Get-WinEvent bricht mit einem roten Fehler ab, sobald im Zeitraum kein einziges passendes Ereignis vorliegt: "No events were found that match the specified selection criteria." Auf einem frisch abgesicherten Server ist genau das der Normalfall, der Befehl scheitert also ausgerechnet bei dem Erfolg, den diese Anleitung anstrebt.

Die entscheidende Frage ist aber nicht, wer es versucht hat, sondern ob es jemand geschafft hat. Erfolgreiche Remotedesktop-Anmeldungen tragen die Ereignis-ID 4624 mit dem Anmeldetyp 10 (RemoteInteractive):

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddDays(-7)} -ErrorAction SilentlyContinue | Where-Object { $_.Properties[8].Value -eq 10 } | Select-Object TimeCreated, @{n='Benutzer';e={$_.Properties[5].Value}}, @{n='Quelle';e={$_.Properties[18].Value}} | Format-Table -AutoSize

Steht dort ein Benutzername oder eine Quelladresse, die du nicht zuordnen kannst, hat jemand ein gültiges Kennwort gefunden. Dann hilft kein Nachschärfen der Richtlinien mehr, dann gehört der Server neu aufgesetzt.

Zusätzlich lohnt ein Blick in das eigene RDP-Protokoll. Ereignis 1149 nennt Benutzer, Domäne und Quelladresse jeder autorisierten Verbindung in einer Zeile:

Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational' -FilterXPath '*[System[EventID=1149]]' -MaxEvents 25 | Format-List TimeCreated, Message

Administrator umbenennen, besser noch abschalten

Das eingebaute Administratorkonto ist der einzige Benutzername, den jeder Angreifer sicher kennt. Umbenennen kostet nichts:

Rename-LocalUser -Name 'Administrator' -NewName 'kh-svc'

Sei dir aber über die Grenze im Klaren: Die SID des Kontos endet weiterhin auf -500, und jeder authentifizierte Zugriff kann den neuen Namen darüber auflösen. Gegen Massenbots wirkt die Umbenennung, gegen einen gezielten Angreifer, der bereits irgendeinen Fuß in der Tür hat, nicht. So findest du das Konto trotz neuem Namen:

Get-LocalUser | Where-Object { $_.SID.Value -like '*-500' } | Select-Object Name, Enabled

Deutlich wirksamer ist, das eingebaute Konto ganz abzuschalten, nachdem dein eigenes Administratorkonto aus dem Abschnitt "Rückweg sichern" nachweislich funktioniert. Teste die Anmeldung mit dem neuen Konto in einer zweiten Sitzung, erst dann:

Disable-LocalUser -Name 'kh-svc'

Sperre zusätzlich den RDP-Zugang auf die Personen ein, die ihn brauchen. Standardmäßig darf jedes Mitglied der lokalen Administratorengruppe per RDP herein, auch Dienstkonten, die das nie tun sollten. Wer aktuell darf, zeigt:

Get-LocalGroupMember -SID 'S-1-5-32-555'

Woran du erkennst, dass es wirklich funktioniert hat

Abhaken statt hoffen. Diese fünf Prüfungen sagen dir, ob die Umstellung angekommen ist:

1. NLA: Get-ItemProperty auf RDP-Tcp liefert UserAuthentication : 1 und SecurityLayer : 2. Eine neue Verbindung fragt jetzt vor dem Verbindungsaufbau nach den Zugangsdaten, nicht erst auf einem Anmeldebildschirm im Fenster.
2. Sperre: net accounts zeigt einen Sperrschwellenwert ungleich "Nie". Gegentest mit einem Wegwerfkonto: nach dem elften falschen Kennwort muss der Client die Sperrmeldung bringen, nicht mehr die Meldung über falsche Anmeldeinformationen.
3. Firewall: Get-NetFirewallAddressFilter zeigt deine Adressen statt Any. Ein Verbindungstest von einer fremden Adresse muss in einen Zeitüberschreitungsfehler laufen, nicht in eine Anmeldeaufforderung. Prüfe das von außen mit Test-NetConnection -ComputerName deinserver -Port 3389, das Ergebnis muss TcpTestSucceeded : False lauten.
4. Protokolle: auditpol /get meldet für die Unterkategorie Erfolg und Fehler.
5. Die Zahl: Zähle die 4625-Ereignisse 24 Stunden nach der Umstellung erneut. Sie muss deutlich niedriger liegen. Bleibt sie hoch, greift eine deiner Regeln nicht, meist weil eine zweite, offenere Firewallregel für Port 3389 existiert, die ein Anbieter-Abbild oder eine Softwareinstallation angelegt hat. Diese Zeile findet sie: Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 3389 } | Get-NetFirewallRule | Select-Object DisplayName, Enabled, Profile, Action. Die Reihenfolge in der Pipeline ist Absicht. Dreht man sie um und schickt zuerst alle Firewallregeln durch Get-NetFirewallPortFilter, dauert der Aufruf gemessen rund 12 Sekunden statt einer, und vor allem fehlt in der Ausgabe der Regelname: Du siehst dann vier Treffer, ohne zu erfahren, welche Regeln das sind.

Wenn du einen Server ohnehin gerade frisch aufsetzt, arbeite die Punkte gleich zu Beginn ab, statt sie nachzurüsten. Für Linux-Systeme gilt dasselbe Muster mit SSH statt RDP, beschrieben in SSH absichern und Key-Login einrichten, und die Reihenfolge der ersten Schritte findest du in unserer Checkliste für neue Rootserver.

Was RDP-Härtung nicht abdeckt

Die Maßnahmen oben schützen gegen Anmeldeversuche. Sie schützen nicht gegen Volumenangriffe, die den Server über die Netzanbindung unerreichbar machen sollen. Dagegen hilft nur Filterung im Netz davor. Wie diese Angriffe funktionieren, steht in Was ist ein DDoS-Angriff, und welche Vorkehrungen serverseitig sinnvoll bleiben, in Server vor DDoS-Angriffen schützen. Alle Server von KernelHost stehen im Rechenzentrum maincubes in Frankfurt am Main hinter einer Filterung, die Angriffsverkehr bereits vor dem Server abfängt.

Und sie ersetzen kein Backup. Ein Server, auf dem sich jemand erfolgreich angemeldet hat, ist nicht mehr vertrauenswürdig, egal wie schnell du das Kennwort danach änderst. Der einzige verlässliche Weg zurück ist ein Sicherungsstand von vor dem Vorfall.