Schützt Windows Firewall vor RDP-Brute-Force?

Eine verbreitete Annahme unter Windows-Administratoren lautet: Die Windows-Firewall ist aktiv, RDP läuft auf TCP-Port 3389 – das reicht. Tut es nicht. Die Windows-Firewall filtert auf OSI-Layer 3 und 4. Sie entscheidet, ob ein Paket einen Port erreichen darf. Sobald eine TCP-Verbindung zum Port 3389 zugelassen ist, tritt die Firewall aus dem Spiel. Der anschließende Authentifizierungs-Handshake – jener Teil, in dem ein Angreifer Administrator mit Password123 versucht, dann mit Password1234, dann mit zehntausend weiteren – läuft oberhalb des Sichtfeldes der Firewall.

Genau in dieser Lücke leben RDP-Brute-Force-Angriffe. Wer einen Windows Server mit erreichbarem RDP betreibt, findet in diesem Artikel präzise, was die integrierte Firewall leistet, was sie nicht sehen kann und was ergänzt werden muss, damit wiederholte Anmeldeversuche tatsächlich gestoppt werden.

Was leistet Windows Firewall tatsächlich für RDP?

Die Windows Defender Firewall ist ein zustandsorientierter (stateful) Paketfilter. Laut dem offiziellen Microsoft-Überblick prüft sie Pakete anhand von Quell-IP, Ziel-IP, Port und Protokoll und entscheidet regelbasiert über Zulassen oder Blockieren. Für RDP lautet die relevante Regel fast immer: "Eingehend TCP 3389 erlauben."

Das ist nützlich. Es bedeutet konkret:

• RDP lässt sich auf einen bestimmten Quell-IP-Bereich beschränken, etwa die statische öffentliche IP des Büros.
• Port 3389 kann auf der internetseitigen Netzwerkschnittstelle komplett geblockt, im Management-VLAN aber freigegeben werden.
• Regeln lassen sich mit den Profilen Öffentlich, Privat und Domäne kombinieren, sodass ein Laptop im Café-WLAN automatisch strenger filtert.

Arbeitet das Team von einer einzigen statischen IP aus, ist diese IP-basierte Beschränkung tatsächlich robust. Der Angreifer erreicht nicht einmal die Anmeldemaske. Das Problem: Die meisten realen Umgebungen sehen nicht so aus. Admins arbeiten von zu Hause, aus Mobilfunknetzen, aus Kundenbüros. Quell-IP-Filterung wird unpraktikabel, sobald die Quelle ständig wechselt.

In der Praxis bleibt Port 3389 deshalb gegenüber einem breiten Bereich – oder gegenüber dem gesamten Internet – offen. Sobald das der Fall ist, ist die Arbeit der Firewall erledigt. Alles, was danach kommt – Benutzernamen, Passwörter, Kontosperren, Audit-Logs – geschieht in einer Schicht, die die Firewall nicht liest.

Schützt Windows Firewall vor Brute-Force-Angriffen?

Nein. Diese Fehlannahme verdient eine klare Korrektur.

Ein Brute-Force-Angriff gegen RDP versucht nicht, eine Schwachstelle auf Netzwerkebene auszunutzen. Er öffnet eine völlig reguläre TCP-Verbindung zu 3389, schließt den Handshake ab und beginnt anschließend auf der Anwendungsebene mit dem Raten von Zugangsdaten. Aus Sicht der Firewall sieht das identisch zu einer normalen Benutzeranmeldung aus. Gleicher Port. Gleiches Protokoll. Gleiche Paketform.

Jeder fehlgeschlagene Anmeldeversuch erzeugt einen Eintrag mit Event ID 4625 im Windows-Sicherheitsereignisprotokoll. Genau dieses Signal sollte man auswerten – eine IP, die in wenigen Minuten Dutzende oder Hunderte 4625-Einträge erzeugt, ist ein laufender Brute-Force-Versuch. Aber die Windows-Firewall liest das Ereignisprotokoll nicht. Sie kennt das Konzept "diese IP hat 200-mal vergeblich versucht, sich anzumelden" nicht. Sie kann Authentifizierungsfehler nicht in Firewall-Regeln überführen.

CISA hat RDP konsequent als eines der am häufigsten angegriffenen Protokolle im Internet eingestuft – insbesondere in AA22-137A, das erreichbares RDP als routinemäßig ausgenutzten Initial-Access-Vektor aufführt. Incident-Response-Daten bestätigen dieses Bild: Der Sophos Active Adversary Report hat externe Remotezugriffsdienste – hauptsächlich RDP – über mehrere Jahre hinweg als führenden Initial-Access-Vektor in realen Angriffsfällen identifiziert. Das sind Brute-Force- und Credential-Stuffing-Angriffe gegen erreichbares RDP – exakt jene Bedrohung, die die Firewall allein nicht stoppen kann.

