Die Revolution der neuen Generation

Ein häufig vernachlässigtes Thema ist das Speichern und Auswerten von Log-Meldungen. Dabei bieten sie eine sehr gute Möglichkeit, Unregelmäßigkeiten auf einem System aufzudecken. Aber wer kennt es nicht? Riesige Logfiles mit Unmengen an uninteressanten Informationen, die auch noch von vielen verschiedenen Anwendungen stammen. Syslog-ng bietet im Gegensatz zum altbewährten syslog wesentlich mehr Funktionen, um Log-Meldungen zu filtern, bevor sie weggeschrieben werden. Seine wahre Stärke spielt er aber erst aus, wenn er als zentraler Server für Log-Meldungen im Netzwerk dient. Dieses Thema wird in einer der nächsten ORDIX News erörtert. Dieser Artikel erläutert zunächst die grundlegende Konfiguration mit Schwerpunkt auf das Filtern von Log-Meldungen.

syslogd syslog-ng (OSE) syslog-ng (PE) Übertragung von Meldungen mittels TCP (verbindungsorientiert) X X Filtern von Meldungen anhand ihres Inhalts X X Nutzt Makros, um dynamisch Zieldateien, Verzeichnisse und Tabellen anzulegen X X IPv6 Support Abhängig vom OS X X Meldungen per TLS verschlüsselt übertragen X Zwischenspeichern von Meldungen auf der Festplatte, um bei einem Ausfall der Netzwerkverbindung keine Informationen zu verlieren X Direktes Speichern von Meldungen in einer Datenbank X Meldungen, die zu einem Ziel gesendet werden, können in der Anzahl limitiert werden X Windows Support X Abb. 1: Unterschiede der einzelnen Syslog-Daemons. Abb. 2: Aufbau von syslog-ng.

Einführung

New Generation? Ganz neu ist das Projekt in Wirklichkeit nicht mehr. Die Entwicklung begann bereits 1998, als Balázs Scheidler den nsyslogd (BSD) auf Linux portierte. In den letzten zehn Jahren hat sich der syslog-ng von einem kleinen Projekt zum Standard Syslog- Daemon in vielen Distributionen entwickelt. Zum Beispiel setzt SuSE seit der Version 9.3 standardmäßig auf den syslog-ng, den es in zwei Versionen gibt: Eine Open Source Variante (OSE) und die so genannte Premium Edition (PE). Beide Varianten werden von der Firma BalaBit IT Security entwickelt.

syslog, syslog-ng (OSE) und syslog-ng (PE) im Vergleich

Bevor wir genauer auf die Open Source Edition eingehen, sollen die Unterschiede der einzelnen Syslog-Daemons aufgezeigt werden. Die Tabelle in Abbildung 1 zeigt die Funktionen, die der syslog-ng zusätzlich zu dem syslogd unterstützt.

Auch werden die Unterschiede zwischen den beiden syslog-ng-Varianten deutlich aufgezeigt. Im Laufe des Artikels wird der Aufbau der Konfiguration näher erläutert.

Ablauf eines Log-Vorgangs

Unter /etc/syslog-ng/syslog-ng.conf liegt standardmäßig die Konfiguration des syslog-ng. Sie lässt sich am besten verstehen, wenn man sich den Ablauf eines Log-Vorgangs visualisiert (siehe Abbildung 2).

1. Eine Applikation generiert eine Log-Meldung und schickt diese beispielsweise an den default Log-Socket des Systems.
2. Aus diesem Socket (source) liest der syslog-ng die Meldungen.
3. Ein oder mehrere Source-Objekte, Filter und Destinationen bilden eine so genannte Log-Anweisung, in der definiert wird, dass ...
4. ... die Meldungen aus dem Source-Objekt, die auf den Filter passen, an das im Destination angegebene Ziel geschickt werden.

Source-Objekt

Ein Source-Objekt beschreibt die Quelle aus der Syslog, die Meldungen empfangen soll. Es können beliebig viele Source-Objekte konfiguriert werden. Um mit syslog-ng alle Meldungen zu empfangen, die auch der alte sys-logd standardmäßig empfangen hat, müsste man folgendes Objekt konfigurieren:

source s_src { 
	unix-stream("/dev/log");
	internal(); 
};

Source sagt aus, dass es sich bei dem folgenden Statement um ein Source-Objekt handelt, s_src ist nur ein Name für das Objekt. In den geschweiften Klammern steht der ausschlaggebende Teil: Unix-stream("/dev/log") öffnet den Socket /dev/log (default Log- Socket) und liest alle eingehenden Meldungen. Mit internal() werden zusätzlich die internen Meldungen des Syslog-Daemons aufgefangen.

Syslog-ng kann Meldungen noch aus vielen anderen Quellen, wie z. B. einer Pipe oder einem TCP-Socket lesen. Auf jede Möglichkeit einzugehen, würde jedoch den Umfang dieses Artikels sprengen. Die Dokumentation der Entwickler bietet aber sehr gute und detaillierte Informationen [1].

Filter-Objekt

Welche Meldungen an eine Destination weitergeschickt werden, wird über einen Filter definiert. Dabei ist es nicht nur möglich, nach der Facility und der Priorität zu filtern, sondern es können unter anderem auch reguläre Ausdrücke auf den Nachrichtentext angewendet werden.

filter f_sexample { 
	priority(err...emerg);
	match("test"); 
};

Dieser Filter würde auf alle Meldungen passen, die vom Level error bis emergency sind und im Nachrichtentext "test" enthalten. Da das Filter-Objekt sehr mächtig ist, sollen an dieser Stelle noch einige Möglichkeiten aufgezeigt werden. Zu den im Beispiel schon genannten Funktionen kommen noch folgende hinzu

• facility(facility[,facility])
Filtern nach den angegebenen Facilities


• filter(filtername)
Ruft einen anderen Filter auf und überprüft ihn


• host(regexp)
Der Reguläre Ausdruck muss auf den Host-Namen passen

netmask(ip/mask) Überprüft die IP-Adresse des sendenden Hosts


• program(regexp)
Der Reguläre Ausdruck muss auf den Programmnamen passen

Destination-Objekt

Eine Destination ist im einfachsten Fall eine Datei. Es ist also das Ziel gemeint, an das die Meldungen geschickt werden sollen. Im folgenden Konfigurationsabschnitt wird das Ziel d_messages definiert, hinter dem sich die Datei /var/log/messages verbirgt.

destination d_messages { 
	file("/var/log/messages");
};

Als Ziel muss aber nicht immer eine Datei definiert werden, auch andere Ziele sind möglich: Wählt man als Ziel z. B. usertty("root"), werden die Meldungen an das Terminal vom User root geschickt.

Log-Anweisung

Schlussendlich werden die einzelnen Objekte in einer Log-Anweisung zusammengefasst. Erst hier wird festgelegt, welche Meldungen, von welchen Quellen, an welche Ziele geschickt werden sollen.

log { 
	source(s_src); 
	filter(f_example); 
	destination(d_messages); 
};

So können flexibel verschiedene Source-, Filter- und Destination-Objekte kombiniert werden. Das ermöglicht es, die Meldungen schon im Vorfeld sinnvoll auf verschiedene Dateien aufzuteilen und uninteressante Meldungen herauszufiltern.

Ausblick

Der syslog-ng erlaubt wesentlich mehr Filtermöglichkeiten als der alte Syslog-Daemon und er hat sich in den letzten Jahren zum Standard in vielen Distributionen entwickelt. Und da unserer Erfahrung nach nichts gegen den Einsatz spricht, können wir Ihnen den syslog-ng uneingeschränkt empfehlen.

Im nächsten Teil des Artikels möchten wir darauf eingehen, welche Vorteile das zentrale Speichern von Log-Meldungen bietet und welche Möglichkeiten es gibt, die Log-Meldungen verschlüsselt über das Netzwerk zu übertragen.

Seitenanfang

Seite drucken

Seite weiterempfehlen