Warum die Wartungs-Fenster?
Die auffällige Ruhe nach dem Wechsel auf BunkerWeb ist kein Zeichen dafür, dass die Angriffe aufgehört haben. Die Abwehr wurde lediglich nach vorn verlegt: weg vom bereits erreichten Server und hin zur ersten Schicht, die HTTP und HTTPS wirklich versteht. Wazuh bleibt wichtig, übernimmt aber wieder die Rolle, für die ein SIEM besonders wertvoll ist - beobachten, korrelieren und auf das reagieren, was die vorderen Linien übersehen.
Warum Wazuh allein zu spät reagierte
Wazuh hatte seine Arbeit gemacht. Sobald verdächtige Ereignisse auf einem überwachten System erkannt wurden, konnte eine Active Response ausgelöst und eine Quelladresse gesperrt werden. Das Problem lag für mich nicht in der Reaktion, sondern im Ort der Reaktion.
Damit Wazuh reagieren konnte, musste der relevante Datenverkehr bereits mehrere Schichten passiert und Spuren auf dem Zielsystem hinterlassen haben. Das ist vergleichbar mit einer Alarmanlage im Wohnzimmer: Sie löst zuverlässig aus, allerdings befindet sich zu diesem Zeitpunkt bereits jemand im Haus.
Die neue Reihenfolge der Schutzschichten
Das sollte sich ändern, als die Angriffe auf meine Infrastruktur enorm zugenommen hatten. Also habe ich qwen3.8 gefragt, was wohl die nächste Ausbaustufe meiner Anbindung sein könnte. Dabei kam ein Vorschlag, wie dieser, heraus:
Jede Schicht beantwortet eine andere Frage. Die externe Firewall/IDS prüft, ob eine Verbindung grundsätzlich erlaubt ist. BunkerWeb sieht den Inhalt der Webanfrage und kann typische Angriffs- und Botmuster erkennen. Die interne Firewall/IDS begrenzt Ziele und Ports. Wazuh betrachtet die Ereignisse über alle Systeme hinweg und reagiert aktiv auf allen beteiligten Systemen.
Eine Paketfilter-Firewall erkennt eine erlaubte HTTPS-Verbindung auf Port 443, aber ohne TLS-Terminierung nicht zuverlässig, ob darin ein Login, eine SQL-Injection oder ein harmloser Abruf steckt. Die WAF kann diese Unterscheidung treffen. Dafür ersetzt sie weder Netzwerksegmentierung noch Host-Härtung.
Was die Messkurve tatsächlich zeigt
Vor Beginn der Angriffswelle lag der Zähler der IP-Sperren durch Wazuh meist grob zwischen 100 und 300 Blockierungen pro Stunde. Danach folgten dichte Ausschläge bis ungefähr 3.800. Direkt nach der Umstellung von Nginx Proxy Manager auf BunkerWeb fiel die von Wazuh erfasste Zahl der zu verhängenden Sperren auf ein niedriges Grundniveau zurück.
Das ist ein starkes Indiz für eine Verlagerung der Blockierung, aber kein Beweis für verschwundene Angriffe. Gemessen wird, was Wazuh noch blockieren musste. Für eine belastbare Bewertung gehören Blockierungen in BunkerWeb, Active Responses in Wazuh sowie erfolgreiche Requests und Fehlercodes der Anwendungen nebeneinander.
Weniger aktive Arbeit für Wazuh
Wazuh bleibt für Vorgänge zuständig, die BunkerWeb nicht sehen kann: Dateiänderungen, Prozesse, Privilegienausweitung, SSH-Aktivität, Container-Ereignisse und Schwachstellen auf den Hosts. Die BunkerWeb-Logs gehören deshalb weiterhin ins SIEM. Wie beim Feintuning von BunkerWeb beschrieben, müssen insbesondere ModSecurity- und BADBEHAVIOR-Meldungen zuverlässig weitergeleitet werden.
Michael Meister
Die KI sitzt nicht am roten Knopf
Die KI beobachtet zusammengeführte Ereignisse und bewertet weiteren Handlungsbedarf. Die Durchsetzung bleibt deterministisch: Firewalls, WAF-Regeln und Wazuh-Responses entscheiden anhand nachvollziehbarer Regeln. Die KI kann priorisieren, Zusammenhänge erläutern und Maßnahmen vorschlagen. Dauerhafte Sperren benötigen klare Grenzen, Protokollierung und eine Rückrollmöglichkeit, die mir durch meine Virtualisierung recht einfach möglich ist. Der große Vorteil des ZFS ist meiner Meinung nach, dass man z.B. mittels zfs send ganze Festplatten per ssh auf einem anderen Server parken kann. Sie lassen sich dann ganz einfach per zfs receive wieder exakt zurückspielen. Eine Methode, die sich auch der Proxmox-Backup-Server zunutze macht.
Michael Meister
Defense in Depth statt Produktduell
Der Wechsel war keine Ablösung von Wazuh durch BunkerWeb. BunkerWeb steht näher an der Haustür, Wazuh näher an den Räumen und technischen Anlagen. Fällt eine Schicht aus, wartet dahinter eine weitere Kontrolle.
Die Backends sollten aus dem Internet ausschließlich über BunkerWeb erreichbar sein. Direkte Portfreigaben, alternative IPv6-Routen oder Management-Ports würden die Kette umgehen. Proxy-Header dürfen nur von bekannten Proxy-Adressen akzeptiert werden, damit keine fremde Client-IP eingeschleust werden kann.
Was im Betrieb geprüft werden sollte
- Von außen sind nur die vorgesehenen BunkerWeb-Listener erreichbar.
- Die interne Firewall erlaubt nur notwendige Ziele und Ports.
- WAF-Ausnahmen bleiben auf Pfad, Methode und Feld begrenzt.
- Access- und Error-Logs erreichen Wazuh vollständig.
- Ausfall und Fehlblockierung lassen sich ohne dauerhaften WAF-Bypass beheben.
Wenn Wazuh-Blockierungen plötzlich gegen null gehen, müssen BunkerWeb-Blockierungen oder sauber beantwortete Requests die Differenz erklären. Fehlen beide, wurde vielleicht nicht besser gefiltert, sondern schlechter gemessen.
Fazit
BunkerWeb verlegt die Abwehr von Webangriffen an die Haustür, während Wazuh dahinter Hosts überwacht, Ereignisse korreliert und bei Bedarf reagiert. Externe Firewall, WAF-Proxy, interne Firewall und Web-DMZ ersetzen einander nicht, sondern begrenzen gemeinsam den Schaden eines einzelnen Fehlers. Die KI ergänzt diese Kette als Beobachter und Analyst - nicht als unkontrollierter Generalschlüssel.