© epicstockmedia, 123RF

In den Logdateien eines Linux-Systems und seiner Dienste rauscht vorüber, was auf dem Rechner passiert. Tools wie Logcheck und Logsurfer filtern die wichtigsten Ereignisse für den Admin heraus – oder leiten sogar automatisch die passende Reaktion ein.

Wichtige Updates einspielen, auf kritische Ereignisse reagieren: Ein Systemadministrator muss stets eine Vielzahl von Aufgaben bewältigen. Umso besser, wenn er beruhigt einige dieser Pflichten an smarte Software abgeben kann. Längst gibt es Tools für die Loganalyse, die mit Hilfe klar definierter Regeln automatisiert auf Ereignisse reagieren.

Das Wichtigste per Mail

Das zeitaufwändigste Verfahren, Systeme zu beobachten, besteht in dem regelmäßige Blick in die Logdateien – doch das wird schnell monoton und aufreibend. Das Programm Logcheck schafft Abhilfe. Einmal installiert, überwacht es standardmäßig »/var/log/syslog« und »/var/log/auth.log« . Dabei filtert es belanglose Events aus, womit der Systembetreuer nur noch eine Mail mit einer Zusammenfassung der wichtigsten Ereignisse erhält (Abbildung 1).

Abbildung 1: Logcheck extrahiert die wichtigsten Meldungen und schickt sie als Mail an den Admin.

Mit dem richtigen Mailclient und entsprechenden Filtern lassen sich die Logs von Hosts oder Gruppen in Ordner einsortieren. So hat der Administrator alle Systeme im Blick, ohne sich auf diesen einloggen zu müssen. Logcheck [1] greift für die Überwachung der Logs übrigens auf das Programm Logtail zurück, das meist im selben Paket steckt.

Logtail kümmert sich darum, nur die Zeilen einer Datei auszugeben, die bisher noch keine Beachtung fanden. Hierfür legt es zu jedem Log eine weitere Datei mit der Bezeichnung »Dateiname.offset« an und speichert Informationen zum Inode der Logdatei. Zusätzlich hält es fest, bis zu welcher Stelle es ein Logfile bereits ausgelesen hat. Würde die Offsetdatei keine Informationen zum Inode dieses Log enthalten, würde Logtail neue Logs nicht erkennen und die Aktionen von Logrotate brächten das durchdachte System durcheinander.

Der im Installationspaket enthaltene Cronjob unter »/etc/cron.d/logcheck« sorgt für den stündlichen Versand der Meldungen, die Logcheck seit dem letzten Mal aus den Logs extrahiert und für wichtig befunden hat. Zusätzlich sendet das Tool eine solche Mail nach jedem Systemstart. Listing 1 zeigt, wie eine Logcheck-Mail aussieht. Der Inhalt der Dateien unter »/etc/logcheck/ignore*« legt fest, welche Meldungen das Tool ausfiltert und aus seinen Mailreports entfernt.

01 Feb 20 23:12:14 jupiter qmail: 1329775934.816939 delivery 19626: deferral: Sorry,_I_wasn't_able_to_establish_an_SMTP_connection._(#4.4.1)/
02 Feb 20 23:16:23 jupiter su[15621]: Successful su for logcheck by root

In diesem Listing finden sich zwei Zeilen, die Logcheck per Mail versenden würde. Die erste enthält eine Meldung des Mailservers Qmail, der sich über den fehlerhaften Verbindungsaufbau zum SMTP-Server des Empfängers einer Nachricht beschwert. Der zweite Eintrag hingegen weist den Systembetreuer auf ein erfolgreiches »su« für den Benutzer Logcheck hin. Beide Meldungen sind es wert, per Mail versandt zu werden.

Logcheck beschränkt sich auf das Filtern von Meldungen und das Verschicken entsprechender Logmails. Besonders bei Debian-basierten Distributionen wird es aber mit einer sehr sinnvollen Vorkonfiguration für viele Dienste ausgeliefert. Zusätzlich enthalten die Debian-Pakete vieler Dienste, etwa des MySQL-Servers, ebenfalls eigene Logcheck-Filter. So kann der Admin mit wenig Aufwand eine sehr gute Filterung seiner System-Logs erreichen.

Einigen Admins wird das eine Alternative zu Logcheck in Erinnerung rufen: Logdigest. Dieses Programm funktioniert ähnlich wie Logcheck, wird jedoch seit November 2009 nicht mehr aktiv weiterentwickelt. Das geplante Rewrite sowie eine Neuauflage des Tools in Python haben die Entwickler bisher nicht realisiert. Wer sich dennoch mit Logdigest auseinandersetzen möchte, findet unter [2] Lesematerial.

Logtail

Beim Beobachten von Logdateien zeigen sich bestimmte Events. Es liegt daher nahe, auf einige dieser Ereignisse mit festlegbaren Aktionen zu reagieren, natürlich automatisiert. Den Logcheck-Helfer Logtail kann der Admin auch dazu verwenden, auf bestimmte Ereignisse automatisch zu reagieren.

