RDP vor DDoS-Angriffen und Bruteforce schützen

Ein Windows-Server mit offenem Remotedesktop hat nicht ein Problem, sondern zwei, und sie werden fast immer verwechselt. Das eine ist ein Bruteforce-Angriff: Jemand probiert Benutzernamen und Kennwörter durch, das Sicherheitsprotokoll füllt sich mit fehlgeschlagenen Anmeldungen, und der Server bleibt dabei die ganze Zeit erreichbar. Das andere ist ein DDoS-Angriff: Jemand erzeugt so viele halboffene Verbindungen oder so viel Verkehr, dass Port 3389 überhaupt nicht mehr antwortet, und dabei versucht niemand, sich anzumelden. Für den Betreiber fühlt sich beides identisch an, nämlich als "RDP geht nicht mehr". Die Gegenmaßnahmen sind aber gegenläufig, und wer sie verwechselt, sperrt entweder sich selbst aus oder lässt die falsche Lücke offen.

Dieser Beitrag ordnet den DDoS-Schutz für RDP aus Betreibersicht. Er erklärt, was RDP auf der Leitung tatsächlich tut, welche Ports dazugehören, wie sich Bruteforce, Anmeldeflut und echter volumetrischer Angriff an ihren Signaturen sicher auseinanderhalten lassen, was eine SYN-Flut gegen Port 3389 in Windows auslöst, welche Firewallregeln und Richtlinien wirklich etwas bewirken, welche vielzitierten Registrierungswerte seit Windows Server 2008 wirkungslos sind, und wo die Grenze verläuft, ab der keine Einstellung im Server mehr hilft. Wenn Ihr Server gerade nicht antwortet, springen Sie direkt zum Abschnitt "Was im laufenden Angriff zu tun ist".

Warum RDP-Server angegriffen werden

RDP steht für Remote Desktop Protocol und ist das Protokoll, mit dem Windows einen kompletten Arbeitsplatz über das Netz ausliefert. Es ist damit der einzige Dienst auf einem gewöhnlichen Windows-Server, bei dem ein einziges erfolgreiches Kennwort die vollständige Kontrolle über die Maschine bedeutet. Genau deshalb steht er ganz oben auf jeder Scannerliste.

Wie zentral RDP für Angreifer ist, zeigt der Sophos Active Adversary Report 2025, der 413 untersuchte Vorfälle aus dem Jahr 2024 auswertet. RDP wurde in 84 Prozent aller Fälle von den Angreifern genutzt, in 67 Prozent ausschließlich für die seitliche Bewegung im internen Netz und in 3 Prozent ausschließlich von außen. Rechnet man die Fälle mit beiden Nutzungsarten hinzu, kommt man auf 83 Prozent intern und 19 Prozent extern. Als Ursache für den Erstzugang nennt derselbe Bericht kompromittierte Zugangsdaten mit 41 Prozent, ausgenutzte Schwachstellen mit 22 Prozent und Bruteforce mit 21 Prozent.

Für die Frage nach DDoS folgt daraus eine wichtige Unterscheidung: Der überwiegende Teil dessen, was auf einem RDP-Server nach Angriff aussieht, ist keine Überlastattacke, sondern eine Übernahmeattacke. Ein DDoS-Angriff will Ihren Dienst wegnehmen, ein Bruteforce-Angriff will ihn haben. Wer aus Sorge vor DDoS die Kontosperrung scharf stellt und aus Sorge vor Bruteforce die Verbindungen begrenzt, hat beide Male die falsche Stellschraube gedreht.

RDP technisch: was beim Verbindungsaufbau passiert

RDP lauscht in der Voreinstellung auf Port 3389 TCP. Seit RDP 8.0, also seit Windows 8 und Windows Server 2012, kommt zusätzlich Port 3389 UDP als beschleunigter Transport für Grafik, Eingabe und Multimedia dazu. Microsoft führt in der Portübersicht zu den Remotedesktopdiensten beide gemeinsam auf: "TCP and UDP 3389: Standard Remote Desktop Protocol (RDP) port." Scheitert der UDP-Weg, fällt die Sitzung auf TCP zurück. Diese Doppelnatur ist für die Angriffsbetrachtung entscheidend, weil TCP und UDP völlig unterschiedlich angreifbar sind.

Der Verbindungsaufbau läuft nach der Microsoft-Spezifikation MS-RDPBCGR in einer festen Reihenfolge ab, und jede Stufe kostet den Server mehr als die vorige:

1. TCP-Handschlag. Drei Pakete, SYN, SYN-ACK, ACK. Der Server legt für ein eingehendes SYN einen Eintrag in der Warteschlange für halb geöffnete Verbindungen an. Das ist der billigste Punkt für einen Angreifer und der teuerste für den Server, gemessen am Verhältnis.
2. X.224 Connection Request. Der Client sendet einen TPKT-Kopf, die X.224-Verbindungsanforderung, optional eine Weiterleitungskennung in der Form mstshash= und eine Struktur namens RDP_NEG_REQ. Deren Feld requestedProtocols sagt, welche Sicherheitsschicht der Client sprechen will: die alte RDP-Sicherheit, TLS oder PROTOCOL_HYBRID mit dem Wert 0x00000002, was CredSSP und damit die Netzwerkebenen-Authentifizierung bedeutet.
3. X.224 Connection Confirm. Der Server antwortet mit seiner Wahl oder mit einer Fehlerstruktur, falls er keines der angebotenen Protokolle unterstützt.
4. TLS- und CredSSP-Handschlag. Erst hier werden Zugangsdaten geprüft. Das kostet Rechenzeit für die Krypto und einen Zertifikatsvorgang.
5. MCS Connect Initial. Danach beginnt die eigentliche RDP-Sitzung, gegebenenfalls nach einem Early User Authorization Result PDU.

Die Netzwerkebenen-Authentifizierung, kurz NLA, verschiebt die Kennwortprüfung auf Stufe 4 und verhindert, dass für einen anonymen Verbindungsversuch eine Sitzung, ein Anmeldebildschirm und der dazugehörige Arbeitsspeicher entstehen. Das ist ein echter Gewinn gegen Anmeldefluten und der Grund, warum NLA in jeder Härtungsanleitung steht, unter anderem in unserem Beitrag RDP absichern unter Windows Server. Gegen eine SYN-Flut hilft NLA dagegen überhaupt nicht, denn die bleibt auf Stufe 1 stehen und erreicht Stufe 2 nie. Diesen Unterschied muss man kennen, sonst erwartet man von der richtigen Maßnahme die falsche Wirkung.

Die Ports rund um RDP im Überblick

Die folgende Tabelle listet die Ports, die Microsoft in der offiziellen Portübersicht für die Remotedesktopdienste nennt. Sie beantwortet die häufigste Ausgangsfrage vor jeder Firewallregel, nämlich was überhaupt offen sein muss.

Die praktische Kernaussage dieser Tabelle steht in der letzten Spalte: Für einen Fernzugriff von außen ist genau ein Port vorgesehen, nämlich 443 TCP über ein RD-Gateway, und wer das nicht einsetzt, nimmt stattdessen ein VPN. Port 3389 direkt im Internet ist in keiner dieser Zeilen der vorgesehene Weg, sondern die Abkürzung, die sich die meisten Betreiber nehmen.

Bruteforce, Anmeldeflut oder DDoS: die Abgrenzung, auf die alles ankommt

