Wie viele fehlgeschlagene RDP-Anmeldungen sind normal?

Auf einem Server ohne Internetzugang nahezu null — eine Handvoll pro Woche von Leuten mit Tippfehlern. Auf einem Server, dessen RDP von jeder Adresse erreichbar ist, sind einige tausend pro Tag unauffällig und sagen nichts über Sie aus; das ist die Grundrate weltweiten Scannens. Wichtig sind Trend und Quellverteilung, nicht die absolute Zahl.

Stoppt ein Wechsel des RDP-Ports Brute-Force-Angriffe?

Er stoppt die ungezielten Scanner, die nur 3389 prüfen, und das ist in der Praxis der Großteil des Volumens — oft über 90% weniger Versuche. Er stoppt nichts, was den gesamten Portbereich scannt, und Dienste wie Shodan indizieren RDP auf abweichenden Ports fortlaufend. Betrachten Sie es als Rauschunterdrückung, nicht als Schutz.

Sollte ich die Kontosperrungsrichtlinie gegen Brute-Force aktivieren?

Nicht als primäre Abwehr auf einem Server im Internet. Die Sperrung hängt am Kontonamen, und Angreifer wählen Kontonamen frei — also kann jeder Ihr Administrator-Konto auf Zuruf von jeder Adresse sperren. Blockieren Sie auf Netzwerkebene und behalten Sie die Sperrung mit moderatem Schwellwert für interaktive Konten, wenn Sie sie wollen.

Ist das Sperren eines ganzen /24-Subnetzes zu aggressiv?

Für einen Bereich, der Ihnen gerade hunderte Fehlanmeldungen geschickt hat, selten. Angriffsverkehr kommt aus Hosting- und VPS-Bereichen, in denen Nachbaradressen demselben Betreiber gehören; Privatnutzer teilen sich fast nie ein /24 mit einem Scanner. Mit einer Whitelist für Ihre Büros und VPN-Ausgänge liegt die Fehlerquote nahe null.

Wie ein RDP-Brute-Force-Angriff wirklich aussieht

Anatomie des Angriffs, der jeden Windows-Server mit öffentlicher IP trifft: wer ihn betreibt, was er kostet, warum die Standardratschläge nur halb wirken und was ihn stoppt.

7 Min. LesezeitAktualisiert 2026-08-26

Der Angriff, ohne Fachjargon

Ein RDP-Brute-Force-Angriff ist keine gezielte Operation gegen Sie. Er ist Massenware: Jemand mietet ein Botnetz, füttert es mit IP-Bereichen und lässt es auf jeder Maschine anmelden, die auf Port 3389 antwortet. Die Passwortliste ist kurz und langweilig — Administrator mit Password1, admin mit admin, der Firmenname plus aktuelles Jahr. Dem Bot ist egal, was Ihr Server tut.

Unerbittlich macht ihn die Ökonomie. Eine erfolgreiche Anmeldung ist auf dem Markt für Ransomware-Zugänge echtes Geld wert, und ein Versuch kostet praktisch nichts. Also hören die Bots nie auf. Stellen Sie einen frischen Windows Server mit offenem RDP auf eine öffentliche IP: Die erste fehlgeschlagene Anmeldung kommt meist binnen einer Stunde, nach einer Woche sind es konstant einige tausend pro Tag.

Entscheidend ist das Volumen. Ein Mensch, der Ihr Passwort errät, ist eine Geschichte; hunderttausend Versuche im Monat von wechselnden Adressen sind eine Wetterlage. Maßnahmen, die vom Ersten ausgehen, nützen gegen das Zweite nichts.

Woran Sie erkennen, dass es Sie trifft

Windows schreibt jede fehlgeschlagene Anmeldung als Ereignis-ID 4625 ins Sicherheitsprotokoll. Öffnen Sie die Ereignisanzeige, gehen Sie zu Windows-Protokolle → Sicherheit und filtern Sie nach 4625. Auf einem ruhigen Server sehen Sie eine Handvoll Einträge von Nutzern, die sich vertippt haben. Unter Angriff sehen Sie eine Wand.

