Stoppen Sie RDP-Brute-Force-Angriffe auf Ihren Windows-Servern

Free ist dauerhaft und ohne Karte: RDP-Brute-Force-Schutz auf einem Server, Sperren der angreifenden Adresse, 24 Stunden Angriffsverlauf und eine Whitelist mit bis zu drei Adressen. Es läuft nicht ab und ist keine Testphase. Die bezahlten Tarife ergänzen das Sperren des gesamten Angreifer-Subnetzes statt einzelner Adressen, Schutz für FTP und MS SQL, Telegram-Alarme, GeoIP-Regeln, längeren Verlauf und die gemeinsame Bedrohungsdatenbank.

Jedes Konto erhält sie einmal, ohne Karte und ohne Kündigung. Sie schaltet den vollen Pro-Funktionsumfang auf Ihren eigenen Servern frei. Nach 14 Tagen kehrt das Konto von selbst zu Free zurück und der Schutz läuft weiter: Subnetz-Sperren werden wieder zu Einzeladress-Sperren, Telegram-Alarme werden abgeschaltet und der Verlauf verkürzt sich auf 24 Stunden. Es wird nie automatisch abgebucht.

Buchen Sie einzelne Server für 3 $ pro Server und Monat, statt in den nächsten Tarif zu wechseln. Zusätzliche Server verlängern sich im selben Zyklus wie der Tarif, den sie erweitern.

Ja. Der Agent liest nur das Sicherheitsprotokoll seines eigenen Betriebssystems und blockiert eingehende Verbindungen zu den geschützten Ports derselben Maschine. Er stellt ausschließlich ausgehende HTTPS-Verbindungen her und öffnet keine eingehenden Ports.

Ja. Die Sperr-Entscheidung wird lokal auf dem Agenten getroffen, daher arbeitet der Schutz mit der zuletzt angewendeten Richtlinie auch dann weiter, wenn die Cloud nicht erreichbar ist.

Der Agent erkennt den tatsächlichen RDP-Port automatisch anhand von Registry und lauschenden Sockets und baut seine Regeln bei einer Änderung neu auf. Der FTP-Port wird genauso erkannt.

Nein. Bei der Installation wird Ihre aktuelle IP-Adresse in die Whitelist eingetragen, und Whitelist-Quellen haben immer Vorrang vor jeder Sperre.

Windows Server 2012 R2 bis 2025 sowie Windows 8.1 / 10 / 11 auf x64, x86 und ARM64. Eine einzige Binärdatei ohne zusätzliche Laufzeitumgebungen.

Internationale Zahlungen laufen über PayPro Global, Zahlungen in Russland über YooKassa, zusätzlich ist Kryptowährung möglich. Der Free-Tarif ist dauerhaft und erfordert keine Karte.

RDP Protector ist die Fail2ban-Alternative, die von Anfang an für Windows Server gebaut wurde. Fail2ban ist ein Linux-Daemon: er liest Textprotokolle und ruft iptables oder nftables auf - beides gibt es unter Windows nicht. Portierungen der Idee laufen meist unter Cygwin oder WSL mit einem Skript auf netsh. RDP Protector erledigt dieselbe Aufgabe so, wie Windows es tut: er abonniert das Windows-Sicherheitsereignisprotokoll, entscheidet lokal, dass eine Quelle angreift, und schreibt die Sperre als eine einzige konsolidierte Regel in die Windows-Firewall statt in tausende. Keine Linux-Laufzeit, kein Log-Parsing, keine Skripte.

Das erste Problem lösen sie gleich - fehlgeschlagene Anmeldungen beobachten, die Adresse sperren - und dort fängt RDP Protector auch an. Der Unterschied beginnt beim zweiten Server. Jene Werkzeuge arbeiten pro Maschine: jede mit eigenen Einstellungen, eigener Sperrliste und ohne jede Ahnung, was die Maschine daneben bereits gesehen hat. Hier teilen sich die Agenten eine Richtlinie und eine mandantenübergreifende Reputationsdatenbank, sodass eine Adresse, die einen anderen geschützten Server angegriffen hat, Ihrem bereits bekannt ist; kostenpflichtige Tarife sperren das ganze /24-Subnetz statt einer Adresse nach der anderen, und das Panel zeigt die ganze Flotte auf einmal.

