Ein SIEM für eine Flotte von 38 Maschinen: Wazuh, von der Dimensionierung bis zur Feinabstimmung

Jeder Server erzeugt Protokolle. Solange sie auf der Maschine bleiben, taugen sie nur für eines: im Nachhinein zu verstehen, vorausgesetzt, der Angreifer hat sich nicht die Mühe gemacht, sie zu löschen. Ein SIEM bringt diese Protokolle außer Reichweite, korreliert sie und macht aus Zeilen Fragen, die sich beantworten lassen: Haben wir diesen SSH-Schlüssel hinzugefügt? Ist diese gesperrte Adresse am Ende doch hereingekommen? Im September haben wir Wazuh auf unserer gesamten Serverflotte eingeführt. Hier sind der Aufbau und vor allem das, was zwischen der Installation und einem wirklich lesbaren Werkzeug passiert ist.

Warum jetzt und warum Wazuh #

Drei Gründe kamen zusammen. Der Bastion hatte gerade alle Zugriffe zentralisiert: Seine Spuren verdienten mehr als eine lokale Festplatte. Unser Selbstaudit nach den Maßnahmen der ANSSI, der französischen Cybersicherheitsbehörde, wies die zentrale Protokollierung als nicht abgedeckte Hygienemaßnahme aus, mit einer empfohlenen Aufbewahrung von sechs Monaten bis zu einem Jahr. Und die DSGVO (Art. 32) erwartet von einem Hoster, dass er eine Verletzung erkennen und dokumentieren kann, statt sie nur zu erleiden. Wazuh setzte sich durch, weil es Open Source und vollständig ist (Erfassung, Erkennung, Dateiintegrität, Konformitätsprüfung, Reaktion) und mit einem schlanken Agenten auf jeder Maschine arbeitet. Wir sind bewusst beim Zweig 4.x geblieben statt bei der ganz neuen Hauptversion, die zum Zeitpunkt der Wahl nicht für die Produktion empfohlen war.

Dimensionieren: die drei Dinge, die der Installer nicht erledigt #

Eine eigene VM, 8 vCPU, 16 GB RAM, 250 GB, mit zwei Netzwerkschnittstellen: eine im internen Netz, eine im öffentlichen Adressblock. Ohne die zweite würden die dreißig internen Agenten über das Gateway hinausgehen und alle unter derselben Adresse erscheinen, in einem Werkzeug, dessen Aufgabe genau darin besteht zu sagen, was woher kommt. Die Firewall des Hypervisors wurde vor dem ersten Start geschrieben (die Falle der deklarierten, aber wirkungslosen Firewall), und kein Dienst ist öffentlich erreichbar, mit Ausnahme des Ports, der für die Erneuerung des Zertifikats nötig ist; die Konsole ist auf zwei Adressen beschränkt. Den Rest erledigt der automatische Installer, bis auf drei Dinge, die wir selbst korrigieren mussten:

1. Der Arbeitsspeicher des Indexers ist auf 1 GB festgelegt, unabhängig vom RAM der Maschine. Bei 16 GB ergibt das eine Maschine, die erst kriecht und dann stehen bleibt. Auf 8 GB angehoben, Minimal- und Maximalwert identisch.
2. Standardmäßig gibt es keine Aufbewahrungsrichtlinie: Die Indizes wachsen unbegrenzt. Wir haben zwölf Monate für die Alarme und neunzig Tage für die technischen Indizes festgelegt, mit automatischer Löschung. Die Aufbewahrung ist eine dokumentierte Entscheidung (Verarbeitungsverzeichnis nach DSGVO), kein Zufall einer vollen Festplatte.
3. Die Rohdatenarchive sollten Sie abschalten: Sie speichern alle Ereignisse, nicht nur die Alarme, und lassen den Speicherbedarf explodieren, ohne einen entsprechenden Wert für Ermittlungen.

38 Agenten in drei Wellen, und zuerst ein Pilot #

Vor dem ersten Agenten wurde der Manager vorbereitet: sechs Gruppen (interne Dienste, Anwendungen, öffentliche Infrastruktur, Hypervisoren, Edge, Mail), weil die Konfiguration pro Gruppe gesteuert wird und alles in der Standardgruppe eine spätere Unterscheidung unmöglich macht. Und eine unangenehme Entdeckung: Die Registrierung verlangte kein Passwort. Jede Maschine im internen Netz konnte sich als Agent anmelden. Vor der ersten Welle behoben. Der Pilot war ein interner Container ohne jede Bedeutung für Kunden: eine bessere Wahl als eine Produktivanwendung, um zu messen, was ein Agent tatsächlich erzeugt.

⟷ seitlich scrollen

Die Feinabstimmung: von 1.250 Alarmen auf 8 #

Der erste Scan des Piloten, ein einziger Container, erzeugte 1.250 Alarme. Hochgerechnet auf die 38 Maschinen wären das 47.000 Alarme allein bei der Registrierung gewesen, und ein Werkzeug, das niemand je wieder geöffnet hätte. Die Auswertung pro Regel zeigte, dass die CIS-Konformitätsprüfung nur 30 % des Rauschens ausmachte. Der eigentliche Fehlalarm kam vom rootcheck im Container: Er hält die Laufzeitdateien eines LXC in /dev für Hinweise auf ein Rootkit, auf Stufe 7. Auf unseren 26 Containern waren rund 2.500 leere Alarme zu erwarten.