Aussagekräftig ist nicht die Zahl allein, sondern die Form. Ein Nutzer mit Tippfehler erzeugt zwei bis drei Fehlschläge von einer Adresse, auf ein existierendes Konto, und hört dann auf. Ein Bot erzeugt eine lange Serie gegen Kontonamen, die es auf Ihrer Maschine nie gab — admin, sql, backup, test, scanner, user1 — von Adressen aus Hosting-Bereichen, mit denen Sie nie zu tun hatten, in gleichmäßigem Takt die ganze Nacht.

Dieser Einzeiler liefert die auffälligsten Quelladressen der letzten 24 Stunden:

powershell

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-1)} |
  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 20 Count, Name

Warum die üblichen Ratschläge nur halb wirken

Jede Härtungs-Checkliste beginnt mit „starkes Passwort". Das ist richtig und es reicht nicht. Ein starkes Passwort heißt, dass die Bots es nicht erraten — versuchen werden sie es trotzdem ewig, und jeder Versuch kostet Sie einen Thread, eine Zeile im Audit-Log und ein Stück CPU. Server unter Dauerbeschuss werden messbar langsamer, und das Sicherheitsprotokoll rotiert so schnell, dass genau das Ereignis, das Sie brauchten, weg ist.

Als Nächstes kommt meist „Kontosperrungsrichtlinie aktivieren". Damit vorsichtig. Die Sperrung zählt Fehlschläge pro Konto, und die Bots raten Kontonamen von einer Liste. Sperren Sie Administrator nach fünf Fehlversuchen, kann ein Angreifer, der das Passwort nie hätte erraten können, dieses Konto jederzeit von überall dauerhaft deaktivieren. Sie haben ein Ärgernis in einen Denial-of-Service gegen sich selbst verwandelt.

Network Level Authentication hilft wirklich: Der Client muss sich authentifizieren, bevor eine Sitzung entsteht, was eine ganze Klasse von Pre-Auth-Exploits ausschließt und die Kosten jedes Versuchs senkt. Schalten Sie es ein. Die Versuchsrate senkt es nicht.

Ein VPN vor RDP ist die stärkste verfügbare Antwort und die, die die meisten Organisationen praktisch nicht umsetzen können: Jeder Auftragnehmer, jedes Telefon, jede Notfallanmeldung um drei Uhr nachts läuft dann über zusätzliche Infrastruktur, die ebenfalls gewartet und bezahlt werden muss. Wenn Sie können, tun Sie es. Die meisten Server, die gerade angegriffen werden, gehören denen, die es nicht können.

Was die Versuche tatsächlich reduziert

Das Volumen ändert nur eines: sich zu weigern, mit der Quelle zu sprechen. Alles andere verhandelt mit ihr.

Das heißt: den Fehlschlagstrom beobachten und, sobald eine Adresse einen Schwellwert überschreitet, sie in eine Firewall-Regel aufnehmen, die ihre Pakete verwirft, bevor Windows irgendetwas dafür aufwendet. Genau das leistet fail2ban unter Linux, und ein eingebautes Windows-Äquivalent gibt es nicht — weshalb so viele Administratoren bei einem geplanten PowerShell-Skript landen.

Drei Details trennen eine Abwehr, die hält, von einer, die leckt:

Das Subnetz sperren, nicht die Adresse. Bots leben in Hosting-Bereichen. Sperren Sie 203.0.113.47, startet eine Stunde später .48. Eine /24-Sperre beendet die ganze Serie auf einmal — und legitime Nutzer teilen sich fast nie ein /24 mit einem Scanner.
Dauerhaft sperren und Neustarts überleben. Eine Stundensperre bedeutet, dass dasselbe Botnetz heute Abend wieder da ist. Die Regel muss in der Firewall liegen, nicht im Speicher.
Sich selbst zuerst auf die Whitelist setzen, bevor irgendetwas anderes aktiv wird. Der häufigste Weg, das zu vermasseln, ist ein Administrator, der die eigene Büro-IP von einem Server aussperrt, den er nur über RDP erreicht.