Weil sie das Konto sperrt, nicht den Angreifer. Eine Sperrrichtlinie stoppt das Raten, indem sie das Ziel deaktiviert - genau das, was ein Brute-Force-Bot braucht, um Ihren Administrator aus einem Server auszusperren, in den er selbst nie hineingekommen wäre; deshalb werden Kontosperren zum Werkzeug für Denial of Service. Am Verkehr ändert sie nichts: die Versuche kommen weiter an, kosten weiter CPU und füllen weiter das Ereignisprotokoll. Die Quelle in der Firewall zu sperren stoppt die Versuche statt des Kontos.

Die meiste Ransomware erreicht einen Windows-Server nicht über einen Exploit, sondern über eine Anmeldung: Die Gruppe errät oder kauft ein RDP-Passwort, meldet sich als Administrator an, schaltet den Virenschutz ab, löscht die Schattenkopien und startet den Verschlüsseler von Hand. Genau deshalb ist RDP-Sicherheit die Ransomware-Maßnahme, die sich zuerst bezahlt: Nehmen Sie Remote Desktop wo möglich aus dem offenen Internet, verlangen Sie Multi-Faktor-Authentifizierung für jedes Konto, das es erreichen kann, und sperren Sie die Quelladresse automatisch nach einigen fehlgeschlagenen Anmeldungen, damit das Raten nie fertig wird. Den letzten Teil übernimmt RDP Protector: Er liest das Windows-Sicherheitsprotokoll auf dem Server selbst, sperrt das Subnetz des Angreifers in der Firewall, bevor die Kontosperrung greift, und behält die Historie jedes Versuchs. Dazu Offline-Backups, aus denen Sie wirklich schon zurückgesichert haben - zusammen entscheiden sie, ob ein Einbruch ein Vorfall oder eine Katastrophe ist.

Mit RDP Protector installiere ich den Agenten als Windows-Dienst: Er liest lokale Authentifizierungsereignisse, ermittelt den tatsächlichen RDP-Port und fügt der Windows-Firewall nach einem Schwellenwert von Versuchen pro Zeitfenster eine Quellenblockierung hinzu. Ich setze meine Verwaltungsadressen auf die Whitelist, überprüfe den Angriff im Panel und lasse die lokale Richtlinie funktionieren, auch wenn ich die Verbindung zur Cloud verliere.

Kostenlos ohne RDP Protector Ich schließe RDP vom gesamten Internet und erlaube nur TCP-Ports von VPN oder festen IPs in der Windows Defender-Firewall. Ich aktiviere NLA, MFA über RD Gateway, lange eindeutige Passwörter und die Überwachung von 4625/4624-Ereignissen; Wenn VPN nicht möglich ist, schreibe ich eine PowerShell-Aufgabe, um das Ereignisprotokoll und die temporären Firewall-Regeln zu analysieren und das Löschen von Regeln und Ausnahmen unabhängig zu steuern.

Mit RDP Protector blockiere ich das Quellnetzwerk auf Firewall-Ebene, bevor es die Fehlergrenze eines bestimmten Kontos erreicht. Ich füge Büro-/VPN-Subnetze zur Whitelist hinzu, konfiguriere das Fenster und den Schwellenwert basierend auf dem tatsächlichen Hintergrund, aktiviere Benachrichtigungen und überprüfe den Angriffsverlauf, ohne die Domänenblockierungsrichtlinie zu lockern.

Kostenlos veröffentliche ich RDS nur über RD Gateway oder VPN, erlaube Verbindungen von vertrauenswürdigen Subnetzen und aktiviere NLA. Ich konfiguriere einen angemessenen Sperrschwellenwert/-dauer, separate Administratorkonten und eine Warnung für Ereignisse 4625 mit Anmeldetyp 10; Manuelle IP-Blockierung ist als vorübergehende Maßnahme akzeptabel, ich dokumentiere jedoch die Dauer jeder Regel, um keine ewige Blacklist zu erstellen.

Mit RDP Protector installiere ich einen einfachen Agenten, der den RDP-Port automatisch erkennt und lokale Windows-Firewallregeln anwendet. Ich füge zunächst die aktuelle Adresse zur Whitelist hinzu, überprüfe den Zugriff vom Backup-Kanal und nutze den kostenlosen Einzelserverschutz; Wenn das Internet ausfällt, bleibt die letzte Richtlinie auf dem VPS.