Dazu legt er einen Cronjob an, der regelmäßig eine Protokolldatei prüft. Die Ausgabe lässt sich mit einem Werkzeug wie Grep oder einem Perl-Skript filtern. Erkennt das Programm ein bestimmtes Muster, kann es eine Aktion auslösen. Diese Aktion besteht vielleicht einfach nur aus einer Mail-Benachrichtigung wie bei Logcheck. Daneben kann der Admin auf diese Weise aber auch Dienste neu starten oder andere Kommandos aufrufen. Listing 2 zeigt einen Cronjob, der den MySQL-Daemon neu startet, wenn er ausgefallen sein sollte.

01 * * * * * root /usr/sbin/logtail /var/log/syslog | grep -q "mysql exited unexpected" && /etc/init.d/mysql restart

Schneller Logsurfer

Ein großer Nachteil von Logcheck und Logtail ist, dass der Admin sie über Cron regelmäßig aufrufen muss und die Programme dadurch nicht unmittelbar reagieren. Das lässt sich mit dem Einsatz von Logsurfer [3] ändern. Dieses auf dem Loganalyse-Tool Swatch basierende Programm hängt sich wie »tail« an ein Logfile und erfasst neue Einträge zur Laufzeit. Da Logsurfer in C geschrieben ist, ergibt sich auch ein Performancevorteil gegenüber dem in Bash realisierten Logcheck.

Während Logcheck einfach nur bekannte Logmeldungen mit einem regulären Ausdruck ausfiltert, verwendet Logsurfer leistungsfähige Regeln. Deren grundsätzlichen Aufbau demonstriert Listing 3. Dabei gibt »Match_regex« den regulären Ausdruck an, der auf die gesuchte Logzeile passt. Mit dem zweiten Feld »Not_match_regex« kann der Anwender Muster ausschließen. Findet »Stop_regex« einen Treffer, streicht Logsurfer die Regel von der aktuellen Liste der aktiven Regeln, das Feld »Not_stop_regex« beschreibt wieder die Ausschlusskriterien. Der Timeout-Eintrag definiert, wie lange die Regel aktiv sein soll. Wer an dieser Stelle eine 0 angibt, legt die Gültigkeit als unbegrenzt fest.

01 Match_regex Not_match_regex Stop_regex Not_stop_regex Timeout [continue] Action [...]

Die optionale Angabe »continue« teilt dem Programm Logsurfer mit, dass es die aktuelle Zeile auch dann parsen soll, wenn eine zuvor definierte Regel zutrifft. Tatsächlich hört Logsurfer standardmäßig nach dem ersten Treffer auf, eine Zeile zu verarbeiten. Das Minuszeichen »-« lässt sich zum Markieren unbenutzter Felder verwenden.

In Aktion treten

Tabelle 1 zeigt die möglichen Schlüsselwörter für die Aktion im letzten Feld. Jeder Regel kann der Admin eine eigene Aktion zuweisen, um auf verschiedene Ereignisse auch unterschiedlich zu reagieren. Neben dem Ausführen beliebiger Programme mit den »exec« – und »pipe« -Aktionen erstellt die »open« -Aktion kontextabhängige Regeln. Dabei speichert die Software sämtliche Zeilen, die auf einen regulären Ausdruck passen. Die »report« -Aktion gibt sie später als kompletten Block zusammenhängender Logeinträge aus.

Tabelle 1: Werte für »action«” width=”300″ height=”128″ /> Tabelle 1: Werte für »action«

Listing 4 enthält ein einfaches Beispiel für eine Regel, die beim Ereignis »Out of memory« eine Mail mit der entsprechenden Logzeile verschickt. Der erste reguläre Ausdruck trifft auf Zeilen mit der Zeichenkette »kernel: Out of memory« zu. In diesem Fall schickt die Regel eine Mail an Root. Der Betreff der Mail verwendet Variablen aus dem Suchmuster, um betroffene Prozess-ID (»$2« ) und weitere Informationen (»$3« ) hinzuzufügen. Daneben übergibt die Regel die komplette Logzeile an die Standardeingabe des Programms »mailx« .

01 'kernel: Out of memory: Kill process ([0-9]*) (.*)'- - - 0
02         pipe "/usr/bin/mailx -s \"Warning! Out of memory! Process $2 killed: $3\" root "

Ein komplexeres Beispiel demonstrieren die drei Regeln in Listing 5. Sie erkennen SSH-Sessions und zeigen alle Daten der Session, falls der Benutzer ein falsches Passwort angibt. Passiert innerhalb der SSH-Sitzung nichts Auffälliges (ist also das Passwort korrekt), verwerfen die Regeln die Logmeldungen.

01 '^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ sshd\[([[:digit:]]+)\]: .*' - - - 0 continue
02         open "$2" - 5000 86400 3600
03         report "/bin/cat" "$2"
04
05 '^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ sshd\[([[:digit:]]+)\]: Failed password .*' - - - 0
06         report "/bin/cat" "$2"
07
08 '^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ sshd\[([[:digit:]]+)\]: Connection closed.*' - - - 0
09         delete "$2"