Drei völlig verschiedene Vorgänge erzeugen auf einem RDP-Server dasselbe Symptom. Sie unterscheiden sich daran, auf welcher Stufe des Verbindungsaufbaus sie stehen bleiben, und genau daran erkennt man sie auch.

Fall 1: Bruteforce gegen die Anmeldung

Ein Bruteforce-Angriff baut jede Verbindung vollständig auf, kommt also bis Stufe 4, und probiert dort Zugangsdaten durch. Er verbraucht kaum Bandbreite. Zehn Versuche pro Sekunde sind weniger als 1 Mbit/s und für die Leitung vollkommen unauffällig. Der Server bleibt erreichbar, echte Nutzer merken oft gar nichts, und trotzdem ist das der gefährlichere der drei Fälle, weil er auf Übernahme zielt und nicht auf Ausfall.

Signatur im Sicherheitsprotokoll: viele Ereignisse mit der ID 4625 (fehlgeschlagene Anmeldung). Dazu Ereignis 4740, sobald eine Kontosperrung greift. Eine erfolgreiche Remotedesktop-Anmeldung trägt die ID 4624 mit Anmeldetyp 10. Im Protokoll Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational steht Ereignis 131 für jede angenommene TCP-Verbindung samt Quelladresse und Ereignis 140 für einen Anmeldefehler mit Quelladresse. Ereignis 140 hat eine Eigenheit, die man kennen muss: Es wird nur dann geschrieben, wenn der versuchte Benutzername auf dem System oder in der Domäne nicht existiert. Probiert jemand gültige Benutzernamen durch, bleibt 140 aus, und Sie sind auf 4625 zusammen mit 131 angewiesen.

Signatur im Netz: wenige Quelladressen mit sehr vielen vollständigen Verbindungen, oder sehr viele Quelladressen mit je wenigen Versuchen, wenn der Angreifer verteilt vorgeht. In beiden Fällen ist die Paketrate niedrig und die mittlere Paketgröße normal.

Was dagegen hilft: Kontosperrung, starke Kennwörter, NLA, Adressbeschränkung. Was nicht hilft: alles, was an der Verbindungsrate dreht, denn ein Bruteforce-Angriff hält sich ohne Mühe an jede Ratenbegrenzung, die Sie einem echten Nutzer noch zumuten wollen. Die vollständige Anleitung dazu steht in RDP absichern unter Windows Server, den Weg aus einer ausgelösten Sperre beschreibt RDP-Fehler: Konto gesperrt.

Fall 2: Anmeldeflut und Verbindungsflut

Eine Anmeldeflut ist ein Angriff auf Layer 7, der wie gewöhnlicher Verkehr aussieht, weil er gewöhnlicher Verkehr ist, nur in falscher Menge. Der Angreifer baut vollständige TCP-Verbindungen auf und lässt den Server jedes Mal bis zum TLS- und CredSSP-Handschlag arbeiten, bricht dann ab und beginnt von vorn. Das ist deutlich teurer als ein Bruteforce-Versuch, weil jede Verbindung eine Krypto-Aushandlung auslöst, und deutlich billiger als ein volumetrischer Angriff, weil die Bandbreite gering bleibt.

Signatur im Sicherheitsprotokoll: auffällig wenige 4625-Ereignisse im Verhältnis zur Last. Genau das ist der Fingerzeig. Wenn die CPU steigt, der Dienst hakt, aber kaum fehlgeschlagene Anmeldungen protokolliert werden, kommt der Verkehr gar nicht bis zur Anmeldung. Im RdpCoreTS-Protokoll steigt dagegen die Zahl der 131-Ereignisse stark an, denn jede angenommene Verbindung wird dort vermerkt.

Signatur im Netz: viele kurzlebige, vollständig aufgebaute Verbindungen zu Port 3389, häufig aus wenigen hundert Quelladressen. Die Zahl der Verbindungen im Zustand Established schwankt stark, die Zahl im Zustand SynReceived bleibt niedrig.

Was dagegen hilft: Adressbeschränkung und Begrenzung gleichzeitiger Sitzungen. Die Windows-Firewall kann keine Verbindungsrate begrenzen, sie kennt diese Funktion schlicht nicht. Eine wirksame Ratenbegrenzung je Quelladresse gibt es für RDP deshalb nur vor dem Server, nicht in ihm.

Fall 3: Volumetrischer DDoS-Angriff

Ein volumetrischer Angriff kümmert sich nicht darum, dass auf Port 3389 ein Dienst lauscht. Er füllt die Leitung, und Ihr RDP wird unerreichbar, weil davor kein Platz mehr ist. Der Angriffsverkehr muss dafür nicht einmal an Port 3389 gerichtet sein: Ein UDP-Flood gegen einen beliebigen Port derselben IP-Adresse hat exakt dieselbe Wirkung. Die Grundlagen dazu stehen in Was ist ein DDoS-Angriff.

Signatur im Sicherheitsprotokoll: keine. Das ist die wichtigste Einzelaussage dieses Abschnitts. Ein volumetrischer Angriff hinterlässt im Sicherheitsprotokoll überhaupt keine Spur, weil kein einziges Paket bis zur Anmeldung kommt. Wer in der Ereignisanzeige nach dem Beweis für einen DDoS-Angriff sucht, sucht am falschen Ort.

Signatur im Netz: hohe Paketrate bei normaler oder niedriger CPU-Last, steigende Verwurfszähler auf der Netzwerkkarte, und der Dienst antwortet über 127.0.0.1 normal, von außen aber nicht. Die mittlere Paketgröße verrät die Bauart: Bytes geteilt durch Pakete unter 100 Byte deutet auf einen Protokollangriff, über 1.000 Byte auf einen Verstärkungsangriff.

Was dagegen hilft: ausschließlich Filterung im Netz vor dem Server. Jede Firewallregel auf dem Server entscheidet über ein Paket, das bereits über das Kabel gelaufen ist.

Die drei Fälle an ihren Signaturen unterscheiden

Die Zeile, die in der Praxis am schnellsten Klarheit schafft, ist die vorletzte: Sind andere Dienste auf derselben IP-Adresse ebenfalls weg, ist es die Leitung und nicht RDP. Antwortet dagegen ein Webserver auf derselben Maschine weiterhin normal, während nur 3389 hängt, haben Sie ein RDP-Problem und kein Bandbreitenproblem. Diese eine Prüfung ersetzt eine halbe Stunde Protokolllesen. Der ausführliche Messablauf steht in DDoS-Angriff erkennen.

SYN-Flut gegen Port 3389 und die halboffene Verbindung

Hier liegt der Unterschied, der RDP von einem UDP-Spieldienst trennt. RDP spricht in erster Linie TCP, und TCP kennt einen Zustand, den UDP nicht hat: die halb geöffnete Verbindung.

Eine SYN-Flut ist ein Angriff, bei dem der Angreifer TCP-Pakete mit gesetztem SYN-Bit und gefälschter Absenderadresse schickt. Der Server legt für jedes Paket einen Eintrag in der Warteschlange für halb geöffnete Verbindungen an, antwortet mit SYN-ACK an eine Adresse, die nie geantwortet hat, und wartet. Das dritte Paket des Handschlags kommt nie. Der Eintrag bleibt liegen, bis er abläuft.

