Unternehmensweite Protokollierung von Systemereignissen:
Syslog, bitte zum Diktat

von Balázs Scheidler

Share
07.11.2007

Im Zusammenhang mit den aktuellen Compliance-Diskussionen gewinnt Syslog an Aktualität.

(Fortsetzung des Artikels von Seite 1)

Als Eric Allman Anfang der 80er Jahre an der University of California in Berkeley den bekannten Mail-Transfer-Agent »Sendmail« entwickelte, suchte er nach einem Weg, Status- und Ereignisinformationen seines E-Mail-Systems an einer zentralen Stelle zu sammeln und abzulegen. Quasi als Nebenprodukt entstand so Syslog, dessen Funktionen von anderen Entwicklern schnell in ihre Anwendungen integriert wurden. Heute sorgt der Begriff Syslog manchmal für Verwirrung, da er für mehrere Dinge verwendet wird. So bezeichnet Syslog einerseits ein Protokoll, das definiert, wie Systemereignisse formatiert und über Computernetze übertragen werden. Gleichzeitig steht Syslog für Programme, die Ereignismeldungen generieren, entgegennehmen, weiterleiten oder speichern.

Grundsätzlich unterscheidet man in einer Syslog-Umgebung drei verschiedene Rollen: Ein so genanntes Syslog-Gerät (Device) generiert Syslog-Nachrichten. Ein solches »Gerät« kann dabei eine Anwendung wie ein Webserver, ein Teil eines Betriebsystems oder auch ein Router, Switch oder eine Firewall sein. Ein Syslog-Kollektor oder Syslog-Server nimmt diese Nachrichten entgegen und speichert sie. In größeren Umgebungen kommen zusätzlich so genannte Syslog-Relays zum Einsatz, die als Syslog-Kollektoren Meldungen von Clients entgegennehmen und dann in der Rolle eines Syslog-Geräts an andere Syslog-Server weiter leiten.

Obwohl es Syslog nach IT-Zeitrechnung schon eine halbe Ewigkeit gibt, existierte das Protokoll lange Zeit lediglich als De-facto-Standard, der von keiner offiziellen Stelle dokumentiert und daher von verschiedenen Softwareentwicklern entsprechend kreativ interpretiert wurde. Erst im August 2001 veröffentlichte die IETF in der RFC 3164 den aktuellen Status quo von Syslog. Einen formellen Standard gibt es nach verschiedenen gescheiterten Anläufen bis heute nicht. Seit Anfang 2007 ist jedoch bei der IETF eine erhöhte Aktivität zu beobachten.

Funktionsweise von Syslog

Eine Syslog-Nachricht eines Syslog-Geräts besteht grundsätzlich aus drei Teilen: einem Selektor (Priority), einem Header und dem eigentlichen Inhalt. Der Selektor ist genau ein Byte groß und beschreibt einerseits die Herkunft der Nachricht sowie deren Wichtigkeit beziehungsweise den Schweregrad (Severity). Zur Berechnung des Selektors multipliziert man den Wert des Herkunftsfelds (Facility) mit acht und addiert dazu den Wert des Schweregrads der Meldung. Mit Hilfe einer Syslog-Priority-Matrix lässt sich diese leicht berechnen und entschlüsseln. Die ersten 16 Quellen von Syslog-Nachrichten sind von der RFC 3164 vordefiniert. Ein Selektor mit dem Wert 19 würde so einen Fehler in einem Mailsystem signalisieren. Dies hilft Administratoren später dabei, für sie relevante Nachrichten aus der Menge aller gesammelten Log-Informationen herauszufiltern.

Auf den Selektor folgt in einer Syslog-Nachricht ein Header. Dort stehen ein Zeitstempel sowie Informationen über das Gerät, das die Syslog-Meldung abgesetzt hat. Dies kann entweder eine IP-Adresse oder ein aufgelöster Hostname sein. Darauf folgt schließlich der eigentliche Inhalt der Nachricht, den der Sender beziehungsweise der Softwareentwickler frei definieren kann. Eine so komponierte Nachricht schickt ein Syslog-Gerät dann im Klartext über UDP an den Port 514 eines Syslog-Servers. Die maximale Länge einer Syslog-Meldung beträgt ein kByte.