Regeln zusammenfassen, sonst wird die Firewall zum Engpass

Ein Detail, das erst im Betrieb auftaucht: Die Windows-Firewall kommt mit wenigen großen Regeln weit besser zurecht als mit tausenden kleinen. Skripte, die New-NetFirewallRule pro gesperrter Adresse aufrufen, laufen zwei Wochen hervorragend und brauchen dann Minuten zur Auswertung, weil der Regelsatz fünfstellig geworden ist.

Die Lösung ist eine einzige Regel, deren Adressliste überschrieben wird, statt einer Regel pro Angreifer. Eine kleine Designentscheidung, die darüber bestimmt, ob die Abwehr in sechs Monaten noch funktioniert.

Dasselbe, ohne das Skript zu schreiben

RDP Protector ist genau diese Logik, verpackt als signierter Windows-Agent. Er liest denselben 4625-Strom, den Sie lesen würden, entscheidet lokal — funktioniert also weiter, wenn das Netz ausfällt — und pflegt eine einzige zusammengefasste Firewall-Regel mit allen gesperrten Bereichen.

Bei der Installation ermittelt er die tatsächlichen RDP-, FTP- und MS-SQL-Ports aus der Registry und den lauschenden Sockets, sodass ein von 3389 umgezogener Server ohne Konfiguration geschützt ist, und setzt die IP, von der Sie verbunden sind, auf die Whitelist, bevor er irgendetwas blockiert.

Was Sie allein nicht bauen können, ist die geteilte Reputation: Eine Adresse, die einen anderen Kunden angegriffen hat, ist bei Ihnen bereits gesperrt, bevor sie ankommt. Ein Server ist dauerhaft kostenlos — genug, um einen echten Angriffsstrom auf der eigenen Maschine zu beobachten und nach Belegen zu entscheiden.

FAQ

Wie viele fehlgeschlagene RDP-Anmeldungen sind normal?: Auf einem Server ohne Internetzugang nahezu null — eine Handvoll pro Woche von Leuten mit Tippfehlern. Auf einem Server, dessen RDP von jeder Adresse erreichbar ist, sind einige tausend pro Tag unauffällig und sagen nichts über Sie aus; das ist die Grundrate weltweiten Scannens. Wichtig sind Trend und Quellverteilung, nicht die absolute Zahl.
Stoppt ein Wechsel des RDP-Ports Brute-Force-Angriffe?: Er stoppt die ungezielten Scanner, die nur 3389 prüfen, und das ist in der Praxis der Großteil des Volumens — oft über 90% weniger Versuche. Er stoppt nichts, was den gesamten Portbereich scannt, und Dienste wie Shodan indizieren RDP auf abweichenden Ports fortlaufend. Betrachten Sie es als Rauschunterdrückung, nicht als Schutz.
Sollte ich die Kontosperrungsrichtlinie gegen Brute-Force aktivieren?: Nicht als primäre Abwehr auf einem Server im Internet. Die Sperrung hängt am Kontonamen, und Angreifer wählen Kontonamen frei — also kann jeder Ihr Administrator-Konto auf Zuruf von jeder Adresse sperren. Blockieren Sie auf Netzwerkebene und behalten Sie die Sperrung mit moderatem Schwellwert für interaktive Konten, wenn Sie sie wollen.
Ist das Sperren eines ganzen /24-Subnetzes zu aggressiv?: Für einen Bereich, der Ihnen gerade hunderte Fehlanmeldungen geschickt hat, selten. Angriffsverkehr kommt aus Hosting- und VPS-Bereichen, in denen Nachbaradressen demselben Betreiber gehören; Privatnutzer teilen sich fast nie ein /24 mit einem Scanner. Mit einer Whitelist für Ihre Büros und VPN-Ausgänge liegt die Fehlerquote nahe null.