Die Asymmetrie ist brutal. Ein SYN-Paket ist auf der Leitung so klein, wie ein Ethernet-Rahmen überhaupt sein darf, nämlich 64 Byte einschließlich Prüfsumme, und kostet den Angreifer nichts. Der Server muss dafür Speicher belegen, eine Antwort erzeugen, einen Zeitgeber starten und die Antwort mehrfach wiederholen. Bei 1 Gbit/s passen rund 1,49 Millionen solcher Pakete pro Sekunde auf die Leitung. Jede Warteschlange, die mit einigen tausend Plätzen arbeitet, ist damit rechnerisch in unter einer Millisekunde voll. Praktisch geben Netzwerkkarte und Kernel schon deutlich vorher auf.

Zwei Eigenschaften machen eine SYN-Flut für den Verteidiger besonders unangenehm. Erstens lässt sich die Absenderadresse fälschen, weil der Angreifer die Antwort nie sehen muss. Eine Sperrliste nach Quelladresse geht deshalb ins Leere, denn die Adressen sind erfunden und ändern sich mit jedem Paket. Zweitens braucht der Angriff kaum Bandbreite, wenn nur die Tabelle das Ziel ist. Ein Anschluss, der im Bandbreitendiagramm ruhig aussieht, kann trotzdem unter einer SYN-Flut stehen.

Was Windows bei einer SYN-Flut tut

Windows hat seit Windows Vista und Windows Server 2008 einen eingebauten SYN-Angriffsschutz. Microsoft beschreibt ihn in der eigenen Dokumentation zur Härtung des TCP/IP-Stapels mit drei Eigenschaften:

• Der Schutz ist ab Werk eingeschaltet und lässt sich nicht abschalten.
• Er berechnet seine Schwellenwerte dynamisch aus der Anzahl der CPU-Kerne und dem verfügbaren Arbeitsspeicher und stellt deshalb bewusst keine konfigurierbaren Parameter über die Registrierung, über netsh oder sonstwie bereit.
• Weil der Treiber anhand dieser Ressourcen entscheidet, beginnt ein System mit mehr Kernen und mehr Arbeitsspeicher später mit dem Verwerfen neuer Verbindungsversuche als ein kleines System. Der Algorithmus ist ausdrücklich so gebaut, dass keine Feinabstimmung nötig ist.

Geht Windows in den Angriffszustand, verwirft es neue Verbindungsanfragen, sobald die intern errechnete Schwelle erreicht ist. Für Ihre Nutzer sieht das so aus: Die Verbindung läuft in eine Zeitüberschreitung, ohne dass irgendeine Fehlermeldung von RDP kommt, und ein zweiter Versuch funktioniert manchmal. Bestehende Sitzungen laufen weiter, neue kommen nicht zustande.

Und jetzt der Teil, den kaum eine Anleitung erwähnt: Windows meldet Ihnen nicht, dass der SYN-Angriffsschutz ausgelöst hat. Es gibt dafür kein Ereignis in der Ereignisanzeige und keinen eigenen Zähler. Sie können den Zustand nur indirekt an drei Werten ablesen, und die lohnt es zu kennen:

Get-NetTCPConnection -State SynReceived | Measure-Object | Select-Object -ExpandProperty Count
Get-NetTCPConnection -LocalPort 3389 -State Established -ErrorAction SilentlyContinue | Measure-Object | Select-Object -ExpandProperty Count
Get-NetAdapterStatistics | Select-Object Name, ReceivedBytes, ReceivedUnicastPackets, ReceivedDiscardedPackets

Der erste Befehl zählt die halb geöffneten Verbindungen. Ein zweistelliger Wert ist auf einem gewöhnlichen Server normal, ein vier- oder fünfstelliger ist eine SYN-Flut. Der zweite zeigt, wie viele RDP-Sitzungen tatsächlich stehen. Der dritte liefert die Netzwerkzähler, und zwar mit sprachneutralen Eigenschaftsnamen. Das ist kein Detail: Die Zählerpfade für Get-Counter sind in Windows übersetzt, ein englisch geschriebener Zählerpfad scheitert auf einem deutschen System. Get-NetAdapterStatistics hat dieses Problem nicht.

Messen Sie diese drei Werte einmal im Normalbetrieb und legen Sie sie ab. Ohne Vergleichswert können Sie im Ernstfall nicht sagen, ob 3.000 halb geöffnete Verbindungen viel sind oder Montagmorgen.

Registrierungswerte gegen SYN-Fluten: was wirklich noch gilt

Im Netz kursiert eine Liste von Registrierungswerten, die angeblich Windows gegen SYN-Fluten härtet. Sie stammt aus einer Anleitung für Windows Server 2003 und wird seitdem von Anbieter zu Anbieter weitergereicht. Diese Werte haben auf jedem heute unterstützten Windows keine Wirkung mehr. Microsoft hat das zweimal ausdrücklich dokumentiert: einmal für die TCP/IP-Werte, einmal für die Werte des AFD-Treibers, bei denen die zugehörige Logik im Quelltext sogar entfernt wurde.

Die drei wirksamen Werte aus den unteren Zeilen prüfen Sie so:

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

Halten Sie sich an diese Trennung. Ein gesetzter Wert, der nichts tut, ist schlimmer als kein Wert, weil Sie danach glauben, geschützt zu sein. Wie Sie den Port sauber und ohne Neustart umstellen, steht in RDP-Port ohne Neustart ändern. Der Umgang mit NLA und den typischen Folgefehlern ist in RDP-Fehler: Authentifizierung auf Netzwerkebene beschrieben.

Warum das Verschieben des Ports Scanner abhält, aber kein Schutz ist

Ein anderer Port als 3389 ist eine Lärmschutzmaßnahme, keine Sicherheitsmaßnahme. Das ist kein Widerspruch, sondern eine präzise Aussage über die Wirkung, und beide Hälften stimmen.

Was es bringt. Die große Masse der automatisierten Scanner arbeitet Adressbereiche ab und prüft genau Port 3389. Ist dort nichts, ziehen sie weiter. Der messbare Effekt ist erheblich: Die Zahl der 4625-Ereignisse fällt auf einem betroffenen Server typischerweise um Größenordnungen, und die Ereignisanzeige wird wieder lesbar. Das ist kein kosmetischer Gewinn. Ein Sicherheitsprotokoll, das unter Bruteforce-Rauschen in Stunden überrollt, überschreibt genau die Einträge, die Sie im Ernstfall brauchen.

Was es nicht bringt. Gegen einen gezielten Angreifer wirkt der Portwechsel nicht. Ein vollständiger Portscan über alle 65.535 Ports dauert Sekunden, und Suchmaschinen für offene Dienste erkennen RDP am Protokoll-Fingerabdruck unabhängig vom Port: Wer eine X.224-Verbindungsanforderung schickt und eine gültige Verbindungsbestätigung zurückbekommt, weiß, dass dort RDP läuft, ganz gleich auf welcher Nummer.

Und gegen DDoS wirkt er gar nicht. Ein volumetrischer Angriff richtet sich gegen Ihre IP-Adresse, nicht gegen eine Portnummer. Der Angriff vom Mai 2025, den Cloudflare dokumentiert hat, verteilte sich im Schnitt über 21.925 Zielports gleichzeitig, in der Spitze über 34.517. Wer sich vor so etwas auf einem anderen Port versteckt, versteckt sich vor niemandem.

