Logwatch der Loganalysierer: Ein Beispiel mit Lighttpd

Zum Thema Monitoring, Serverüberwachung und Intrusion Detection System (IDS) habe ich mir in den letzten Wochen ein paar Gedanken gemacht und neue Software ausprobiert. Ich habe das Thema noch nicht abgeschlossen und teste von Zeit zu Zeit noch das ein oder andere Programm an, was mir bei dieser Aufgabe für meinen Server helfen könnte. Heute stelle ich Logwatch näher vor.

Zur Zeit benutze ich Monit zur Überwachung von Prozessen wie Lighttpd oder den Spieleservern. Es kam in der Vergangenheit bei OpenArena z.B vor, dass der Server wegen eines unbekannten Fehlers unregelmäßig gecrasht ist. Dank Monit wird der Server automatisch neugestartet.
Für den langfristigen Trendverlauf bei Systemressourcen oder Benutzung der Spieleserver verwende ich Munin, womit die Werte grafisch anschaulich aufbereitet werden.
Die Mehrzahl der Daten wird natürlich in Logdateien gespeichert. Da die Menge an Informationen manuell nicht in annehmbarer Zeit zu überprüfen ist, braucht es einen Loganalysierer, der die Daten für Menschen lesbar aufbereitet und im Idealfall nur die "wichtigen" Informationen herausfiltert.
Ein bekannter Loganalysierer heißt Logwatch, den ich am längsten kenne und seit Anfang an für den Server benutze. Speziell für Berichte über die Vorgänge mit der Firewall gibt es aber auch noch FwLogwatch. Ebenfalls angeschaut habe ich mir Logcheck, Swatch und Tenshi. Snort steht auf jeden Fall noch auf der Todo-Liste und mit Tiger als Auditor habe ich auch schon gute Erfahrungen gemacht.

Logwatch

aptitude install logwatch

Ein großer Pluspunkt von Logwatch ist, dass es direkt nach der Installation einfach funktioniert und täglich eine Zusammenfassung als Textmail an Root und die externe Adresse schickt, sofern man zuvor einen Mailserver eingerichtet hat.
Logwatch ist in der Standardeinstellung auf einen niedrigen Detaillevel eingestellt. Die Werte reichen von 0 (low) über 5 (medium) bis 10 (high). Grundsätzlich werden die Logs der letzten 24 Stunden analysiert, wozu der Cronjob in /etc/cron.daily/00logwatch aufgerufen wird. Diese Zeitsteuerung lässt sich wie schon beschrieben über das Verschieben von 00logwatch in den entsprechenden Cron-Ordner oder durch die Bearbeitung der Crontabs ändern.
Die Reichweite der Loganalyse kann auch per Option direkt an Logwatch übergeben werden. Weitere Hinweise dazu finden sich mit logwatch --range Help.

Konfigurationsbeispiel mit Lighttpd

Für einen tiefergehenden Einblick in die Materie empfehle ich einen Blick in Howto-Customize-Logwatch.gz und Readme.Debian in /usr/share/doc/logwatch/ zu werfen. Das Konzept der Konfiguration ist dort ausführlich beschrieben.
Prinzipiell finden sich in den Unterverzeichnissen logfiles und services in /usr/share/logwatch/default.conf die Regeln, welche Logdateien analysiert werden sollen und Parameter, die den Output näher bestimmen. Die tatsächliche Arbeit verrichten aber die Skripte in /usr/share/logwatch/scripts.
Die zentrale Konfigurationsdatei ist logwatch.conf und befindet sich zusammen mit ignore.conf in /usr/share/logwatch/default.conf. Schon rein aus formalen Gründen habe ich aber alle Dateien dort unangetastet gelassen, da Debian selbst die Werte im Verzeichnis /usr/share/logwatch/dist.conf/ überschreibt und jede individuelle Einstellungen wie gewohnt in /etc/logwatch/ festgelegt wird.
Die Unterverzeichnisse in /etc/logwatch/ spiegeln die Verzeichnisstruktur in /usr/share/logwatch wider. Man muss also nur die modifizierten Dateien für Logfiles und Services dort ablegen.
In meinem Fall habe ich den Service http angepasst, der standardmäßig auf die Analyse von Apache ausgerichtet ist. Mit wenigen Handgriffen funktioniert er aber auch für Lighttpd.

