Teil 1 – Erkennung von Reconnaissance-Aktivitäten gegen Webanwendungen in einem Docker Swarm
Geschätzte Lesezeit: 10–12 Minuten
Zielgruppe: Security Engineers, DevOps Engineers, Systemadministratoren und SOC-Analysten
Einleitung
Wer öffentlich erreichbare Webanwendungen betreibt, stellt schnell eines fest: Sie stehen unter ständigem Beschuss.
Bereits wenige Minuten nach der Bereitstellung einer neuen Website beginnen automatisierte Scanner damit, sie auf bekannte Schwachstellen zu untersuchen. Manche Anfragen zielen auf veraltete WordPress-Installationen ab, während andere nach offengelegten Git-Repositorys, Sicherungsdateien, anfälligen PHP-Skripten oder kürzlich veröffentlichten CVEs suchen. Die meisten dieser Anfragen erfolgen vollständig automatisiert und stammen von Bots, die das Internet fortlaufend nach verwundbaren Systemen durchsuchen.
In vielen Unternehmen werden solche Anfragen schlicht als Hintergrundrauschen hingenommen. Sie werden in Protokolldateien geschrieben, nach einigen Tagen rotiert und weitgehend ignoriert. Ich wollte einen anderen Ansatz verfolgen.
Anstatt Reconnaissance-Aktivitäten lediglich zu beobachten, sollte meine Infrastruktur verdächtiges Verhalten in Echtzeit erkennen und die Grundlage für eine automatisierte Reaktion schaffen. Dabei ging es nicht darum, jede fehlgeschlagene Anfrage zu blockieren. Vielmehr wollte ich anhaltende Ausspähversuche über mehrere Server und Anwendungen hinweg erkennen, bevor ein Angreifer auf ein lohnendes Ziel stößt.
Dieser Artikel bildet den Auftakt einer Serie, in der ich dokumentiere, wie ich mithilfe von Graylog, Fail2Ban, IPset und Docker Swarm eine verteilte Plattform zur Sperrung von IP-Adressen aufgebaut habe.
Das Problem herkömmlicher Blockmechanismus
Viele Administratoren setzen auf Werkzeuge wie Fail2Ban, um Dienste wie SSH, Mailserver oder Webanwendungen zu schützen. Solche Lösungen funktionieren effektiv, wenn eine einzelne Protokolldatei auf einem einzelnen Server überwacht wird. Meine Umgebung sah jedoch grundlegend anders aus.
Ich betreibe mehrere Anwendungen auf verschiedenen Docker-Swarm-Knoten. Auf jedem Knoten laufen zahlreiche Container, die unabhängig voneinander Apache-, Nginx-, Anwendungs- und Dienstprotokolle erzeugen.
Einem Angreifer ist gleichgültig, welchen Server er gerade untersucht. Er scannt lediglich den öffentlich erreichbaren Endpunkt. Da die Anfragen auf den gesamten Swarm verteilt werden, können sich verdächtige Aktivitäten über mehrere Knoten verteilen.
Für sich betrachtet würde keiner dieser Server einen herkömmlichen Blockmechanismus auslösen. In der Gesamtbetrachtung zeigt sich jedoch ein koordinierter Reconnaissance-Versuch mit mehr als 50 fehlgeschlagenen Anfragen von derselben IP-Adresse. Mit klassischer Protokollüberwachung lassen sich solche verteilten Aktivitäten nur schwer miteinander in Verbindung bringen.
Designziele
Bevor ich mit dem Aufbau der Plattform begann, definierte ich einige zentrale Designziele.
Die Lösung sollte:
Protokolldaten von allen Docker-Swarm-Knoten zentral erfassen,
Ereignisse aus mehreren Anwendungen miteinander korrelieren,
Reconnaissance-Aktivitäten statt einzelner Anfragen erkennen,
Fehlalarme auf ein Minimum reduzieren,
Erkennung und Durchsetzung voneinander trennen,
beim Hinzufügen neuer Server und Anwendungen skalierbar bleiben und
auch dann weiterarbeiten, wenn einzelne Knoten nicht verfügbar sind.
Ebenso wichtig war mir, dass der Sperrmechanismus unabhängig von Graylog bleibt. Erkennung und Durchsetzung sollten nur lose miteinander gekoppelt sein, sodass sich beide Komponenten unabhängig voneinander anpassen lassen, ohne das gesamte System neu konzipieren zu müssen.
Architekturübersicht
Die Gesamtarchitektur folgt einem einfachen Grundsatz: Transparenz zentralisieren. Durchsetzung dezentralisieren.
Warum Graylog?
Im Zentrum der Plattform steht Graylog. Jeder im Docker Swarm ausgeführte Container leitet seine Protokolldaten an eine zentrale Graylog-Instanz weiter. Dadurch entsteht eine einheitliche Übersicht über sämtliche Aktivitäten in der gesamten Umgebung, ohne dass jeder Server einzeln analysiert werden muss.
Anstatt unstrukturierte Textdateien auszuwerten, extrahiert Graylog unter anderem die folgenden strukturierten Felder:
Diese strukturierten Daten ermöglichen Verhaltensanalysen, die über einen einfachen Musterabgleich hinausgehen.
Graylog kann beispielsweise folgende Fragen beantworten:
Welche IP-Adresse hat die meisten HTTP-404-Antworten verursacht?
Welche IP-Adresse hat in mehreren Anwendungen Fehler ausgelöst?
Welcher Container erhält die meisten fehlgeschlagenen Anfragen?
Welche IP-Adresse durchsucht verschiedene virtuelle Hosts innerhalb des Clusters?
Mithilfe voneinander isolierter Protokolldateien lassen sich solche Fragen nur schwer beantworten.
Warum HTTP-400- und HTTP-500-Antworten überwachen?
Eine meiner ersten Entscheidungen war die Frage, welches Verhalten als verdächtig einzustufen ist.
Anstatt nach bestimmten Angriffsmustern zu suchen, konzentrierte ich mich auf HTTP-Statuscodes.
Wiederholte 4xx-Antworten deuten häufig auf Folgendes hin:
Anfragen nach nicht vorhandenen Ressourcen
verzeichnis enumerierung
ungültige API-Aufrufe
fehlgeschlagene Authentifizierungsversuche
automatisierte Schwachstellenscans
Wiederholte 5xx-Antworten können auf Folgendes hindeuten:
unerwartetes Anwendungsverhalten
ausgelöste Ausnahmen
Grenzfälle innerhalb eines Frameworks
Versuche, die Anwendungslogik auszunutzen
Eine einzelne HTTP-404-Antwort ist wenig aussagekräftig. Fünfzig HTTP-404-Antworten, die innerhalb von zwei Minuten von derselben IP-Adresse aus unterschiedliche Endpunkte betreffen, zeichnen hingegen ein völlig anderes Bild.
Durch die Konzentration auf Verhaltensmuster anstelle fester Signaturen bleibt die Erkennung auch dann wirksam, wenn Angreifer ihre Payloads verändern.
Verhalten statt Signaturen
Anstatt zu fragen:
„Hat jemand
/wp-login.phpaufgerufen?“
wollte ich folgende Frage beantworten:
„Verhält sich diese IP-Adresse wie ein automatisiertes Reconnaissance-Tool?“
Dieser Unterschied ist entscheidend. Angreifer verändern ihre Payloads fortlaufend, während sich typische Verhaltensmuster wesentlich seltener ändern.
Zu den charakteristischen Merkmalen gehören:
eine große Anzahl fehlgeschlagener Anfragen
Anfragen an zahlreiche unterschiedliche URLs
eine hohe Anfragerate
Zugriffe auf mehrere virtuelle Hosts
ungültige HTTP-Methoden
Anfragen an bekanntermaßen anfällige Endpunkte
Solche Indikatoren lassen sich erheblich schwerer umgehen als eine Erkennung, die beispielsweise nur auf dem verwendeten User-Agent-String basiert.
Vorbereitung auf eine automatisierte Reaktion
Eine wichtige Designentscheidung bestand darin, die Erkennung von der Durchsetzung zu trennen. Graylog verändert niemals direkt die Firewall-Regeln. Stattdessen erkennt es verdächtiges Verhalten und erzeugt eine Benachrichtigung, sobald ein definierter Schwellenwert überschritten wird. Ein dedizierter Sperrdienst prüft anschließend die Anfrage und entscheidet, ob eine Sperrmaßnahme eingeleitet werden soll.
Diese Trennung bietet mehrere Vorteile:
unabhängige Sicherheitskontrollen
einfachere Tests
ein geringeres Risiko versehentlicher Sperren
bessere Nachvollziehbarkeit
zukünftige Integration weiterer Sperrtechnologien
Der Sperrdienst selbst wird in Teil 2 dieser Serie behandelt.
Wie geht es weiter?
In diesem Artikel haben wir die Überlegungen hinter der Architektur betrachtet und erläutert, warum eine zentralisierte Protokollanalyse eine bessere Grundlage für die Erkennung von Reconnaissance-Aktivitäten in einer verteilten Umgebung bietet.
In Teil 2 bauen wir die Erkennungslogik innerhalb von Graylog auf. Dabei behandeln wir folgende Themen:
Protokollanalyse und Feldextraktion
Pipeline-Regeln
Stream-Design
Ereignisdefinitionen
Konfiguration von Schwellenwerten
Korrelationsstrategien
Reduzierung von Fehlalarmen
Tests der Erkennungslogik mit realem Reconnaissance-Datenverkehr
Quellen und weiterführende Literatur
Graylog-Dokumentation – Offizielle Dokumentation zu Installation, Pipelines, Streams, Ereignisdefinitionen, Alarmierungen, Dashboards und APIs.
Graylog-Pipeline-Dokumentation – Ausführlicher Leitfaden zu Pipeline-Regeln, Verarbeitungsstufen, Streams, Feldextraktion und Protokollanreicherung.
Dokumentation zum Docker-GELF-Logging-Treiber – Erläutert, wie Docker-Container ihre Protokolldaten mithilfe des GELF-Logging-Treibers direkt an Graylog übertragen können.
Dokumentation zum Graylog-Docker-Image – Offizielles Docker-Image sowie Hinweise zur Bereitstellung von Graylog in containerisierten Umgebungen.
Sicherheitsreferenzen
Die folgenden Quellen bieten nützliche Hintergrundinformationen zu den im Artikel behandelten Konzepten:
OWASP Web Security Testing Guide (WSTG) – Umfassende Methodik für Sicherheitstests von Webanwendungen.
OWASP Top 10 – Übersicht der häufigsten und schwerwiegendsten Sicherheitsrisiken für Webanwendungen.
MITRE ATT&CK Framework – Wissensdatenbank zu Taktiken und Techniken von Angreifern, einschließlich Reconnaissance und Ausnutzung von Schwachstellen.
Fail2Ban-Dokumentation – Offizielle Dokumentation zur Konfiguration von Fail2Ban und zur Verwaltung von Jails.
ipset-Handbuchseite – Offizielle Dokumentation zur effizienten Verwaltung von IP-Adressmengen unter Linux.
Netfilter-/iptables-Projekt – Offizielles Projekt für Paketfilterung und Firewall-Funktionen unter Linux.
Serienübersicht
Teil 1: Erkennung von Reconnaissance-Aktivitäten gegen Webanwendungen in einem Docker Swarm (dieser Artikel)
Teil 2: Aufbau der Erkennungslogik in Graylog
Teil 3: Entwicklung der API für den Sperrdienst
Teil 4: Automatisierte Durchsetzung mit Fail2Ban und ipset
Teil 5: Replikation von Sperrlisten auf allen Docker-Swarm-Knoten
Teil 6: Erfolgsmessung und Erkenntnisse aus dem laufenden Betrieb
Individuelle Sicherheitslösungen für Ihre Infrastruktur
Jede IT-Umgebung stellt andere Anforderungen an Überwachung, Angriffserkennung und automatisierte Abwehr. Wir entwickeln maßgeschneiderte Sicherheitslösungen, die auf Ihre Infrastruktur, Anwendungen und betrieblichen Abläufe abgestimmt sind – von zentraler Protokollanalyse und Echtzeitüberwachung bis hin zu automatisierten Sperrmechanismen.
Möchten Sie Ihre Systeme besser vor automatisierten Angriffen und anderen Bedrohungen schützen? Kontaktieren Sie uns für ein unverbindliches Gespräch.