Fazit für die Praxis: Verschieben Sie den Port, aber als Ergänzung und nie als Ersatz. Und legen Sie die Firewallregel für den neuen Port an, bevor Sie den Dienst umstellen, sonst sperren Sie sich aus. Die eingebauten Remotedesktop-Regeln von Windows sind fest auf 3389 gebunden und greifen nach einem Portwechsel nicht mehr.

Die andere Rolle: RDP als Verstärker gegen Dritte

Ein Punkt, der in RDP-Anleitungen praktisch nie vorkommt, obwohl er direkt in dieses Thema gehört: Ein RDP-Server mit offenem UDP-Port 3389 kann nicht nur Opfer, sondern auch Waffe sein.

NETSCOUT hat im Januar 2021 beschrieben, dass der RDP-Dienst auf UDP/3389 für Reflexions- und Verstärkungsangriffe missbraucht werden kann. Die Zahlen sind eindeutig: Der Verstärkungsfaktor liegt bei 85,9 zu 1. Die erzeugten Antwortpakete sind durchgehend 1.260 Byte groß und mit langen Ketten von Nullen aufgefüllt. Zum Zeitpunkt der Veröffentlichung wurden rund 33.000 missbrauchbare Windows-RDP-Server gezählt, und die damit beobachteten Angriffe lagen zwischen etwa 20 Gbit/s und 750 Gbit/s. Das Verfahren wurde in die Werkzeugkästen kommerzieller Angriffsdienste aufgenommen.

Ein Verstärkungsangriff funktioniert so: Der Angreifer schickt eine kleine Anfrage an Ihren offenen UDP-Dienst und trägt als Absender die IP-Adresse seines Opfers ein. Ihr Server antwortet pflichtgemäß, nur eben an das Opfer, und die Antwort ist 85,9-mal größer als die Anfrage. Für Sie als Betreiber hat das drei Folgen, die alle unangenehm sind: Ihre eigene Ausgangsbandbreite wird verbraucht, Ihre Fernzugriffsmöglichkeit kann dabei selbst ausfallen, und Ihre IP-Adresse landet auf Sperrlisten, aus denen sie schwer wieder herauskommt.

Die Gegenmaßnahme ist einfach und kostet nichts: Wenn Sie den beschleunigten UDP-Transport nicht brauchen, machen Sie UDP 3389 zu. Sie verlieren dabei nichts außer etwas Bildlaufkomfort bei hoher Laufzeit, denn RDP fällt automatisch auf TCP zurück. NETSCOUT empfiehlt in derselben Veröffentlichung ausdrücklich, RDP-Server ausschließlich über VPN erreichbar zu machen, und nennt das Schließen von UDP/3389 als Zwischenlösung für alle, die das nicht sofort umsetzen können.

Was auf dem Server selbst hilft

Auf dem Server lässt sich mehr erreichen als oft behauptet, und zwar gegen alles, was klein bleibt: Scanner, Bruteforce, einzelne Quellen und mäßige Verbindungsfluten. Alle folgenden Befehle laufen in einer PowerShell-Sitzung mit Administratorrechten auf Windows Server 2016 bis 2025, sofern nicht anders angegeben.

1. Zuerst messen, dann ändern

Sichern Sie den Ausgangszustand, bevor Sie irgendetwas anfassen. Diese vier Zeilen brauchen keine halbe Minute und beantworten hinterher die Frage, ob eine Maßnahme gewirkt hat:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-1)} -ErrorAction SilentlyContinue | Measure-Object | Select-Object -ExpandProperty Count
Get-NetTCPConnection -State SynReceived | Measure-Object | Select-Object -ExpandProperty Count
Get-NetAdapterStatistics | Select-Object Name, ReceivedBytes, ReceivedUnicastPackets, ReceivedDiscardedPackets
Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 3389 } | Get-NetFirewallRule | Select-Object DisplayName, Enabled, Profile, Action, Direction

Das -ErrorAction SilentlyContinue in der ersten Zeile gehört dazu: Get-WinEvent bricht mit einem roten Fehler ab, wenn im gewählten Zeitraum kein einziges passendes Ereignis vorliegt. Auf einem sauber abgesicherten Server ist genau das der Normalfall.

Die vierte Zeile ist die, die in der Praxis am häufigsten die Überraschung liefert. Sie listet alle Firewallregeln, die Port 3389 betreffen. Fast jedes Anbieter-Abbild und viele Softwareinstallationen legen dort eigene, weit offene Regeln an, und solange eine davon existiert, wirkt jede Einschränkung an den eingebauten Regeln nicht. Die Reihenfolge in der Pipeline ist Absicht: Dreht man sie um, dauert der Aufruf ein Vielfaches und in der Ausgabe fehlt der Regelname.

2. Den Rückweg sichern, bevor Sie eine Firewallregel anfassen

Jede Maßnahme in diesem Abschnitt kann Sie aussperren. Bei einem Server, den Sie nur über RDP erreichen, ist das das Ende der Sitzung. Drei Vorkehrungen verhindern das zuverlässig.

Erstens: Prüfen Sie, dass Sie eine netzunabhängige Konsole haben. Bei KVM-Servern von KernelHost finden Sie im Kundenbereich eine VNC-Konsole, die direkt auf den Bildschirm der virtuellen Maschine schaut. Sie funktioniert auch dann noch, wenn Firewall, RDP-Dienst und Netzwerkeinstellungen gemeinsam kaputt sind. Öffnen Sie sie einmal probeweise, bevor Sie etwas ändern, nicht danach.

Zweitens: Sichern Sie das gesamte Firewall-Regelwerk in eine Datei. Ein Rückweg in einem Befehl ist mehr wert als jede Notiz:

netsh advfirewall export "C:\firewall-vorher.wfw"

Zurückspielen lässt sich das mit netsh advfirewall import "C:\firewall-vorher.wfw", und zwar auch über die VNC-Konsole, wenn RDP nicht mehr geht.

Drittens: Lassen Sie die RDP-Sitzung, in der Sie arbeiten, während der gesamten Umstellung offen und prüfen Sie jede Änderung mit einer zweiten, neu aufgebauten Verbindung. Bestehende Sitzungen werden von neuen Firewallregeln nicht sofort getrennt, eine neue Verbindung scheitert dagegen sofort. So merken Sie den Fehler, solange Sie ihn noch zurücknehmen können.

3. Windows-Firewall: Bereichsbeschränkung auf bekannte Quelladressen

Das ist die Maßnahme, die den Angriffsverkehr auf Anwendungsebene wirklich beendet, und zwar vollständig. Sie beschränkt die eingebauten Remotedesktop-Regeln auf eine Liste erlaubter Quelladressen. Arbeiten Sie dabei mit der sprachneutralen Gruppenkennung @FirewallAPI.dll,-28752 und nicht mit dem angezeigten Gruppennamen, denn der ist übersetzt und heißt auf einem englischen System anders als auf einem deutschen. Zuerst ansehen, was betroffen sein wird:

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

Erwarten Sie mehr Treffer, als Sie Regeln erwartet hätten. Die Gruppe enthält üblicherweise mehrere Regeln je Profil. Das ist richtig so, denn sonst bliebe eine der Kopien offen. Dann setzen:

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

Und gegenlesen, welche Adressen tatsächlich gespeichert wurden:

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

Der Wirkungsnachweis von außen ist eine Zeile und sollte von einer fremden Adresse aus laufen. Das Ergebnis muss TcpTestSucceeded : False lauten:

Test-NetConnection -ComputerName 203.0.113.50 -Port 3389