Kostenlos erstelle ich ein separates WireGuard/Tailscale VPN-Netzwerk und schließe RDP für die öffentliche Schnittstelle, so dass die Notfallkonsole des Hosters übrig bleibt. Ich schließe NLA, Updates, ein eindeutiges Konto ohne den Standard-Administratornamen, MFA, sofern verfügbar, und tägliche externe Sicherung mit separaten Schlüsseln ein; Ich verwende die Portübertragung nur zur Geräuschreduzierung, nicht als Schutz.

Mit RDP Protector unterbinde ich wiederholte fehlgeschlagene Anmeldungen bei der Windows-Firewall, pflege eine Whitelist vertrauenswürdiger Quellen und überprüfe Angriffsadressen und -zeiten zentral. Ich betrachte den Agenten als externe Ebene des Kontos, speichere jedoch separat die geringsten Berechtigungen, Updates und Backups – Brute-Force-Blockierung ersetzt nicht den Datenschutz nach der Anmeldung.

Kostenlos installiere ich RD Gateway/VPN vor dem Server, aktiviere NLA und MFA, trenne Benutzer- und Administratorkonten, verweigere lokalen Benutzern den Zugriff auf Backups und teste die Wiederherstellung. Ich sammle 4624/4625 und Änderungen an Administratorgruppen in der Windows-Ereignisweiterleitung und schließe öffentliche 3389 mit Firewallregeln.

Mit RDP Protector ermögliche ich die Ereigniserfassung unterstützter Dienste, erlaube dem Agenten, die tatsächlichen Ports zu ermitteln, und wende eine lokale Firewall-Lösung auf das Netzwerk des Angreifers an. Ich stelle sicher, dass die erforderlichen Prüfprotokolle aktiviert sind, füge vertrauenswürdige Integrationen zur Whitelist hinzu und sehe den zugehörigen Quellverlauf in einem Bereich. Der erweiterte FTP- und MS SQL-Schutz ist tarifabhängig.

Kostenlos schließe ich MS SQL und administratives FTP aus dem Internet, erlaube sie nur über ein VPN oder eine IP-Liste und ersetze FTP nach Möglichkeit durch SFTP. Ich aktiviere die SQL Server-Anmeldeüberwachung, die erweiterte FTP-Protokollierung und die Windows-Ereignisweiterleitung und führe dann eine PowerShell-Aufgabe aus, die die Quellen normalisiert und temporäre Windows-Firewallregeln mit TTL hinzufügt.

Mit RDP Protector blockiere ich Quellen basierend auf dem tatsächlichen Fluss fehlgeschlagener Eingaben, anstatt alle unbekannten Adressen im Voraus zu sperren. Ich füge während der Installation die aktuelle administrative IP hinzu, pflege eine Whitelist für VPNs und bekannte Netzwerke, wende GeoIP nur als zusätzliche Regel an und überprüfe das Cloud-Panel auf Blockaden.

Ich gebe Mitarbeitern kostenlos Zugriff über WireGuard/Tailscale oder RD Gateway mit MFA und schließe öffentliches RDP. Wenn dies vorübergehend nicht möglich ist, aktiviere ich NLA, starke eindeutige Passwörter, ein kurzes Sitzungs-Timeout und eine Benachrichtigung für 4625/4624 aus einem neuen Land; Ich blockiere allgemeines NAT nicht für immer, sondern nutze temporäre Firewall-Regeln und einen Notfall-Zugriffskanal.

Mit RDP Protector lasse ich die Reaktion auf Massenfehler für alle externen Netzwerke aktiviert, füge nur das kontrollierte VPN zur Whitelist hinzu, nicht die Privatadressen von Auftragnehmern, und erhalte einen Verlauf der Quellen und Blockaden. Ich kombiniere dies mit einem separaten temporären Windows-Konto: Der Agent schützt den Perimeter und die Dauer und Rechte bleiben in meiner Zugriffsrichtlinie.