Kopieren

/usr/share/logwatch/default.conf/logfiles/http.conf --> /etc/logwatch/conf/logfiles/
/usr/share/logwatch/default.conf/services/http.conf --> /etc/logwatch/conf/services/

Anpassen

Meine http.conf für logfiles.
Meine http.conf für services.
Die Logdateien für meinen Lighttpd-Webserver liegen immer in /var/log/lighttpd/linuxiuvat.de/. Mit

LogFile = lighttpd/linuxiuvat.de/*access.log.1

wird der relative Pfad zu /var/log und meinen Logdateien festgelegt, wobei es noch drei weitere Zeilen in dieser Form gibt, die auf die anderen Logdateien verweisen.
Die zweite http.conf Datei ist der sogenannte Filter oder Service, der auf die Logdateien angewendet wird. Ich habe den Titel auf "Lighttpd" gesetzt und den Detaillevel auf 10 erhöht. Dadurch wird der Standard von 0 überschrieben und die Ausgabe von Lighttpd deutlich "lauter". Der Rest beschränkt sich darauf Parameter auszukommentieren, die nützlich sein können, z.B.

$HTTP_USER_DISPLAY = "$field{http_rc} >= 400"

womit alle HTTP-Fehlermeldungen >= 400 angezeigt werden.

override.conf

In /etc/logwatch/conf kann man die Datei override.conf anlegen, womit sich die globalen Einstellungen aus logwatch.conf überschreiben lassen. Ich brauchte z.B. nicht den Output des Service Iptables.

logwatch: Service = "-iptables"

Mit dem Schlüsselbegriff logwatch: wird die Veränderung eingeleitet, danach folgt der Name der Variable und der Wert. Weitere Ideen, was sich manipulieren lässt, finden sich in logwatch.conf.

Fazit

Das Kopieren und Editieren der Konfiguration ist bei Logwatch erst einmal Gewöhnungssache. Der Vorteil liegt darin, dass die Originaldateien unangetastet bleiben und man alles ordentlich dort hat, wo es hingehört, in /etc. Wer viele Veränderungen vornehmen muss und diese auf mehrere Server anwendet, sollte besser über eine Neukompilierung des Pakets nachdenken.
Mir gefällt Logwatch sehr gut, da es bisher die anderen Methoden gut ergänzt. Logwatch ist ein Teil der Lösung aber eben nicht alles. Für mich ist eine tägliche E-Mail-Benachrichtigung ausreichend. Außerdem ist die Standardkonfiguration sehr gut. Wer noch mehr Kontrolle und andere Voreinstellungen bevorzugt, sollte sich Logcheck anschauen. Dort wird man anfangs sogar stündlich informiert und kann durch Reguläre Ausdrücke festlegen, was man sehen möchte oder eben nicht.

5 Replies to “Logwatch der Loganalysierer: Ein Beispiel mit Lighttpd”

  1. Wenn du dich für host basiertes intrusion detection interessierst kann ich dir ossec empfehlen. läuft bei mir einwandfrei zusammen mit logwatch auf allen servern.

  2. Danke für deinen Tipp. Ich versuche mich gerade etwas in die Materie einzuarbeiten. Ossec sieht auf den ersten Blick sehr vielversprechend aus. Schade, dass es (noch) kein Debian-Paket gibt. Naja der ITP läuft seit 6 Jahren, aber für Wheezy wird das nicht mehr reichen. Da bleibt die Frage, welche Distribution benutzt du oder hast du dir ein eigenes Paket gebaut? 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.