4. Dieselbe Beschränkung mit netsh advfirewall

Wer lieber mit netsh arbeitet oder ein Skript für ältere Systeme braucht, legt eine eigene Regel an, statt die eingebauten anzufassen. Das ist hier sogar der robustere Weg, weil eine selbst benannte Regel keinen übersetzten Namen hat. Diese Befehle laufen in einer Eingabeaufforderung mit Administratorrechten ebenso wie in PowerShell:

netsh advfirewall firewall add rule name="RDP nur Buero" dir=in action=allow protocol=TCP localport=3389 remoteip=203.0.113.10,198.51.100.0/24 profile=any
netsh advfirewall firewall show rule name="RDP nur Buero"

Eine erlaubende Regel allein genügt allerdings nicht, solange eine zweite, offenere Regel für denselben Port existiert. Die Windows-Firewall wertet erlaubende Regeln gemeinsam aus, es gewinnt also die weiteste. Prüfen Sie deshalb mit der vierten Zeile aus Schritt 1 nach und schalten Sie die eingebauten Regeln entweder ab oder beschränken Sie sie wie in Schritt 3.

Dieselbe Syntax setzt auch eine gezielte Sperre gegen eine auffällige Quelladresse. Blockierende Regeln haben in der Windows-Firewall Vorrang vor erlaubenden:

netsh advfirewall firewall add rule name="Sperre Angreifer" dir=in action=block protocol=any remoteip=203.0.113.99

Machen Sie sich dabei über die Grenze dieser Maßnahme keine Illusionen. Eine Sperrliste hilft gegen einzelne Quellen. Gegen einen verteilten Angriff wächst keine Liste schnell genug, und jeder zusätzliche Eintrag kostet Prüfzeit auf einem System, das ohnehin schon unter Last steht.

5. UDP 3389 schließen, wenn Sie den beschleunigten Transport nicht brauchen

Nach dem Abschnitt über die Verstärkung ist das die Maßnahme mit dem besten Verhältnis von Aufwand zu Wirkung. Sie schließen damit die Verstärkerrolle und nehmen zugleich eine Angriffsfläche vom Server, denn UDP kennt keinen Verbindungsaufbau, den man verlangen könnte:

netsh advfirewall firewall add rule name="RDP UDP zu" dir=in action=block protocol=UDP localport=3389 profile=any

In PowerShell entspricht das:

New-NetFirewallRule -DisplayName 'RDP UDP zu' -Direction Inbound -Protocol UDP -LocalPort 3389 -Action Block -Profile Any

Der sauberere Weg, wenn Sie Gruppenrichtlinien einsetzen, führt über gpedit.msc: Computerkonfiguration, Administrative Vorlagen, Windows-Komponenten, Remotedesktopdienste, Remotedesktopsitzungs-Host, Verbindungen, Richtlinie "RDP-Transportprotokolle auswählen". Dort stellen Sie "Nur TCP verwenden" ein. Der Unterschied zur Firewallregel ist, dass der Dienst dann gar nicht erst auf UDP lauscht, statt dass die Pakete davor verworfen werden. Beides führt zum Ziel, die Richtlinie ist die aufgeräumtere Lösung.

Prüfen Sie anschließend, dass nichts mehr auf UDP 3389 lauscht:

Get-NetUDPEndpoint -LocalPort 3389 -ErrorAction SilentlyContinue

6. Kontosperrungsrichtlinie und ihre Kehrseite

Eine Kontosperrung ist gegen Bruteforce die wirksamste Einzelmaßnahme und gegen DDoS wirkungslos. Sie gehört trotzdem in diesen Beitrag, weil sie unter Beschuss zur Falle wird. Gesetzt wird sie in einem Aufruf, sonst lehnt Windows die Dauer ab, solange der Schwellenwert noch bei 0 steht:

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

Die Werte 10, 10 und 10 entsprechen der Empfehlung, die Microsoft im Artikel zu KB5020282 als Ausgangspunkt nennt: Sperre nach zehn Fehlversuchen innerhalb von zehn Minuten, Sperrdauer zehn Minuten. Die Sperrdauer muss immer größer oder gleich dem Beobachtungsfenster sein.

Seit den kumulativen Updates vom 11. Oktober 2022 gibt es zusätzlich die Richtlinie "Sperrung des Administratorkontos zulassen", mit der auch das eingebaute Administratorkonto unter die Sperrregel fällt. Auf neu eingerichteten Systemen ab Windows 11 22H2 ist sie bereits bei der Ersteinrichtung aktiv. Sie liegt unter Richtlinie für lokalen Computer, Computerkonfiguration, Windows-Einstellungen, Sicherheitseinstellungen, Kontorichtlinien, Kontosperrungsrichtlinien.

Die Kehrseite: Eine Kontosperrung ist auch eine Waffe gegen Sie. Wer Ihren Benutzernamen kennt, hält das Konto dauerhaft gesperrt, indem er alle zehn Minuten elf falsche Kennwörter schickt. Das ist ein Denial of Service, der mit wenigen Kilobit pro Sekunde auskommt und den kein Filter als Angriff erkennt, weil er aus gültigen, vollständigen Verbindungen besteht. Genau deshalb ist die Kontosperrung die zweite Verteidigungslinie und die Adressbeschränkung die erste.

Ein Detail entschärft den schlimmsten Fall, und es steht ausdrücklich in Microsofts eigener Beschreibung: Das neue Sperrverhalten betrifft nur Netzwerkanmeldungen wie RDP. Anmeldungen an der Konsole bleiben während der Sperrzeit erlaubt. Wer also eine VNC-Konsole im Kundenbereich hat, kommt selbst bei gesperrtem Administratorkonto noch an die Maschine.

7. Gleichzeitige Sitzungen begrenzen

Gegen eine Verbindungsflut, die keine Anmeldung versucht, ist eine harte Obergrenze für gleichzeitige Verbindungen die passende Antwort. Die Richtlinie heißt "Anzahl der Verbindungen einschränken" und liegt in gpedit.msc unter Computerkonfiguration, Administrative Vorlagen, Windows-Komponenten, Remotedesktopdienste, Remotedesktopsitzungs-Host, Verbindungen. Auf einem Server, an dem drei Personen arbeiten, gehört dort eine kleine Zahl hinein und nicht der Standardwert.

Setzen Sie außerdem Zeitgrenzen für getrennte und untätige Sitzungen, ebenfalls über Gruppenrichtlinien unter Remotedesktopsitzungs-Host, Zeitlimits für Sitzungen. Getrennte Sitzungen, die nie enden, belegen Arbeitsspeicher und Sitzungsplätze, und unter Last ist jeder belegte Platz ein Platz, den ein echter Nutzer nicht bekommt.

Wie viele Sitzungen gerade laufen und wer sie hält, zeigt der eingebaute Befehl:

query session

8. Verworfene Pakete protokollieren

Ohne Protokoll raten Sie. Die Windows-Firewall kann verworfene Verbindungen mitschreiben, tut es aber ab Werk nicht:

netsh advfirewall set allprofiles logging droppedconnections enable
netsh advfirewall set allprofiles logging maxfilesize 32767
netsh advfirewall show allprofiles logging

Die Obergrenze für die Dateigröße liegt bei 32.767 Kilobyte, mehr nimmt netsh nicht an. Unter Beschuss ist diese Datei schnell voll, deshalb schöpfen Sie den Wert aus. Die Standardablage ist %systemroot%\system32\LogFiles\Firewall\pfirewall.log, das Format ist Text mit einer Kopfzeile, die die Spalten benennt.