Kostenlos erstelle ich für jeden Auftragnehmer ein persönliches VPN-Profil und ein Windows-Konto mit Ablaufdatum, Mindestgruppen und einem Verbot der lokalen Anmeldung, wenn diese nicht benötigt wird. Ich aktiviere MFA auf dem Gateway, logge 4624/4634/4672 ein, lösche das Profil nach getaner Arbeit und verwende kein gemeinsames Konto, da sonst eine Untersuchung und Sperrung des Zugriffs unmöglich wird.

Mit RDP Protector stoppe ich die Quelle bei einer Reihe von Fehlern, bevor sie den Schwellenwert für die Domänensperrung erreicht oder das Passwort errät. Ich setze eine Whitelist nur für Netzwerke, in denen die Integration tatsächlich funktioniert, kontrolliere Angriffe im Panel und lasse die lokale Blockierung offline wirken; Gleichzeitig habe ich vor, das veraltete Konto abzuheben.

Ich deaktiviere dieses Konto kostenlos über RDP über die Zuweisung von Benutzerrechten, wenn keine interaktive Anmeldung erforderlich ist, und beschränke die Netzwerkanmeldung auf die erforderlichen Hosts. Ich ändere das Passwort in ein langes, zufälliges Geheimnis, speichere es, aktiviere Auditing und Firewall-Zulassungsliste über VPN; Wenn RDP dennoch benötigt wird, erstelle ich einen separaten Gateway-Zugang mit MFA.

Mit RDP Protector konfiguriere ich den Netzwerkblockierungsschwellenwert unterhalb des Domänenschwellenwerts und verbiete die Quelle in der Windows-Firewall, bis der Benutzer erneut blockiert wird. Ich verwende eine Subnetzsperre gegen die Rotation von Nachbaradressen, schließe vertrauenswürdige Netzwerke aus und verfolge, welche Quellen auf das Konto abzielen. Gleichzeitig schwäche ich meine Domain-Richtlinie nicht ab.

Kostenlos schließe ich das RDP hinter dem VPN/RD-Gateway, ändere den öffentlich bekannten Admin-Namen und trenne die Arbeits- und Notfallkonten. Ich habe eine Warnung für 4740 und 4625 eingerichtet, den Computernamen/die IP des Anrufers überprüft und die Quelle vorübergehend mit einem PowerShell-Skript blockiert. Eine einfache Erhöhung der Sperrschwelle verwende ich erst nach einer Risikoanalyse, da sie die eigentliche Auswahl erleichtert.

Mit RDP Protector blockiere ich sofort aktive Quellen und Subnetze gemäß den lokalen Richtlinien, überprüfe den Verlauf von Angriffen und belasse die Whitelist nur für den kontrollierten Kanal. Anschließend ändere ich das Passwort, beende aktive Sitzungen und analysiere den erfolgreichen 4624-Anmeldetyp 10; Das Produkt reduziert das Angriffsfenster, bricht jedoch nicht die Untersuchung eines bestehenden Logins ab.

Kostenlos schließe ich vorübergehend öffentliches RDP mit einer Windows-Firewall-Regel, setze das Passwort und die zugehörigen Geheimnisse zurück, widerrufe Sitzungen und aktiviere MFA über RD-Gateway/VPN. Ich überprüfe 4624, 4672, neue 7045-Dienste, Aufgaben, Benutzer und Defender-Warnungen für den Zeitraum; Nach der Bereinigung erlaube ich RDP nur über einen sicheren Kanal und verbiete die Wiederverwendung von Passwörtern.

Mit RDP Protector lade ich den Verlauf erkannter Angriffe und angewendeter Blockierungen hoch, füge Schwellenwert-/Fensterparameter, eine Liste geschützter Ports und genehmigter Ausnahmen hinzu. Ich dokumentiere das lokale Verhalten des Agenten bei Verlust der Cloud, die ausgehende HTTPS-Verbindung und den fehlenden eingehenden Kontrollport, führe dann einen kontrollierten Test durch und speichere das Ereignis, die Firewall-Regel und die Benachrichtigung.

Kostenlos erstelle ich eine RDP-Richtlinie über VPN/RD-Gateway, exportiere GPO, Windows-Firewallregeln und protokolliere 4625/4624 im sicheren Speicher. Ich speichere Änderungen in einem Änderungsprotokoll, teste monatlich Blockierung und MFA, unterschreibe den Bericht mit der verantwortlichen Person und vergleiche eine Stichprobe erfolgreicher Anmeldungen mit einer Liste von Mitarbeitern; ein Beweis wird durch ein wiederholbares Verfahren erstellt.