Warum kann Windows Firewall RDP-Brute-Force nicht allein stoppen?

Drei strukturelle Gründe, die es zu verstehen lohnt:

Sie zählt fehlgeschlagene Anmeldungen nicht. Eine Firewall-Regel ist statisch. Sie lässt Verkehr von einer IP entweder zu oder blockiert ihn. Sie führt nicht Buch darüber, wie viele Sitzungen diese IP geöffnet hat, wie viele davon in LogonFailure endeten oder wie schnell sie aufeinander folgen.

Sie kann IPs nicht dynamisch blockieren. Eine Sperre lässt sich manuell für eine einzelne IP hinzufügen, aber das ist reaktiv und nachgelagert – und moderne Brute-Force-Tools rotieren durch Hunderte oder Tausende Quell-IPs. Manuelles Blockieren skaliert nicht.

Die Kontosperre ist kein Ersatz. Windows enthält in der lokalen Sicherheitsrichtlinie die Einstellung Account Lockout Threshold. Der Standardwert ist 0 – Konten werden nie gesperrt. Aktiviert man sie, etwa Sperre nach 5 Fehlversuchen, hat man den Brute-Force für dieses Konto gestoppt, dem Angreifer aber gleichzeitig ein Denial-of-Service-Werkzeug in die Hand gegeben. Das echte Administrator-Konto lässt sich von überall im Internet auf Knopfdruck aussperren. Die IP versucht es weiter. Bestraft wird nur der Benutzername.

Network Level Authentication (NLA), seit Windows Vista und Windows Server 2008 verfügbar, hilft teilweise. NLA verlangt, dass der Client sich authentifiziert, bevor eine volle RDP-Sitzung aufgebaut wird. Das senkt den Ressourcenaufwand pro Fehlversuch und blockiert einige Vor-Authentifizierungs-Exploits. Doch NLA akzeptiert weiterhin Passwortversuche – nur eben in CredSSP eingepackt. Ein Brute-Force-Tool, das CredSSP spricht, ist nicht schwerer zu schreiben als eines ohne. NLA ist notwendig, aber nicht ausreichend.

Wer den Angriffsmechanismus genauer verstehen will: Was ist ein RDP-Brute-Force-Angriff?

Was ergänzt dedizierter RDP-Brute-Force-Schutz?

Das fehlende Element ist ein Prozess, der das Sicherheitsereignisprotokoll in Echtzeit beobachtet, Fehlversuche pro Quell-IP zählt und eine Windows-Firewall-Regel schreibt, sobald eine IP einen Schwellenwert überschreitet.

Mehr ist die Aufgabe nicht. Klingt einfach, ist es architektonisch auch – aber zuverlässig erledigen (4625-Events korrekt parsen, die Quell-IP aus dem richtigen Feld extrahieren, IPv6 berücksichtigen, Sperren über Neustarts hinweg erhalten, legitime Nutzer mit Tippfehler nicht treffen) ist der Punkt, an dem dedizierte Werkzeuge ihre Daseinsberechtigung haben.

BruteFence macht genau das. Das Tool beobachtet die zu RDP gehörenden Event-ID-4625-Einträge, zählt Fehlversuche pro Quell-IP und fügt der Windows-Firewall eine Sperrregel für die IP hinzu, sobald ein konfigurierbarer Schwellenwert überschritten wird – typischerweise zwischen 3 und 10 Fehlversuchen. Geblockt wird weiterhin durch die Firewall. BruteFence liefert ihr nur die Information, die sie selbst nicht sammeln kann.

Der entscheidende Unterschied zur Account Lockout Policy: BruteFence sperrt die IP, nicht das Konto. Das echte Administrator-Konto bleibt nutzbar. Der Angreifer, woher auch immer er kommt, bekommt schlicht keine Pakete mehr durch.

Die Installation dauert etwa 5 Minuten, läuft vollständig auf dem Server ohne Cloud-Abhängigkeit und benötigt im Normalbetrieb rund 1 % CPU. Es gibt eine 7-tägige kostenlose Testphase, falls man die Sperrregeln live in der eigenen Firewall erscheinen sehen möchte. Eine Schritt-für-Schritt-Anleitung findet sich im Artikel BruteFence installieren.