Schwachstellen von Syslog

Auf Grund der ursprünglich recht simplen Architektur von Syslog treten dessen Schwachstellen recht schnell zu Tage. Eine ist zum Beispiel die Übertragungsweise der Nachrichten. Da ein Syslog-Gerät seine Meldungen verbindungslos über UDP schickt, gibt es keine Möglichkeit für einen Syslog-Server, den fehlerfreien Empfang aller gesendeten Nachrichten sicherzustellen. Denn da ein Kollektor nicht weiß, ob und wann von wem ein UDP-Paket an ihn geschickt wird und er keine Möglichkeit hat, mit dem Sender zu kommunizieren, ist die Übertragung von Syslog-Meldungen über UDP in der Praxis schlicht Glückssache. Überlastete Netzwerksegmente oder WAN-Verbindungen können hier schnell zum Verlust von Syslog-Informationen führen. Das selbe gilt, wenn ein Syslog-Server ausfällt oder vorübergehend nicht erreichbar ist. An diesen Server über UDP gesendete Nachrichten sind ebenfalls für immer verloren.

Ein weiteres Problem aus heutiger Sicht ist die Übertragung der Nutzdaten im Klartext. Sendet beispielsweise ein E-Mail-Server Informationen über fehlgeschlagene Anmeldeversuche eines Benutzers inklusive dessen Login und verwendetem Passwort per Syslog durch das Netz, kann ein Angreifer diese Daten mit einfachsten Mitteln mitlesen. Hatte der Benutzer bei der Eingabe des Passworts nur einen Buchstabendreher, kann der Angreifer daraus sofort dessen richtiges Passwort ableiten. Damit einher geht die fehlende Authentifizierung eines sendenden Geräts bei einem Syslog-Server. So können Angreifer leicht selber Syslog-Pakete generieren und im Netzwerk absetzen – beispielsweise in Form einer Replay- oder Flooding-Attacke.

Weitere Probleme treten in der Praxis durch verschiedene Verwendungen des Priority-Felds auf. Auch unterdrücken einige Syslog-Implementierungen bei der Weiterleitung von Nachrichten deren ursprüngliche Quelle, so dass der Syslog-Server am Ende nicht mehr weiß, von welchem System die Nachricht ursprünglich stammt. Andere Syslog-Server setzen als Zeitstempel lediglich den aktuellen Monat, Tag und die Uhrzeit, so dass spätestens nach einem Jahr Meldungen nicht mehr eindeutig zuzuordnen sind. Und schließlich nimmt gerade in größeren Umgebungen die Zahl an Syslog-Nachrichten schnell überhand. Hier wäre es also auf Relay- oder Server-Seite wünschenswert, nur bestimmte Nachrichten herauszufiltern, weiterzuleiten oder zu speichern.

Syslog – Next Generation

Einigen dieser Defizite nehmen sich verschiedene Weiterentwicklungen von Syslog an. Zu den Open-Source-Vertretern zählen beispielsweise Syslog-ng, modular Syslog oder rSyslog. Heute am verbreitetsten ist wohl Syslog-ng, dessen Entwicklung 1998 begann. Syslog-ng ist heute in vielen Linux-Distributionen wie Debian, Fedora, Gentoo oder Suse enthalten. In Suse-Linux ist Syslog-ng seit der Version 9.3 der standardmäßige Syslog-Server.

Um sicherzustellen, dass Syslog-Nachrichten nicht mehr auf Grund von Engpässen im Netzwerk verloren gehen, nutzt Syslog-ng statt UDP das verbindungsorientierte TCP als Transportprotokoll. Weiterhin verwendet Syslog-ng einen Zeitstempel, der das komplette Datum einschließlich der Uhrzeit inklusive Millisekunden und Zeitzone unterstützt. Weiterhin protokolliert die nächste Generation von Syslog alle bei einer Übertragung verwendeten Syslog-Relays in den Nachrichten, so dass am Ende der genaue Weg einer Meldung nachvollziehbar ist.

