Zeile für Zeile

An Log-Dateien erinnert man sich häufig erst, wenn etwas vorgefallen ist. Doch zu einem sicheren Netz gehört es nicht nur, den Betrieb regelmäßig zu analysieren, sondern auch, auf Vorfälle reagieren zu können.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 4 Min.
Von
  • Lukas Grunwald

Zum Absichern eines Systems genügt es nicht, dieses einmal auf einem hohen Sicherheitsniveau aufzusetzen und zu pflegen. Auch die regelmäßige Kontrolle, Beobachtung und Betriebsanalyse spielen eine wichtige Rolle, will man sich vor Angriffen schützen. Hierzu dienen die Systemmitteilungen und Log-Dateien, die Auskunft geben über den aktuellen Gesundheitszustand des Systems, also die Verfügbarkeit im Normalbetrieb oder das Fehlverhalten einer technischen Komponente, aber auch über den Sicherheitszustand des Systems im gefährdeten Bereich.

Solche Log-Einträge in den Dateien stammen vom Systemkern, von Diensten und Benutzerskripten. Sie dienen der Erkennung und Auswertung von Vorfällen wie Angriffen auf das System, Portscans und Exploits ebenso wie von Ereignissen des allgemeinen Betriebs, etwa Verbindungsaufnahmen. Dadurch kann der Sicherheitsadministrator aktuelle Bedrohungsszenarien erkennen und daraufhin das System schützen, es gegebenenfalls vom Netz nehmen oder aktualisieren.

Unter Unix/Linux steht schon seit Jahren eine Methode der Ereignisprotokollierung zur Verfügung, das so genannte Syslog oder System-Logging. Das Syslog-System unterscheidet unterschiedliche Log-Level (Dringlichkeiten) und Log-Facilities (Zugehörigkeiten). Je nach Level und Facility geben klassische Systeme die Benachrichtigungen auf der Konsole aus, tragen sie in eine Log-Datei ein oder senden sie per E-Mail an die Administratoren. Bei einer großen Installation mit vielen Servern - etwa in einem Rechenzentrum - ist das aber nicht mehr handhabbar.

Um die Daten für eine Auswertung an zentraler Stelle zu sammeln, empfiehlt es sich, einen Log-Server zu betreiben. Seine Aufgabe ist es, die Daten vorzufiltern, das heißt, die sicherheitsrelevanten Daten soweit zusammenzuschrumpfen, das sie nur noch nach sicherheitskritischen respektive betriebskritischen Kriterien auszuwerten sind. Das Zusammenstellen solcher Auswertungskriterien kann recht aufwendig sein. Sie lassen sich nur im Regelbetrieb erstellen, indem man häufig auftretende Log-Ereignisse - den so genannten Common-Case - herausfiltert und Filterregeln für Meldungen über ungewöhnliche Ereignisse erarbeitet.

Ein weiterer Anwendungszweck eines Syslog-Servers ist es, die Log-Dateien einem Auditor zur Verfügung zu stellen - also einer Person aus der Revision, die regelmäßig den ordnungsgemäßen Betrieb der Server zu überwachen hat. Zu diesem Zweck transportiert der Log-Server die Dateien, die so genannten Audit-Trails, an einen weiteren Security-Auditation-Rechner, beispielsweise über einen SSH-Tunnel. Dort werden dann Audit-Listen erstellt, die etwa die Root-Log-ins der Administratoren protokollieren und anhand derer man das Verhalten der Administratoren auf den Systemen nachvollziehen kann.

Zwar unterstützt das klassische Syslog-Format das Weiterleiten an einen Log-Server. Allerdings gehen die Syslog-Meldungen als ungesicherte UDP-Datagramme übers Netz, was nicht besonders zuverlässig ist, da UDP nicht gegen den Verlust der Datagramme schützt. Zudem ist UDP nicht gegen Spoofing gesichert, also gegen das Fälschen respektive Ersetzen durch nichtssagende oder den Log-Server irritierende Meldungen. Man benötigt also einen neuen Mechanismus, das so genannte Secure Syslogging.

Auf dem Beispielserver soll das Syslog-NG- Syslog Next Generation - die Arbeit verrichten. Zwar existieren noch andere Secure-Syslog-Programme, die eine solche Aufgabe ebenfalls erfüllen, aber gegenüber Syslog-NG einige Nachteile aufweisen. Ein Beispiel ist das SDSC (Secure Syslog), das ebenfalls auf Protokoll-Level kompatibel mit Syslog „Classic“ (514/UDP) ist. Allerdings ist es noch nicht lange in der Praxis erprobt und durch sein übertriebenes Layering sowie seinen wissenschaftlichen Ansatz wesentlich schwerer zu handhaben als Syslog-NG.

Syslog-NG unterstützt neben UDP auch TCP und bietet trotz einfacher Handhabung viele unterschiedliche Log-Mechanismen, etwa das Weitergeben von Ereignissen an eine SQL-Datenbank. Ebenso kann es die Meldungen an Programme via Pipe oder durch Aufruf etwa eines SNMPv3-Inform-Sender weiterleiten. Eine weitere Stärke von Syslog-NG liegt in der Flexibilität der eingebauten Filter.

Im vollständigen Artikel in der Printausgabe lesen Sie mehr über die Konfiguration des Syslog-NG-Dämons, seine Einbindung in Alarmierungsketten und über das Timekeeping. Außerdem im Heft: Mandatory Access Control mit SE-Linux.

Mehr Infos

(sun)