Geben Sie parallel dem Sicherheitsprotokoll mehr Platz, sonst überschreibt es sich unter Bruteforce innerhalb weniger Stunden selbst:

wevtutil sl Security /ms:1073741824

Und werten Sie danach aus, aus welchen Adressen die Fehlversuche kommen. Die Auswertung ü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

Für Fehlversuche mit unbekanntem Benutzernamen, bei denen im Sicherheitsprotokoll keine brauchbare Adresse steht, hilft das RDP-eigene Protokoll:

Get-WinEvent -LogName 'Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational' -FilterXPath '*[System[EventID=140]]' -MaxEvents 50 -ErrorAction SilentlyContinue | Format-List TimeCreated, Message

Die eigentliche Empfehlung: RDP gehört nicht offen ins Internet

Alle bisherigen Maßnahmen verbessern die Lage eines Servers, dessen RDP im Internet steht. Die beste Maßnahme ist, dass es dort gar nicht steht. Das ist keine Vorsichtsformel, sondern eine Umformung des Problems: Aus einem RDP-Problem wird ein VPN-Problem, und das VPN-Problem ist kleiner.

Der Grund liegt in der Bauart der Dienste. RDP muss auf einen Verbindungsversuch antworten, bevor es weiß, wer da klopft: Es schickt eine Verbindungsbestätigung, handelt TLS aus und prüft erst dann Zugangsdaten. Ein modernes VPN kann sich anders verhalten. WireGuard antwortet auf ein Paket, das keinen gültigen Schlüssel trägt, überhaupt nicht. Für einen Scanner sieht der Port aus wie nichts. Die gesamte Klasse der Bruteforce-Angriffe und der Anmeldefluten entfällt damit, nicht weil sie abgewehrt wird, sondern weil es nichts mehr gibt, woran sie ansetzen könnten.

Variante A: ein VPN davor

Der Ablauf ist immer derselbe. Sie richten den VPN-Dienst ein, testen die Verbindung, geben RDP nur noch für den Adressbereich des VPN frei und schließen 3389 im Internet vollständig. Die Reihenfolge ist wichtig: erst das VPN prüfen, dann RDP zumachen, und zwar in einer zweiten Sitzung, während die erste offen bleibt.

Die Freigabe für einen VPN-Adressbereich sieht so aus:

Set-NetFirewallRule -Group '@FirewallAPI.dll,-28752' -RemoteAddress '10.8.0.0/24'

Wie ein eigener VPN-Dienst aufgesetzt wird, beschreibt WireGuard-VPN-Server einrichten. Ob sich ein eigener Dienst gegenüber einem fertigen Angebot lohnt, wägt Eigener VPN-Server oder VPN-Dienst ab. Wichtig für diesen Beitrag: Ein VPN verlagert das Problem, es löst es nicht vollständig. Der VPN-Dienst selbst hängt weiterhin an derselben Leitung und ist derselben volumetrischen Überlast ausgesetzt. Was ein VPN erledigt, ist die Anmeldeseite. Was es nicht erledigt, ist die Leitung. Was danach am VPN-Port selbst zu tun ist, von der Handschlag-Flut bis zur Ratenbegrenzung getrennt nach Handschlag und Datenverkehr, steht in VPN-Server vor DDoS schützen.

Variante B: ein RD-Gateway auf 443

Die Microsoft-eigene Antwort auf dieselbe Frage heißt Remotedesktopgateway. Es nimmt RDP innerhalb einer HTTPS-Verbindung auf TCP 443 entgegen, prüft die Berechtigung anhand von Richtlinien und reicht die Sitzung erst danach an den eigentlichen Server weiter. Optional kommt UDP 3391 für den beschleunigten Transport dazu. Beide Portnummern lassen sich im Verwaltungswerkzeug des Gateways ändern.

Der Vorteil gegenüber einem VPN: Für Windows-Clients ist kein zusätzlicher Dienst nötig, die Gatewayadresse wird direkt in der Remotedesktopverbindung eingetragen. Der Nachteil: Ein RD-Gateway ist eine eigene Rolle mit Zertifikat, Netzwerkrichtlinienserver und Wartungsaufwand, und es steht selbst im Internet, allerdings mit einer deutlich kleineren Angriffsfläche als ein nackter 3389.

Welche Variante passt, hängt vom Umfeld ab. Für einen einzelnen Windows-VPS mit zwei oder drei Zugriffsberechtigten ist ein VPN die kürzere Strecke. Für eine Umgebung mit mehreren Sitzungshosts und wechselnden Mitarbeitern ist das RD-Gateway die sauberere Struktur. Was beide Varianten gemeinsam haben, und darauf kommt es an: Port 3389 ist danach aus dem Internet verschwunden.

Wo jede Maßnahme auf dem Server aufhört

Jetzt der Teil, den keine Richtlinie und keine Firewallregel löst. Alle bisherigen Maßnahmen laufen auf Ihrem Server, also am Ende der Leitung. Eine Firewallregel entscheidet über ein Paket, das bereits über das Kabel gelaufen ist. Sie können es verwerfen, aber nicht ungesendet machen. Ist die Leitung davor voll, kommen die Pakete Ihrer Nutzer schon vorher nicht mehr an, unabhängig davon, wie gut Ihr Regelwerk ist.

Rechnen Sie das für Ihren Fall einmal durch. Ein Windows-VPS hängt typischerweise an 1 Gbit/s. Die untere Kante der von NETSCOUT beobachteten RDP-Verstärkungsangriffe lag bei rund 20 Gbit/s. Das ist das Zwanzigfache dessen, was Ihre Leitung überhaupt transportieren kann. In diesem Bereich ist die Frage nach der richtigen Firewallregel gegenstandslos.

Es gibt noch eine zweite, unangenehmere Grenze. Sobald die Leitung gesättigt ist, erreicht Sie unter Umständen nicht einmal mehr die RDP-Sitzung, mit der Sie nachsehen wollten. Wer dann keinen netzunabhängigen Zugang hat, sieht überhaupt nichts mehr. Das ist der Grund, warum die VNC-Konsole in diesem Beitrag mehrfach vorkommt: Sie ist im Ernstfall der einzige Weg, der noch funktioniert.

Was KernelHost dagegen stellt

Der Dauerschutz, der in jedem Serverpaket enthalten ist

Der DDoS-Schutz von KernelHost ist zweistufig aufgebaut und dauerhaft aktiv, ohne dass Sie etwas einschalten, bestellen oder konfigurieren müssen:

• Stufe 1: 17 Tbps Mitigationskapazität im globalen Scrubbing-Netzwerk. Volumetrische Angriffe werden nah an ihrer Quelle bereinigt, bevor sie das Rechenzentrum erreichen.
• Stufe 2: Arbor-Echtzeitfilterung mit 3,2 Tbps in Frankfurt am Main. Direkt vor dem Server werden protokollspezifische Muster erkannt und verworfen, Paket für Paket. Für RDP heißt das konkret: SYN-Fluten und Verbindungsfluten gegen 3389 TCP sowie Reflexionsverkehr auf UDP-Basis enden dort und nicht auf Ihrer Netzwerkkarte.

