Brute-Force-Angriffe gehören zu den häufigsten Bedrohungen für Server, die aus dem Internet erreichbar sind. Sie laufen meist automatisiert, hartnäckig und kostengünstig ab. Ein Angreifer muss nur wenig über ein Unternehmen wissen, bevor er einen SSH-Daemon, RDP-Endpunkt, ein Control Panel, eine Datenbank oder eine Schnittstelle zur Fernadministration mit Tausenden gestohlener oder erratener Zugangsdaten testet.
Viele Versuche scheitern und stellen zunächst nur ein geringes unmittelbares Risiko dar. Die Gefahr besteht darin, dass einer erfolgreich ist – insbesondere wenn ein Passwort wiederverwendet wurde, ein altes Konto noch aktiv ist oder ein Dienst ohne Multi-Faktor-Authentifizierung erreichbar ist. Wiederholte fehlgeschlagene Anmeldungen sollten daher als nützliche Sicherheitsdaten und nicht bloß als Hintergrundrauschen des Internets betrachtet werden.
Dieser Leitfaden erklärt, wie Sie Brute-Force-Angriffe auf Server erkennen, welche Maßnahmen sie eindämmen, wo Blockierungsstrategien versagen können und was zu tun ist, wenn ein Angreifer Zugriff erhält.
So sehen Brute-Force-Angriffe auf Server aus
Bei einem Brute-Force-Angriff wird versucht, durch das Testen vieler Passwörter, Benutzernamen oder Kombinationen aus Zugangsdaten Zugriff zu erlangen. Moderne Kampagnen nutzen häufig Credential Stuffing statt zufälliger Rateversuche: Der Angreifer testet Kombinationen aus Benutzernamen und Passwörtern, die bei früheren Datenlecks erbeutet wurden. Beim Password Spraying wird dagegen ein gängiges Passwort gegen viele Konten ausprobiert. So lassen sich kontobezogene Sperren umgehen.
SSH und RDP sind häufige Ziele, da sie direkten administrativen Zugriff ermöglichen. Andere exponierte Dienste können ebenso wichtig sein:
- Webhosting- und Server-Control-Panels
- VPN-Gateways und Portale für den Fernzugriff
- Administrations- und Webmail-Oberflächen für E-Mail-Systeme
- Datenbank-Listener wie MySQL, PostgreSQL oder Microsoft SQL Server
- Anmeldeseiten von Anwendungen und API-Endpunkte
- Konsolen für Virtualisierung, Backups und Monitoring
Die Aktivitäten können von einer einzelnen Adresse, einer wechselnden Liste von Cloud-Servern oder einem großen IP-Adressbereich ausgehen. Ein verteilter Angriff kann pro Adresse nur wenige Versuche erzeugen, insgesamt aber eine große Zahl von Fehlversuchen verursachen. Deshalb reicht es oft nicht aus, nur eine Firewall-Regel oder das Protokoll eines einzelnen Servers zu betrachten.
Automatisierte Anmeldeversuche erkennen
Beginnen Sie mit den Authentifizierungsprotokollen
Authentifizierungsprotokolle sind der erste Anlaufpunkt. Unter Linux erscheinen SSH-Ereignisse üblicherweise im Systemjournal oder im Authentifizierungsprotokoll. Windows-Administratoren sollten RDP-Ereignisse und andere relevante Ereignisse in der Ereignisanzeige oder einer zentralen Windows-Protokollierungsplattform prüfen. Control Panels, VPN-Produkte und Datenbanken führen normalerweise eigene Audit-Protokolle.
Achten Sie auf Muster statt auf einzelne Ereignisse:
- Dutzende oder Hunderte fehlgeschlagene Anmeldungen innerhalb kurzer Zeit
- Versuche gegen zahlreiche Benutzernamen, einschließlich nicht vorhandener Namen
- Wiederholte Versuche gegen privilegierte Konten wie root, Administrator oder Dienstkonten
- Verbindungen, die in regelmäßigen Abständen von wechselnden Adressen eintreffen
- Eine erfolgreiche Authentifizierung unmittelbar nach einer langen Reihe von Fehlversuchen
- Anmeldungen zu ungewöhnlichen Zeiten, aus ungewöhnlichen Ländern oder über unbekannte Netzwerke
- Neue Konten, geänderte Passwörter, veränderte SSH-Schlüssel oder Änderungen an der Gruppenzugehörigkeit
Eine einzelne fehlgeschlagene Anmeldung ist noch kein Sicherheitsvorfall. Ein Muster aus Fehlversuchen auf mehreren Systemen verdient jedoch eine Untersuchung – besonders, wenn anschließend eine Anmeldung erfolgreich ist. Teams, die Tools zur Erkennung und Blockierung bewerten, können verschiedene Ansätze anhand dieser Ressourcen zur Erkennung von Brute-Force-Angriffen auf Server und zu Fail2ban vergleichen. Vor der Einführung automatischer Sperren sollte jedes Tool jedoch in der eigenen Umgebung getestet werden.
Warnmeldungen und Verkehrssignale nutzen
Die Sammlung von Protokollen ist nur dann nützlich, wenn sie von einer Person oder einem System ausgewertet wird. Warnmeldungen können auf Schwellenwerten basieren, etwa zehn fehlgeschlagenen SSH-Anmeldungen innerhalb von fünf Minuten. Regeln, die ausschließlich Schwellenwerte verwenden, können langsames Password Spraying jedoch übersehen. Eine bessere Überwachung kombiniert Authentifizierungsereignisse mit Quelladressen, Benutzernamen, Geolokalisierung, Kritikalität des Assets und erfolgreichen Anmeldungen.
Netzwerk-Telemetrie kann zusätzlichen Kontext liefern. Achten Sie auf einen plötzlichen Anstieg der Verbindungsversuche zu Verwaltungs-Ports, wiederholte TCP-Handshakes, die nie abgeschlossen werden, Scans über mehrere Dienste hinweg oder ungewöhnlichen ausgehenden Datenverkehr nach einer verdächtigen Anmeldung. Ein kompromittierter Server kann damit beginnen, Verbindungen zu Command-and-Control-Infrastrukturen aufzubauen, interne Systeme zu scannen oder Daten zu übertragen.
Eine zentrale Überwachung ist besonders für Agenturen wichtig, die mehrere Kundenumgebungen verwalten. Ein einziges Dashboard oder eine SIEM-Plattform erleichtert es, denselben IP-Bereich, dasselbe Benutzernamensmuster oder dieselbe Password-Spraying-Kampagne auf mehreren Servern zu erkennen. Warnmeldungen sollten eine handlungsfähige Person erreichen und genügend Details enthalten, damit Einsatzkräfte während eines Vorfalls nicht erst unstrukturierte Protokolle durchsuchen müssen.
SSH und andere exponierte Dienste absichern
Starke Authentifizierung verwenden
Deaktivieren Sie, wo möglich, die SSH-Authentifizierung per Passwort und verlangen Sie individuelle kryptografische Schlüssel. Jeder Administrator sollte ein eigenes Konto und einen eigenen Schlüssel besitzen. Privilegierter Zugriff sollte über eine kontrollierte Rechteerhöhung und nicht über gemeinsam genutzte Root-Zugangsdaten erfolgen. Schützen Sie private Schlüssel mit Passphrasen und speichern Sie sie sicher. Entfernen Sie Schlüssel umgehend, sobald ein Mitarbeiter oder Dienstleister keinen Zugriff mehr benötigt.
Verwenden Sie für RDP, VPNs und Control Panels MFA, sofern das Produkt dies unterstützt. Bevorzugen Sie, wenn verfügbar, phishing-resistente Verfahren – insbesondere für Administratorkonten. MFA macht einen verwundbaren Dienst nicht automatisch sicher, verringert aber den Wert eines gestohlenen Passworts erheblich.
Passwortrichtlinien bleiben für Dienste wichtig, die Passwörter erfordern. Verwenden Sie lange, eindeutige Zugangsdaten, einen Passwortmanager sowie getrennte Konten für Administration, Anwendungen und Datenbanken. Lassen Sie niemals Standardzugangsdaten des Herstellers bestehen. Deaktivieren Sie inaktive Konten und prüfen Sie Dienstkonten auf unnötigen interaktiven Zugriff.
Angriffsfläche reduzieren
Die sicherste Verwaltungsschnittstelle ist eine, die öffentlich nicht erreichbar ist. Beschränken Sie den Zugriff auf SSH, RDP und Datenbanken nach Möglichkeit auf ein VPN, ein privates Netzwerk, einen Bastion Host oder festgelegte IP-Bereiche von Administratoren. Ein Datenbank-Listener muss in der Regel keine Verbindungen aus dem öffentlichen Internet akzeptieren.
Das Ändern des standardmäßigen SSH-Ports kann opportunistische Scans reduzieren, ist aber allein keine Sicherheitsmaßnahme. Angreifer können nicht standardmäßige Ports schnell entdecken. Betrachten Sie dies als Reduzierung von Rauschen, nicht als Schutz. Die wirksameren Kontrollen sind Netzwerkbeschränkungen, moderne Authentifizierung, Patch-Management und Überwachung.
Installieren Sie Sicherheitsupdates für Betriebssysteme, Control Panels, VPNs und Anwendungen. Entfernen Sie nicht mehr benötigte Dienste und prüfen Sie, ob administrative Schnittstellen nach Migrationen oder Firewall-Änderungen versehentlich exponiert wurden. Sichern Sie den Host nach einer dokumentierten Baseline ab und überprüfen Sie diese regelmäßig, statt anzunehmen, dass eine einmalige Konfiguration dauerhaft korrekt bleibt.
Verfahren zum Blockieren und Begrenzen der Rate
Firewalls und Filterung auf Providerebene
Host-Firewalls können Verwaltungs-Ports beschränken, Quellnetzwerke begrenzen und Datenverkehr zurückweisen, bevor er die Anwendung erreicht. Netzwerk-Firewalls oder Filter auf Providerebene können unerwünschten Datenverkehr früher abfangen oder verwerfen. Das ist hilfreich, wenn ein Angriff so viele Verbindungen erzeugt, dass Serverressourcen erschöpft werden.
Kontrollen auf Providerebene sind kein Ersatz für sichere Konten. Sie können außerdem ungenauer sein als anwendungsbezogene Kontrollen, besonders wenn sich viele legitime Kunden einen Adressbereich teilen. Legen Sie zugelassene Administratornetzwerke fest und halten Sie einen Notfallzugang aufrecht, damit eine fehlerhafte Regel nicht die Personen aussperrt, die für ihre Behebung zuständig sind.
Blockierung nach dem Fail2ban-Prinzip
Tools wie Fail2ban überwachen Protokolle und fügen nach einer festgelegten Zahl von Fehlversuchen vorübergehende Firewall-Regeln hinzu. Sie eignen sich für SSH und andere Dienste mit konsistenten Protokollformaten. Dauer einer Sperre, Fehlerschwelle und Liste ausgenommener Adressen sollten anhand des beobachteten Verhaltens festgelegt und nicht ungeprüft kopiert werden.
Vorübergehende Sperren bieten meist ein besseres Gleichgewicht als dauerhafte Blockierungen. Sie verlangsamen wiederholte Versuche, reduzieren Protokollrauschen und geben Administratoren Zeit zu reagieren, ohne eine stetig wachsende Sperrliste zu erzeugen. Stellen Sie sicher, dass das Überwachungstool selbst Log-Rotation, Neustarts von Diensten und Änderungen am Authentifizierungssystem übersteht.
Ratenbegrenzung und Kontrollen für Benutzerkonten
Eine Ratenbegrenzung kann auf Ebene eines Reverse-Proxys, einer Firewall, einer Anwendung oder eines Identity Providers umgesetzt werden. Sie ist besonders für Web-Anmeldeseiten und APIs nützlich, die öffentlich verfügbar bleiben müssen. Gestaffelte Verzögerungen, CAPTCHA-Abfragen und risikobasierte MFA können Automatisierung reduzieren, ohne jeden Nutzer nach einem einzigen Fehler auszusperren.
Bei Kontosperren ist mehr Vorsicht erforderlich. Eine strenge Sperre kann Rateversuche gegen ein einzelnes Konto stoppen. Ein Angreifer kann jedoch im Rahmen einer Password-Spraying-Kampagne absichtlich alle Mitarbeiterkonten sperren. Bevorzugen Sie kurze, gestaffelte Sperren oder eine Drosselung und richten Sie einen getesteten administrativen Wiederherstellungsprozess ein. Verlassen Sie sich bei einem privilegierten Konto niemals ausschließlich auf eine Sperrrichtlinie.
Zielkonflikte und häufige blinde Flecken
IP-Blockierung ist leicht verständlich, hat aber Grenzen. Adressen können von Büros, Mobilfunknetzen, Cloud-Plattformen oder Carrier-Grade-NAT gemeinsam genutzt werden. Das Blockieren eines gesamten Bereichs kann legitime Nutzer beeinträchtigen, während das Sperren einzelner Adressen gegen eine verteilte Kampagne wenig ausrichten kann. Auch Geolokalisierungsregeln können bei reisenden Mitarbeitern und externen Dienstleistern Fehlalarme erzeugen.
Fehlalarme sind mehr als eine Unannehmlichkeit. Ein blockiertes Monitoring-System, ein Backup-Operator oder ein Notfalladministrator kann die Wiederherstellung verzögern. Führen Sie, wo angemessen, eine Allowlist für vertrauenswürdige Verwaltungswege und schützen Sie diese sorgfältig; überprüfen Sie sie außerdem regelmäßig. Setzen Sie keinen großen dynamischen Bereich auf die Allowlist, nur weil er einmal mit einem legitimen Nutzer verbunden war.
Verteilte Angriffe erfordern identitätsbezogene Kontrollen. Wird dasselbe Konto aus vielen Netzwerken angegriffen, löst eine Blockierung der Quellen das Problem nicht. Starke MFA, eindeutige Zugangsdaten, deaktivierte Passwortauthentifizierung und zentrale Erkennung sind nachhaltigere Antworten. Suchen Sie neben IP-Adressen auch nach Mustern bei Benutzernamen, Geräten, Anwendungen und Zeitpunkten.
Untersuchung eines vermuteten Angriffs
Beginnen Sie mit der Sicherung von Beweismitteln. Dokumentieren Sie den betroffenen Host, die Zeitzone, relevante Protokolleinträge, Quelladressen, angegriffene Konten und bereits angewendete automatische Sperren. Exportieren Sie Protokolle, bevor sie überschrieben werden. Vermeiden Sie einen vorschnellen Neustart oder eine Bereinigung des Servers, wenn eine realistische Möglichkeit einer Kompromittierung besteht; flüchtige Daten und aktive Verbindungen können wichtig sein.
Ermitteln Sie anschließend, ob die Aktivitäten erfolglos waren oder ob ein Konto verwendet wurde. Suchen Sie nach erfolgreichen Anmeldungen in zeitlicher Nähe zu den Fehlversuchen und überprüfen Sie Quelle, Authentifizierungsmethode und Zeitpunkt. Prüfen Sie dann:
- Neue lokale oder Domänenkonten und unerwartete Gruppenzugehörigkeiten
- Neue autorisierte SSH-Schlüssel, geplante Aufgaben, Cron-Jobs oder Starteinträge
- Änderungen an Firewall-Regeln, Einstellungen für den Fernzugriff oder Sicherheitsrichtlinien
- Unerwartete Prozesse, offene Ports und ausgehende Verbindungen
- Veränderte Webdateien, Binärdateien, Skripte und Konfigurationsdateien
- Ungewöhnlichen Datenzugriff, Downloads, Uploads oder Rechteausweitungen
Vergleichen Sie den Host mit einer bekannten, vertrauenswürdigen Konfiguration oder einem Build-Standard. Prüfen Sie neben dem Server auch Protokolle des Identity Providers, VPNs, der Firewall, der Endpunkte und der Cloud. Ändern Sie Zugangsdaten und widerrufen Sie Sitzungen, sobald ein begründeter Verdacht besteht, dass sie offengelegt wurden. Verarbeitet das System regulierte Daten, Kundeninformationen oder geschäftskritische Vorgänge, befolgen Sie den Incident-Prozess der Organisation und prüfen Sie gesetzliche, regulatorische und vertragliche Meldepflichten.
Das Blockieren eines Versuchs ist keine Reaktion auf eine Kompromittierung
Eine Firewall-Regel oder Fail2ban-Sperre reagiert auf eine beobachtete Verbindung. Sie entfernt keinen Angreifer, der sich bereits erfolgreich authentifiziert hat. Eine erfolgreiche Anmeldung verwandelt störenden Datenverkehr in einen potenziellen Sicherheitsvorfall.
Wenn eine Kompromittierung vermutet wird, isolieren Sie den Server vom Netzwerk. Sichern Sie dabei notwendige Beweismittel und erhalten Sie einen kontrollierten Verwaltungsweg. Löschen Sie nicht einfach ein verdächtiges Konto und schalten Sie den Host wieder online. Ein Angreifer könnte Persistenz eingerichtet, Zugangsdaten gestohlen oder Binärdateien verändert haben. Die sicherere Reaktion besteht darin, den Umfang zu ermitteln, den Server gegebenenfalls aus einer vertrauenswürdigen Quelle neu aufzubauen, die ursprüngliche Schwachstelle zu beheben, Geheimnisse zu rotieren und wiederhergestellte Dienste engmaschig zu überwachen.
Die Wiederherstellung hängt außerdem von sauberen und nutzbaren Backups ab. Backups sollten von den normalen Zugangsdaten und der Verwaltungsebene des Servers isoliert sein, da ein Angreifer mit Administratorzugriff versuchen könnte, sie zu löschen oder zu verschlüsseln. Safenix bietet Offsite-Backups für vom Kunden kontrollierte Unternehmensserver. Die Daten werden mit einem Schlüssel verschlüsselt, den Safenix niemals besitzt, in Deutschland gespeichert und für die Dauer des gewählten Aufbewahrungszeitraums unveränderbar gehalten. Dies ist eine Maßnahme für die Wiederherstellung und kein Ersatz für Absicherung oder Incident Response: Der Kunde bleibt für die Kontrolle des geschützten Servers und die Entscheidung über dessen Wiederherstellung verantwortlich.
VPS-, Dedicated- und Shared-Hosting-Umgebungen
Welche Kontrollen Ihnen zur Verfügung stehen, hängt stark davon ab, wer das Betriebssystem und die Netzwerkgrenze kontrolliert. Ein vom Kunden verwalteter VPS bietet normalerweise Zugriff auf Betriebssystem, Firewall und Dienstkonfiguration. Damit kann ein Administrator – vorbehaltlich der Plattformgrenzen des Providers – SSH-Schlüssel durchsetzen, die Passwortanmeldung deaktivieren, Host-Überwachung installieren und Verwaltungsdatenverkehr beschränken.
Ein dedizierter Server bietet meist mehr direkten Einfluss auf Host, Netzwerkdesign und Trennung der Workloads. Die genauen Zuständigkeiten hängen jedoch weiterhin vom Vertrag und vom Verwaltungsmodell ab. Ein verwalteter Server kann bestimmte Änderungen einschränken und zugleich operativen Support bieten. Dokumentieren Sie diese Aufgabenteilung, bevor ein Vorfall eintritt.
Shared Hosting ist anders. Der Provider kontrolliert Host, Betriebssystem, Webserver-Konfiguration und die Sicherheitsgrenze zwischen Kunden. Kunden können möglicherweise Anwendungseinstellungen ändern, in der Regel aber kein Fail2ban installieren, Host-Firewall-Regeln anpassen, SSH für die Plattform deaktivieren oder sämtliche Authentifizierungsprotokolle einsehen. Hinweise zu Sicherheitskontrollen in kundenseitig verwalteten VPS-Infrastrukturen im Vergleich zu Shared Hosting sollten daher im Kontext des tatsächlich gewährten Zugriffs gelesen werden.
Safenix schützt Server, die der Kunde kontrolliert. Das Unternehmen verkauft keinen Backup-Tarif für eine Website, die auf Shared Hosting läuft. Eine Shared-Hosting-Website sollte daher nicht so dargestellt werden, als sei sie durch einen Safenix-Server-Backup-Service abgedeckt. Beim Shared Hosting muss der Kunde die verfügbaren Backup- und Exportoptionen des Hosts nutzen oder die Workload auf eine Infrastruktur verlagern, über die die Organisation die erforderliche Kontrolle besitzt.
Eine praktische Betriebsroutine
Der Schutz vor Brute-Force-Angriffen funktioniert am besten als Betriebsroutine und nicht als einzelne Einstellung. Überprüfen Sie mindestens regelmäßig exponierte Dienste und privilegierte Konten. Testen Sie Warnmeldungen mit autorisierten Simulationen, bestätigen Sie, dass Sperren wie vorgesehen ablaufen, und prüfen Sie, ob Administratoren weiterhin einen Notfallzugang erreichen können.
- Führen Sie ein Inventar internetseitig erreichbarer Dienste, ihrer Verantwortlichen und zugelassener Verwaltungsnetzwerke.
- Überprüfen Sie Trends bei fehlgeschlagenen und erfolgreichen Authentifizierungen und nicht nur die aktuellste Warnmeldung.
- Verwenden Sie SSH-Schlüssel, MFA, eindeutige Konten und das Prinzip der geringsten Rechte für die Administration.
- Patchen Sie Betriebssysteme und exponierte Anwendungen und entfernen Sie unnötige Dienste.
- Zentralisieren Sie Protokolle und sorgen Sie dafür, dass Warnmeldungen für das zuständige Reaktionsteam unmittelbar nutzbar sind.
- Testen Sie die Wiederherstellung von Backups und bestätigen Sie, dass Wiederherstellungsdaten von den Serverzugangsdaten isoliert sind.
- Dokumentieren Sie Eskalationskontakte, Schritte zur Beweissicherung und Verfahren zum Neuaufbau.
Automatisierte Angriffe werden weiterhin exponierte Dienste prüfen, müssen aber nicht zur Krise werden. Reduzieren Sie zuerst die Angriffsfläche, erschweren Sie den Missbrauch der Authentifizierung, setzen Sie Blockierungen als maßvolle Schutzschicht ein und überwachen Sie Anzeichen dafür, dass aus einem Versuch eine erfolgreiche Anmeldung wurde. Wird diese Grenze überschritten, wechseln Sie unverzüglich von der Blockierung zu Incident Response und Wiederherstellung.