Mit RDP Protector erlaube ich dem Agenten, eine Reihe fehlgeschlagener Anmeldungen zu erkennen und die Windows-Firewall-Quelle zu blockieren, woraufhin bei neuen Verbindungen die Authentifizierung fehlschlägt und nicht mehr die gleiche Menge an Ereignissen generiert wird. Ich überprüfe die Protokollgröße und die Aufbewahrung separat und verwende den Angriffsverlauf als kompakten Index zu den ursprünglichen Ereignissen.

Kostenlos schränke ich den Zugriff auf Ports über VPN/Zulassungsliste ein, erhöhe die Größe des Sicherheitsprotokolls und aktiviere Archivierung statt Neuschreiben. Ich leite 4625/4624 an Windows Event Collector oder SIEM weiter, filtere die erforderlichen Anmeldetypen und löse eine temporäre Blockierung am Schwellenwert aus; Ich deaktiviere das Auditing nicht, da es nach einer erfolgreichen Anmeldung weiterhin die Hauptquelle für Fakten bleibt.

Mit RDP Protector habe ich einen lokalen Schwellenwert für die automatische Blockierung festgelegt, sodass der Agent die Windows-Firewall-Regel anwendet, ohne dass ein Mensch eingreifen oder auf einen Cloud-Befehl warten muss. Ich sende Benachrichtigungen an den richtigen Kanal, überprüfe morgens den Verlauf und die Ausnahmen und um eine Selbstblockierung zu riskieren, speichere ich die Notfallkonsole und die Whitelist im Voraus.

Kostenlos installiere ich RDP hinter einem ständig laufenden VPN, konfiguriere Scheduled Task PowerShell basierend auf den Ereignissen 4625 und sende E-Mails/Webhooks über meinen eigenen Server. Ich verwende temporäre Regeln mit Ablaufdatum, teste die Aufgabe mit einem Testangriff und dokumentiere den Notfallzugriff; Ich kümmere mich selbst um das Skript, die Protokolle und die Zustellung der Benachrichtigungen.

Mit RDP Protector verbinde ich jeden Server als Agent, sehe seine tatsächlichen Ports und seinen Status in einem Panel, behalte aber separate Richtlinien und Whitelists, wenn sie sich unterscheiden. Ich wende einen Basisschwellenwert an, dokumentiere Ausnahmen, verteile Benachrichtigungen und nutze den Verlauf auf jedem Host, um dem Kunden Bericht zu erstatten.

Kostenlos speichere ich die Windows-Firewall/GPO-Konfiguration in separaten Inventaren des Ansible/PowerShell DSC-Clients, stelle die Basisvorlage über CI bereit und vermische keine Geheimnisse und Mandantenadresslisten. Ich zentralisiere Ereignisse über WEF/WEC oder kostenloses Wazuh, setze Client-Tags und prüfe mit einem Skript auf Abweichungen; Ich unterstütze die Infrastruktur und aktualisiere mich selbst.

Mit RDP Protector wende ich die Richtlinie direkt auf den Agenten an: Er liest weiterhin lokale Ereignisse und ändert die Windows-Firewall auf die neueste Konfiguration, auch wenn das Panel nicht verfügbar ist. Ich synchronisiere die Whitelist und die Schwellenwerte im Voraus. Nachdem die Verbindung wiederhergestellt ist, überprüfe ich den Bericht und verknüpfe die Entscheidung über jede Anmeldung nicht mit der Remote-API.

Kostenlos lokalisiere ich die Kontrolle vollständig: Die Windows-Firewall lässt RDP nur von VPN/erforderlichen Subnetzen zu, und geplante Aufgaben analysieren das Ereignisprotokoll und erstellen temporäre Regeln ohne Netzwerk. Ich speichere die Konfiguration und Protokolle auf dem Server, richte eine Benachrichtigungswarteschlange ein, nachdem die Verbindung wiederhergestellt wurde, und stelle sicher, dass ein DNS- oder Cloud-Fehler keine bereits angewendeten Sperren aufhebt.