Zwei Eigenschaften sind entscheidend. Der Schutz läuft permanent und ist ab der Bereitstellung des Servers aktiv, er muss einen Angriff also nicht erst erkennen, um zu wirken. Es gibt keine Minuten am Anfang, in denen der Server weg ist. Und es wird kein Nullrouting eingesetzt: Ihre IP-Adresse bleibt im Netz, verworfen werden nur die schädlichen Pakete. Wer die IP-Adresse aus dem Netz nimmt, erreicht für Sie dasselbe Ergebnis wie der Angreifer. Der Standort ist Frankfurt am Main.

Advanced DDoS Protection für dauerhaft beschossene Projekte

Manche Server werden nicht gelegentlich gestreift, sondern gezielt und über Wochen angegriffen, oft zur selben Uhrzeit und mit wechselnden Mustern. Dafür gibt es die Advanced DDoS Protection ab 50,00 € im Monat, PrePaid, ohne Mindestlaufzeit und ohne Einrichtungsgebühr. Der Unterschied liegt nicht in mehr Kapazität, sondern in der Kontrolle:

• Dedizierte Schutz-IP aus dem Frankfurter Kern, auf die Ihr Server im eigenen Netz umgestellt wird. Auf Ihrer Seite ist kein Umbau nötig.
• Selbst verwaltbare Schutzregeln je Port und Protokoll im Kundenbereich: Sie stellen getrennt ein, was auf 3389 TCP erlaubt ist, was auf 443 TCP für ein RD-Gateway und was auf dem Port Ihres VPN, und können alles andere zumachen, ohne dafür ein Ticket zu schreiben.
• Änderungen greifen in Echtzeit, Sie können also während eines laufenden Angriffs nachjustieren, statt auf ein Wartungsfenster zu warten.
• Schutzprofil passend zum Dienst, ebenso für eigene Anwendungen auf beliebigen TCP- oder UDP-Ports.

Die Advanced DDoS Protection richtet sich an KernelHost-Kunden und setzt einen Server bei KernelHost voraus. Wenn Ihr Windows-Server derzeit woanders läuft und dort regelmäßig unter Beschuss steht, ist der Umzug hierher der Weg, denn die Filterung ist Teil des Netzes und kein Zusatz, der sich auf einem fremden Server nachrüsten lässt.

Die beiden Stufen im Vergleich

Für die meisten Windows-Server reicht der inkludierte Dauerschutz zusammen mit einer sauberen Konfiguration, also NLA, Adressbeschränkung, geschlossenem UDP 3389 und RDP hinter VPN oder RD-Gateway. Die Advanced DDoS Protection ist die Antwort darauf, dass jemand es persönlich nimmt.

Was im laufenden Angriff zu tun ist, in dieser Reihenfolge

Die Reihenfolge ist wichtiger als die einzelnen Schritte, weil die folgenschwersten Fehler in den ersten fünf Minuten passieren.

1. Feststellen, ob es überhaupt die Leitung ist. Prüfen Sie von außen einen zweiten Dienst auf derselben IP-Adresse, etwa einen Webserver oder einen Ping. Antwortet der ebenfalls nicht, ist es ein Netzproblem. Antwortet er normal und nur 3389 hängt, ist es ein RDP-Problem.
2. Messen, nicht schrauben. Sichern Sie zuerst die Werte aus Get-NetTCPConnection -State SynReceived, Get-NetAdapterStatistics und die Zahl der 4625-Ereignisse in eine Datei. Nach dem Angriff sind diese Werte weg, und ohne sie kann Ihnen niemand helfen.
3. Nicht neu starten. Ein Neustart löscht alle Zähler und Verbindungszustände, und die Last ist nach wenigen Sekunden wieder da. Sie verlieren damit genau die Daten, aus denen die Filterregeln gebaut werden.
4. Die Ebene bestimmen. Viele 4625-Ereignisse bedeuten Bruteforce. Viele halb geöffnete Verbindungen bedeuten SYN-Flut. Steigende Verwurfszähler bei ruhigem Sicherheitsprotokoll bedeuten Volumen. Die Zuordnungstabelle weiter oben in diesem Beitrag führt das im Detail aus.
5. Adressbeschränkung setzen, nicht den Dienst abschalten. Beschränken Sie die Remotedesktop-Regeln auf Ihre eigene Adresse. Das beendet Bruteforce und Anmeldeflut sofort. Gegen ein Volumenproblem ändert es nichts, schadet aber auch nicht.
6. UDP 3389 zumachen, falls noch offen. Das dauert eine Zeile und nimmt Ihnen im laufenden Angriff eine Angriffsfläche und Ihrem Server die Verstärkerrolle.
7. Verwaltungsports prüfen. WinRM auf 5985, SMB auf 445 und alles, was nicht öffentlich sein muss, gehört auf Ihre eigene Adresse begrenzt. Das reduziert die Angriffsfläche sofort und ohne Risiko für Ihre Nutzer.
8. Den Anbieter mit Zahlen einbeziehen. Eröffnen Sie ein Ticket mit fünf Angaben: Zeitpunkt, betroffene IP-Adresse, Zielport, gemessene Paketrate und mittlere Paketgröße. Diese fünf Werte entscheiden darüber, wie schnell die Filterregeln für Ihre Adresse nachjustiert werden.
9. Danach dokumentieren. Halten Sie fest, wann es begann, wie lange es dauerte und welches Muster es war. Wiederkehrende Angriffe zur selben Uhrzeit sind das Kriterium dafür, ob ein Server eine dedizierte Schutz-IP braucht.

Der ausführliche Ablauf für einen schweren, länger laufenden Angriff steht in Schwerer DDoS-Angriff: was tun, die serverseitigen Vorkehrungen für Linux-Systeme in Server vor DDoS-Angriffen schützen.

Wenn Sie selbst nicht mehr hineinkommen

Das ist der Fall, für den man vorgesorgt haben muss, weil man in ihm nicht mehr vorsorgen kann. Drei Wege bleiben, in dieser Reihenfolge:

Erstens die VNC-Konsole im Kundenbereich. Sie hängt nicht am Netzwerk des Gastsystems und funktioniert deshalb auch bei gesättigter Leitung, kaputter Firewallregel oder abgestürztem RDP-Dienst. Von dort aus nehmen Sie eine falsche Regel zurück oder spielen das gesicherte Regelwerk mit netsh advfirewall import ein.

Zweitens: Ist nur das Konto gesperrt, hilft Abwarten. Nach Ablauf der Sperrdauer entsperrt Windows von selbst. Und weil das Sperrverhalten laut Microsoft ausdrücklich nur Netzwerkanmeldungen betrifft, kommen Sie über die Konsole auch währenddessen herein. Den kompletten Weg beschreibt RDP-Fehler: Konto gesperrt.

Drittens der Notfallkontakt beim Anbieter. Wenn die Leitung voll ist, ist das Ticketsystem der schnellere Weg als jeder weitere Versuch, sich zu verbinden. Nennen Sie dabei die fünf Angaben aus Schritt 8, auch wenn Sie nur einen Teil davon haben.

Legen Sie sich für den Ernstfall ein kleines Skript ab, das die Adressbeschränkung nach zehn Minuten selbsttätig zurücknimmt, bevor Sie eine Firewallregel scharf schalten. Eine geplante Aufgabe, die Set-NetFirewallRule -Group '@FirewallAPI.dll,-28752' -RemoteAddress Any ausführt, kostet fünf Minuten Vorbereitung und rettet den Abend. Funktioniert die neue Verbindung, löschen Sie die Aufgabe wieder.