Die richtige Vorgehensweise besteht nicht darin, Module abzuschalten. Der mitgelieferte Regelsatz trennt bereits den Zustand von der Abweichung: Die Regeln, die bei jedem Scan das Konformitätsinventar neu veröffentlichen, wurden auf Stufe 0 gesenkt, während diejenigen, die eine Prüfung melden, die von bestanden auf nicht bestanden gewechselt ist, auf Stufe 9 bleiben. Die Konformitätskonsole wird weiterhin gespeist, da ihre Ergebnisse in einer vom Alarmindex getrennten Datenbank liegen. Der rootcheck auf /dev wurde für die Gruppen mit Containern abgeschaltet, und nur für diese: Die neun öffentlichen Maschinen haben einen eigenen Kernel und kennen diesen Fehlalarm nicht. Gemessenes Ergebnis auf der gesamten Flotte: 8 Alarme für 38 Agenten im Kontrollzeitraum, alle ausgelöst durch unsere eigenen Verbindungen.

Drei Ausgänge, je eine Schwelle #

Ein SIEM ohne Empfänger ist eine Festplatte, die sich füllt. Unsere Regel hängt an der Schwelle, mehr als am Kanal: ab Stufe 12 sofortige Benachrichtigung im Alarmkanal des Teams; 7 bis 11 tägliche Zusammenfassung per Mail um sieben Uhr; darunter nur die Konsole. Die Zusammenfassung erforderte ein eigenes Skript, weil Wazuh keine SMTP-Authentifizierung beherrscht und ein lokales Relay erwartet, was unserer Regel widerspricht, ausgehende Mails über eine authentifizierte API zu versenden. Und jeder Ausgang wurde von Ende zu Ende geprüft, mit einer temporären Regel der Stufe 12, ausgelöst durch eine fingierte Protokollzeile und danach wieder entfernt: das Rezept, um einen Ausgang zu testen, ohne auf einen echten Vorfall zu warten.

Die Erkennungen, auf die es wirklich ankommt #

• Jede Änderung an einer Datei authorized_keys auf den 38 Maschinen, in Echtzeit, mit dem Diff im Alarm (Stufe 14). Das ist die Antwort auf „Jemand hat sich irgendwo einen Schlüssel verschafft“: der Blickwinkel, den der Bastion nicht abdeckt.
• Die Verwendung des Offline-Notfallschlüssels, erkannt an seinem Fingerabdruck in einer erfolgreichen Anmeldung: Stufe 15, das Maximum. Er darf nie benutzt werden, ohne dass wir es wissen.
• Die Konformität dieses Notfallschlüssels, über eine eigene Prüfrichtlinie: Die öffentlichen Maschinen müssen ihn tragen, die internen Container dürfen ihn nicht tragen. Ein eigenes Dashboard zeigt den Zustand jeder Maschine, stündlich aktualisiert.
• Die Korrelation mit CrowdSec: gesperrte Adresse und danach erfolgreiche SSH-Verbindung, Stufe 13.

SSO mit zwei Ebenen und ein lokales Konto, das bleibt #

Die Konsole ist an unseren IdP angebunden, aber Wazuh hat zwei Autorisierungsebenen: das Rollen-Mapping des Indexers und die Zugriffskontrolle der Manager-API, weil das Dashboard den Kontext des Benutzers weiterreicht. Ohne Regel in der zweiten Ebene ist man angemeldet, die Anwendung aber leer, mit einer allgemeinen Fehlermeldung. Und die Mapping-Datei auf der Festplatte bewirkt nichts, solange sie nicht in den Sicherheitsindex übertragen wurde: Prüfen Sie über die API, nie durch Lesen der YAML-Datei. Das lokale Administratorkonto bleibt neben dem SSO aktiv: nie ausschließlich SSO auf einem SIEM, denn das ist das Werkzeug, das man öffnet, wenn alles andere schiefläuft.

Was noch offen ist #

Wir sagen es, weil es stimmt: Die VM des SIEM hat noch keine Speicherreplikation zwischen den Knoten, ihre Wiederherstellung läuft also über das Backup, mit möglichem Datenrückstand. Die Agenten wurden von Hand in drei Wellen ausgerollt; daraus muss eine Automatisierungsrolle werden, damit jeder neue Host registriert wird, ohne dass man daran denken muss (siehe unseren Lebenszyklus der Maschinen). Maschinen, die an Kunden vermietet sind und von ihnen selbst administriert werden, liegen bewusst außerhalb des Geltungsbereichs. Und die Frage, die jedes SIEM irgendwann stellt, bleibt auch unsere: Wer liest die Alarme? Die Schwelle und die tägliche Zusammenfassung sind unsere Antwort; sie werden im Betrieb nachjustiert.

Einen mitten in der Nacht hinzugefügten Schlüssel erkennen, einen Zugriff abspielen, einem Auditor zwölf Monate Protokolle nachweisen: Genau das umfassen unsere Managed Services über das Hosting hinaus. Wenn Ihre Protokolle die Maschine, die sie erzeugt, nie verlassen, sprechen wir darüber.