Zentrales Logging unter Linux: Logs sammeln, auswerten und im Ernstfall nachweisen

Auf einem einzelnen Server ist die Lage übersichtlich: journalctl, ein paar Dateien unter /var/log, logrotate räumt regelmäßig auf. Sobald aber dreißig oder dreihundert Systeme im Spiel sind, kippt dieses Modell. Ein Vorfall zieht sich über Loadbalancer, Applikationsserver, Datenbank und Firewall, und du sitzt vor vier SSH-Sessions und versuchst, Zeitstempel im Kopf zu synchronisieren. Wenn ein System kompromittiert wurde, ist ausgerechnet dessen lokales Log die unzuverlässigste Quelle, weil jemand mit Rootrechten Einträge löschen oder verändern kann.

Dazu kommt der regulatorische Druck. NIS2 verlangt von betroffenen Einrichtungen eine Frühwarnung innerhalb von 24 Stunden und einen Bericht nach 72 Stunden. Diese Fristen hältst du nur ein, wenn die Daten schon vor dem Vorfall an einer Stelle liegen, mit definierter Aufbewahrung und durchsuchbar. Wer erst nach dem Alarm anfängt, Logs einzusammeln, verliert genau die Zeit, die er für die Analyse bräuchte.

Typische Fehler wiederholen sich dabei in fast immer derselben Reihenfolge. Es wird alles auf höchstem Loglevel eingesammelt, der Storage läuft nach wenigen Wochen voll, danach dreht jemand die Aufbewahrung auf sieben Tage herunter und die Nachweisfähigkeit ist wieder weg. Oder die Zeitquelle stimmt nicht, weil chrony auf einem Teil der Systeme nie sauber konfiguriert wurde, und die Korrelation über mehrere Hosts wird zur Ratearbeit. Und sehr oft fehlt die Zugriffskontrolle: Wenn dieselben Konten, die Systeme administrieren, auch die zentrale Logablage schreiben und löschen dürfen, ist die Beweiskraft der Daten praktisch dahin.