Das ist kein Ersatz für die Windows-Firewall – es ist eine Steuerung dafür.

Sollte man Windows Firewall trotzdem behalten?

Ja, ohne Frage. Der richtige Rahmen ist gestaffelte Verteidigung, kein Entweder-Oder. Was jede Schicht leistet:

| Schicht | Aufgabe | Grenzen | |---|---|---| | Windows Firewall | Blockiert Pakete nach IP, Port, Protokoll | Sieht keine Authentifizierungsfehler | | Account Lockout Policy | Sperrt Konto nach N Fehlversuchen | Sperrt auch legitime Nutzer; blockiert keine IP | | Network Level Authentication | Verlangt Vor-Authentifizierung vor RDP-Sitzung | Akzeptiert weiterhin unbegrenzte Passwortversuche | | Dedizierter Schutz (BruteFence) | Sperrt Angreifer-IP automatisch ab Schwellenwert | Ersetzt keine Netzwerksegmentierung und kein MFA |

Eine vernünftige Windows-Server-Konfiguration nutzt alle vier. Die Firewall ist die Grundlage. NLA ist Pflicht. Die Kontosperre wird mit Augenmaß gesetzt – Schwellen hoch genug, Sperrdauern kurz genug, damit echte Nutzer nicht leiden. Und ein dediziertes Brute-Force-Tool schließt die Lücke, die keine andere Schicht schließen kann.

Eine vollständige geschichtete Checkliste bietet die Windows-Server-Sicherheits-Checkliste 2026.

Wie konfiguriert man Windows Firewall korrekt für RDP?

Auch mit einem dedizierten Werkzeug zählt die Firewall-Konfiguration. Fünf praktische Schritte:

1. Quell-IP einschränken, wo immer möglich. RDP-Eingangsregel in wf.msc öffnen, auf den Reiter "Bereich" (Scope) wechseln und bekannte gute IP-Bereiche unter "Remote-IP-Adresse" eintragen. Selbst die Einschränkung von Beliebig auf den eigenen Länder-IP-Block reduziert die Angriffsfläche deutlich.

2. RDP an konkrete Netzwerkschnittstellen binden. Auf einem Server mit mehreren NICs (eine Management-, eine öffentliche Schnittstelle) im Firewall-Regelreiter "Schnittstellentypen" oder "Profile" RDP nur auf dem Management-Profil zulassen. Azure- und AWS-Server haben oft ein dediziertes Management-Subnetz – nutzen.

3. RDP-Port wechseln – aber nicht überschätzen. Verschiebt man RDP von 3389 auf einen hohen Port, sinkt das Rauschen von ungezielten Scannern. Einen entschlossenen Angreifer hält das nicht auf, er findet den neuen Port innerhalb von Stunden. Als Lärmreduktion sinnvoll, als Sicherheitsmaßnahme nicht.

4. Firewall-Logging aktivieren. Unter Erweiterte Einstellungen → Eigenschaften → Protokollieren die pfirewall.log für verworfene Pakete aktivieren. Nützliches Beweismaterial im Abgleich mit 5 Anzeichen eines laufenden Brute-Force-Angriffs.

5. Wenn IP-Filterung nicht funktioniert, dediziertes Werkzeug ergänzen. Müssen Admins tatsächlich von überall verbinden, ist Quell-IP-Filterung praktisch unbrauchbar. Genau das ist der Fall, in dem dedizierter RDP-Brute-Force-Schutz einsteigt – die dynamische Sperre, die die Firewall nicht leisten kann.

Was sollten Sie jetzt sofort tun?

Ereignisanzeige auf dem Windows Server öffnen. Zu Windows-Protokolle → Sicherheit navigieren. Das aktuelle Protokoll nach Event-ID 4625 filtern. Die letzten 24 Stunden anschauen.

Liegt die Zahl im Dutzend- oder dreistelligen Bereich, lässt die Windows-Firewall genau diese Versuche derzeit durch – mehr kann sie nicht. Jeder dieser Einträge ist eine Verbindung, die die Firewall akzeptiert hat, eine Authentifizierung, die sie nicht sehen konnte, und ein Fehlschlag, auf den sie nicht reagiert hat.

Das ist die fehlende Schicht. Sie zu ergänzen heißt nicht, die Firewall zu ersetzen. Es heißt, ihr die Augen zu geben, die sie nicht hat.

Wenn Sie sehen möchten, was auf Ihrem Server passiert, testen Sie BruteFence 7 Tage kostenlos.