Dass Syslog-ng auf vielen verschiedenen Plattformen verfügbar ist, hat dabei ebenso zu dessen Verbreitung beigetragen wie die umfangreichen Filtermechanismen, die in den Syslog-Client und -Server Einzug gehalten haben. Über einfache bis hin zu hoch komplexen Regeln kann ein Syslog-ng-Server eingehende Nachrichten beispielsweise nach Herkunft, Schweregrad, Muster im Hostfeld sowie auf Basis von regulären Ausdrücken selektieren und so entscheiden, ob eine Nachricht wichtig genug ist, um weitergeleitet oder gespeichert zu werden.


Sicherheit, Vertraulichkeit und Authentizität

Der Einsatz von TCP als Transportprotokoll (RFC 3195) garantiert zwar, dass keine Meldungen mehr auf dem Übertragungsweg verloren gehen. Allerdings ist so noch nicht sichergestellt, dass bei Überlastung oder Ausfall eines Relays oder Servers der Syslog-Sender keine Nachrichten verwirft. Hier kann eine intelligente Flusskontrolle in Verbindung mit einer intelligenten Zwischenspeicherung Abhilfe leisten. In einer Syslog-Infrastruktur speichert dabei ein Relay alle empfangenen Nachrichten auf Festplatte, wenn dessen Zielserver gerade nicht erreichbar ist. Wenn sich die Kapazität seines Puffers dem Ende zuneigt, nimmt er zudem keine weiteren Meldungen mehr von Sendern entgegen. Verfügen diese ebenfalls über diese Mechanismen, werden die Meldungen dann dort zwischengespeichert.

Die Vertraulichkeit der Übertragung von Syslog-Nachrichten kann man durch den Einsatz der SSL-Verschlüsselung während der Übertragung sicherstellen. Kommen bei SSL zur Authentifizierung zudem X.509-Zertifikate zum Einsatz, können auch keine fremden Quellen einen Kollektor oder Server mit gefälschten Nachrichten überfluten.

Um Administratoren die Analyse von Syslog-Nachrichten zu erleichtern, kann es weiterhin sinnvoll sein, diese nicht in Textdateien, sondern in einer relationalen Datenbank abzulegen. In den zunehmend heterogenen IT-Umgebungen kommt weiterhin oft der Wunsch auf, auch Windows-Server in eine Syslog-Infrastruktur mit einzubeziehen. Von Haus aus unterstützt Windows Syslog nicht, sondern speichert entsprechende Informationen in einem lokalen Ereignisprotokoll, dem so genannten Event-Log. Spezielle Syslog-Agenten für Windows können die Informationen jedoch vor dort auslesen und per Syslog an einen zentralen Server schicken.

Einige dieser erweiterten Funktionen lassen sich mit Syslog-ng und weiteren Open-Source-Mitteln abbilden. Andere Features haben Anbieter kommerzieller Syslog-Server in ihren Applikationen umgesetzt.

Fazit

Insbesondere im Rahmen der Compliance-Diskussionen im Umfeld des Sarbanes-Oxley-Acts, von Basel II, des PCI-Data-Security-Standards oder des Health-Insurance-Portability-and-Accountability-Acts (HIPAA) erhält die Verwaltung von Logdaten eine erhöhte Aufmerksamkeit in Unternehmen. Denn die Zentralisierung aller Protokollinformationen aller Systeme kann Organisationen dabei helfen nachzuweisen, dass ihre Systeme und Daten nicht manipuliert wurden, keine Daten verloren gegangen sind und keine unberechtigten Personen auf Daten zugegriffen haben.

Um dies revisionssicher zu bewerkstelligen, muss jedoch der gesamte Weg einer Syslog-Nachricht von ihrer Entstehung bis zu ihrer verschlüsselten Speicherung vor Datenverlust und Manipulation geschützt sein. Im Schadensfall helfen zentrale Logdaten dann, ein Ereignis schnell zu rekonstruieren und entsprechende Maßnahmen daraus abzuleiten. Vielleicht ist das auch der Grund für das erneute Interesse der IETF an Syslog und die dort wieder auflebende Arbeit an der Standardisierung und Erweiterung des Protokolls.

Balázs Scheidler,
Geschäftsführer der Balabit Deutschland und Entwickler von Syslog-ng