Kontexte als Zwischenspeicher

Das Tool Logcheck könnte in diesem Szenario allenfalls die Logzeile »Failed password« herausfiltern, aber keine weiteren Informationen zur SSH-Session liefern. Alternativ könnte der Admin alle SSH-Logzeilen herausfiltern. Dann würde er aber mit zu vielen überflüssigen Informationen überschüttet und die wirklich wichtigen Zeilen dürften ihm entgehen. Logsurfer löst dieses Problem mit den so genannten Kontexten. Sie bieten die Möglichkeit, bestimmte Zeilen zwischenzuspeichern und bei Bedarf erneut zu verwenden.

Die drei Regeln in Listing 5 ergeben nur in ihrer Kombination einen Sinn. Auf Debian-basierten Systemen lassen sie sich auf die Logdatei »/var/log/auth.log« anwenden. Der Einfachheit halber geben sie alle Informationen direkt auf der Konsole aus. Es wären aber auch andere Aktionen möglich, und sei es nur die, eine Mail zu schicken.

Die erste Zeile erkennt alle Logzeilen des SSH-Daemon. Die Aktion »open« eröffnet einen neuen Kontext. Dabei benutzt die Regel die PID (in eckigen Klammern nach »sshd« ) der jeweiligen SSH-Sitzung, um jene Zeilen zu erkennen, die zu einer SSH-Session gehören. Zusätzlich definiert sie Timeouts. Laufen diese ab, geben die Regeln ebenfalls die Session-Daten aus. Wichtig ist an dieser Stelle das Schlüsselwort »continue« , damit auch die nachfolgenden Regeln zum Zuge kommen.

Enthält eine Logzeile den Eintrag »Failed password« (Zeile 5), gibt dieses Beispiel den kompletten Kontext der SSH-Session auf der Konsole aus. Wieder dient die PID der SSH-Session dazu, den Kontext zu identifizieren. Die Regel in Zeile 8 löscht den Kontext wieder, wenn eine SSH-Session geschlossen wird. Abbildung 2 zeigt die Ausgabe der Regeln im Praxiseinsatz.

Abbildung 2: Mit drei Logsurfer-Regeln lassen sich missglückte Anmeldeversuche am SSH-Port überwachen.

Wer den »tail« -Modus benutzt, darf nicht vergessen das Signal »SIGHUP« an den Logsurfer-Prozess zu schicken, wenn Logrotate oder ähnliche Tools das Logfile neu anlegen.

Leider gibt es Logsurfer nur als Sourcepaket, es existieren keine fertigen Binärpakete in den gängigen Linux-Distributionen. Das Kompilieren und Installieren sollte aber dem durchschnittlich erfahrenen Administrator leicht von der Hand gegen. Für Debian-basierte Distributionen stellt der Autor dieses Artikels unter [4] fertige Pakete bereit.

Sicherheit nicht vergessen

Bei allen Tools für die Loganalyse darf der Admin nicht vergessen, dass nicht nur das System und seine Dienste Logmeldungen erzeugen, denn auch externe Benutzer tun das mit ihren Aktionen. Ein Angreifer könnte beispielsweise das Postfach des Administrators zum Überlaufen bringen, im schlimmsten Fall aber auch mit geeigneten Ausdrücken Systeme außer Gefecht setzen oder beliebige Kommandos ausführen.

Das trifft insbesondere auf Tools wie Logsurfer zu, die das Systemprotokoll in Echtzeit analysieren und beliebige Skripte oder Programme ausführen können. Werden Teile der Logzeile einem externen Programm als Parameter oder via Standardeingabe übergeben – wie im ersten Beispiel –, erhielte ein Angreifer die Chance, das Programm zu manipulieren. Der Anwender solcher Tools muss also die Übergabeparameter und die Standardeingabe entsprechend absichern. Weitere Informationen zum Thema Sicherheit enthält die Manpage von »logsurfer.conf« , die auch online unter [5] zu finden ist.

Simpel oder raffiniert

Wie die vorgestellten Beispiele zeigen, können sich Systemadministratoren eine Menge Arbeit sparen, indem sie Logfiles automatisch auswerten und gegebenenfalls Aktionen anstoßen.

Neben den hier im Artikel beschriebenen Tools existiert noch andere nützliche Software, die automatisierte Reaktionen auf bestimmte Events einleiten kann. In den Tests der Autoren hat sich Logsurfer allerdings als das flexibelste Programm mit den meisten Möglichkeiten herausgestellt. Die Syntax wirkt zwar auf den ersten Blick ziemlich kompliziert, sie erlaubt es aber, auch komplexe Szenarien abzubilden. Wie immer gilt: Wer sich umfassend informiert und offen für bisher unbekannte Ideen ist, kann langfristig viel monotone Arbeit bei der Systembetreuung sparen.