Häufige Fehler und Lösungen

"Die Ereignisanzeige ist voll mit 4625, also werde ich geddost": Nein, Sie werden durchprobiert. Ein volumetrischer Angriff erzeugt kein einziges 4625-Ereignis, weil kein Paket bis zur Anmeldung kommt. Viele fehlgeschlagene Anmeldungen bedeuten das Gegenteil: Ihr Server ist erreichbar und jemand rät Kennwörter. Die richtige Antwort ist Kontosperrung und Adressbeschränkung, nicht mehr Bandbreite.

"Ich habe SynAttackProtect gesetzt und es wurde nicht besser": Der Wert hat seit Windows Vista und Windows Server 2008 keine Wirkung mehr. Der SYN-Angriffsschutz ist eingebaut, ab Werk aktiv und nicht abschaltbar, und er berechnet seine Schwellenwerte dynamisch aus CPU-Kernen und Arbeitsspeicher. Es gibt dafür keinen Schalter, weder in der Registrierung noch über netsh. Löschen Sie den Wert wieder, damit Sie sich später nicht darauf verlassen.

"Ich habe RDP auf meine IP-Adresse beschränkt und es kommt trotzdem Angriffsverkehr an": Prüfen Sie mit Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 3389 } | Get-NetFirewallRule, ob eine zweite, offene Regel existiert. Anbieter-Abbilder und Installationsprogramme legen solche Regeln gern an. Erlaubende Regeln werden gemeinsam ausgewertet, es gewinnt die weiteste.

"Nach dem Portwechsel komme ich nicht mehr herein": Die eingebauten Remotedesktop-Regeln sind fest auf 3389 gebunden und greifen für den neuen Port nicht. Legen Sie eine eigene Regel für den neuen Port an, bevor Sie den Dienst umstellen. Der vollständige Ablauf steht in RDP-Port ohne Neustart ändern.

"Mein Konto ist ständig gesperrt, obwohl ich das richtige Kennwort habe": Dann hält jemand die Sperre aktiv, indem er im Takt falsche Kennwörter schickt. Das ist ein Denial of Service mit minimalem Aufwand. Die Lösung ist nicht, die Sperre abzuschalten, sondern den Dienst aus dem Internet zu nehmen, damit der Angreifer gar nicht mehr an das Anmeldeformular kommt.

"Die Firewall soll die Verbindungsrate begrenzen": Das kann sie nicht. Die Windows-Firewall kennt keine Ratenbegrenzung je Quelladresse, weder über die Oberfläche noch über netsh oder PowerShell. Was sie kann, ist erlauben, sperren und auf Adressen einschränken. Eine echte Ratenbegrenzung für RDP gibt es nur in der Filterung vor dem Server.

"Mein bisheriger Anbieter hat meine IP-Adresse gesperrt": Das ist Nullrouting. Der Anbieter schützt damit sein eigenes Netz, für Sie ist das Ergebnis identisch mit einem erfolgreichen Angriff, meist noch für Stunden danach. Fragen Sie im Zweifel nach, ob gefiltert oder nullgeroutet wird. Die Antwort entscheidet mehr über Ihre Verfügbarkeit als jede Hardwareangabe.

"Ich sehe im Mitschnitt auf dem Server nichts Auffälliges": Wenn der Verkehr schon im Netz davor gefiltert wird, kommt auf dem Server erwartungsgemäß nichts an. Das ist der Normalfall bei funktionierender Filterung und kein Zeichen dafür, dass nichts passiert ist.

Kurz zusammengefasst

• RDP lauscht in der Voreinstellung auf 3389 TCP und seit RDP 8.0 zusätzlich auf 3389 UDP. Ein RD-Gateway nimmt stattdessen 443 TCP und optional 3391 UDP entgegen. Für den Zugang von außen ist genau der Gatewayweg vorgesehen, nicht der offene 3389.
• Was in den Windows-Ereignisprotokollen wie ein DDoS-Angriff aussieht, ist meistens Bruteforce. Ein volumetrischer Angriff hinterlässt im Sicherheitsprotokoll überhaupt keine Spur, weil kein Paket bis zur Anmeldung kommt.
• Die schnellste Unterscheidung dauert zehn Sekunden: Sind andere Dienste auf derselben IP-Adresse ebenfalls weg, ist es die Leitung. Hängt nur 3389, ist es RDP.
• Die Registrierungswerte SynAttackProtect, TcpMaxHalfOpen und die AFD-Werte für den dynamischen Backlog haben seit Windows Vista und Windows Server 2008 keine Wirkung mehr. Der SYN-Angriffsschutz ist eingebaut, nicht abschaltbar und berechnet seine Schwellen dynamisch aus CPU-Kernen und Arbeitsspeicher.
• Windows meldet nicht, wenn dieser Schutz ausgelöst hat. Messbar ist er nur indirekt über die Zahl der Verbindungen im Zustand SynReceived und die Verwurfszähler der Netzwerkkarte.
• Einen offenen UDP-Port 3389 sollten Sie schließen, wenn Sie den beschleunigten Transport nicht brauchen. Laut NETSCOUT lässt sich RDP darüber mit dem Faktor 85,9 zu 1 als Verstärker missbrauchen, die beobachteten Angriffe lagen zwischen 20 und 750 Gbit/s.
• Der Portwechsel weg von 3389 senkt das Scannerrauschen deutlich und schützt gegen nichts. Gegen einen volumetrischen Angriff wirkt er gar nicht, weil der sich gegen die IP-Adresse richtet und nicht gegen eine Portnummer.
• Eine Kontosperrung ist gegen Bruteforce sehr wirksam und selbst ein Angriffsziel: Wer Ihren Benutzernamen kennt, hält das Konto mit wenigen Kilobit pro Sekunde dauerhaft gesperrt. Laut Microsoft betrifft die Sperre nur Netzwerkanmeldungen, die Konsole bleibt erreichbar.
• Die beste Maßnahme ist, RDP gar nicht ins Internet zu stellen. Ein VPN davor oder ein RD-Gateway macht aus dem RDP-Problem ein VPN-Problem, und das ist das kleinere.
• Oberhalb der Bandbreite Ihres Anschlusses entscheidet ausschließlich die Filterung im Netz davor. Bei KernelHost ist diese zweistufig, dauerhaft aktiv, ohne Nullrouting und ohne Aufpreis in jedem Serverpaket enthalten: 17 Tbps Mitigationskapazität im globalen Scrubbing-Netzwerk plus Arbor-Echtzeitfilterung mit 3,2 Tbps in Frankfurt am Main.

Wie ein Windows-Server sauber aufgesetzt wird, von der Lizenz über die Firewallprofile bis zur RDP-Absicherung, steht in Windows Server auf einem VPS einrichten. Welche Größe für welchen Einsatzzweck passt, ordnet Windows-VPS: wofür und welche Größe ein.

Läuft Ihr Server bereits bei KernelHost, ist die Filterung aktiv, ohne dass Sie etwas tun müssen. Bemerken Sie trotzdem Auffälligkeiten, eröffnen Sie ein Support-Ticket mit den fünf Angaben aus Schritt 8, damit die Filterregeln für Ihre IP-Adresse nachjustiert werden. Bei einem laufenden Angriff erreichen Sie uns zusätzlich über den WhatsApp-Notfallchat unter +43 650 8209883.