© bonzami emmanuelle, 123RF

Wer Logdateien überwachen möchte, könnte zu einem dicken Hund wie Nagios oder Icinga greifen. Doch auch leichtgewichtige Alternativen wittern Bedrohungen, lassen sich aber wesentlich flotter einrichten. Das Linux-Magazin geht mit fünf dieser kleinen Wachhunde auf den Trainingsparcours.

Die Logfiles eines Systems protokollieren nicht nur fehlgeschlagene Anmeldeversuche der Nutzer, sondern auch Programmfehler und Hinweise auf Angriffe. Administratoren sollten sie daher kontinuierlich im Blick behalten. Dabei helfen ihnen Tools wie Logalyze [1], Logcheck [2], Logwatch [3], Multitail [4] und Swatch [5].

Anders als große Monitoring-Lösungen wie Nagios und Incinga konzentrieren sie sich auf die Analyse von Logdateien. Dafür verbrauchen sie weniger Ressourcen und sind deutlich schneller einzurichten. Sie eignen sich daher ideal für den Einsatz auf schwachbrüstiger Hardware und Embedded-Geräten wie dem Raspberry Pi sowie auf Servern mit wenigen ausgewählten Diensten.

Alle Kandidaten greifen sich eine oder mehrere Logdateien und filtern nach vorgegebenen Regeln wichtige Meldungen heraus. Das Ergebnis schicken sie wahlweise per E-Mail an den Administrator oder geben es an der Kommandozeile aus. Die Filterregeln dürfen Admins um eigene ergänzen, meist in Form regulärer Ausdrücke. Mitunter liefern die Entwickler einen Satz oft benötigter Regeln mit. Besonders leistungsfähige Tools stellen zudem einen Report über den Zustand des Systems zusammen und weisen auf Sicherheitsprobleme hin. Dass diese Funktionen jedoch nicht selbstverständlich sind, zeigt ein Vergleich der oben genannten Kandidaten.

Logalyze

Von dem ungarischen Unternehmen Zuriel Ltd. stammt Logalyze [1]. Das ehemals proprietäre Tool steht zwar mittlerweile unter der GPLv2, den Quellcode halten die Entwickler jedoch noch unter Verschluss. Die letzte Version 4.1.4 erschien erst im Dezember 2016, sie behebt aber nur kleinere Fehler aus der fast vier Jahre alten Vorversion. Logalyze setzt daher noch immer auf Oracles Java Runtime Environment in der vollkommen veralteten Version 1.6.

Die Installation beschreibt eine kurze und knappe Anleitung im PDF-Format. Administratoren konfigurieren Logalyze über eine mitgelieferte Webanwendung, die einen der Application-Server Apache Tomcat, Jetty, Glassfish oder Jboss voraussetzt. Dem Installationspaket liegt das hoffnungslos veraltete Tomcat 6.0.35 aus dem Jahr 2011 bei, das sich immerhin über ein vorbereitetes Skript schnell hochfahren lässt.

In der Benutzeroberfläche legt der Administrator zunächst einen oder mehrere so genannte Collectors an. Diese holen die Logdaten über das Netzwerk oder aus einer Datei. Jeden Collector schaltet der Admin individuell zu- oder ab. Aus den eingelesenen Daten erzeugt Logalyze dann Statistiken und Reports und fasst so beispielsweise alle kritischen Fehler in einem übersichtlichen Bericht zusammen (Abbildung 1).

Abbildung 1: Logalyze zeigt Statistiken direkt in der Weboberfläche als Torten-, Balken- oder Liniendiagramm an. Hier ist deutlich zu erkennen, dass die Anzahl der Ereignisse in der letzten Zeit zurückging.

Admins dürfen dabei eigene Statistiken und Reports erstellen, indem sie in der Benutzeroberfläche entsprechende Kriterien zusammenklicken. Auf dieser Basis generiert Logalyze dann wahlweise eine PDF- oder CSV-Datei. Die wiederum lädt der Administrator herunter oder lässt sie sich per E-Mail zuschicken.

Ergänzend darf er in den Logfiles gezielt nach Begriffen suchen. Reguläre Ausdrücke erlaubt Logalyze dabei zwar nicht, mehrere Suchbegriffe verknüpft es dabei aber über Operatoren wie AND und OR. Es hinterlegt häufig benötigte Suchanfragen, um sie später schnell per Mausklick abzurufen (Abbildung 2). Logalyze bringt bereits einige vordefinierte Suchanfragen mit, die unter anderem schnell alle Fehler aus dem Syslog auflisten.

Abbildung 2: Logalyze hat drei Ereignisse für den Rechner »ubuntu« gefunden.

Logcheck

Das Debian-Projekt pflegt derzeit das unter der GPLv2 stehende Logcheck [2]. Es untersucht Logfiles selbstständig auf Probleme, Sicherheitslücken und mögliche Einbruchsversuche. Nach seinem Start greift sich Logcheck standardmäßig das Syslog und das »auth.log«. Administratoren setzen das Tool wahlweise aber auch auf beliebige andere Logfiles an.

Alle seit der letzten Prüfung neu hinzugekommenen Einträge vergleicht Logcheck mit einem Batzen vorgegebener Filterregeln. Abhängig vom Ergebnis geht das Tool entweder direkt zum nächsten Eintrag über oder klassifiziert ihn als wichtiges Systemereignis, Sicherheitsproblem oder Warnung. Alle Ereignisse der letzten drei Kategorien verschickt Logcheck dann in einer E-Mail an den Administrator oder schreibt sie in die Standardausgabe (Abbildung 3).

Abbildung 3: Ubuntu-Anwender starten Logcheck mit Hilfe des Users »logcheck«. Der Parameter »-o« gibt die Ereignisse im Terminal aus. Die Ausgaben können wie hier ziemlich unübersichtlich sein.

Damit die Übersicht nicht verloren geht, dürfen Administratoren zwischen drei Filterstufen wählen: Die höchste namens »Paranoid« ist für besonders sicherheitsrelevante Systeme mit wenigen, ausgewählten Diensten gedacht. In ihr liefert Logcheck besonders viele ausführliche Meldungen, die es in den anderen Stufen verwerfen würde. Voreingestellt ist die Stufe »Server«, die wenigsten Meldungen gibt es in der Stufe »Workstation«. Warnungen vor Sicherheitsproblemen und Angriffen verschickt Logcheck in jeder Filterstufe. Damit das Tool jedes Systemereignis nur einmal meldet, merkt es sich mit Hilfe des Perl-Skripts Logtail die jeweils letzte Position in den zu untersuchenden Logdateien.

Alle Filterregeln liegen als reguläre Ausdrücke vor, die Administratoren nach Belieben um eigene ergänzen (Abbildung 4). Zur besseren Übersicht wandern alle Ausdrücke für einen Dienst, wie etwa den Apache Webserver, in eine eigene Konfigurationsdatei. Logcheck liest bei seinem Start automatisch sämtliche Konfigurationsdateien ein. Netterweise liefern die Entwickler bereits ein Paket mit mehreren solcher Konfigurationsdateien mit. Die in dieser so genannten Logcheck-Database enthaltenen Regeln decken jedoch lediglich ein paar grundlegende Fehler und besonders wichtige Angriffsmuster ab.

Abbildung 4: Logcheck verwirft in der Filterstufe »Server« unter anderem alle Ereignisse, die diesen regulären Ausdrücken in der Datei »/etc/logcheck/ignore.d.server/sudo« entsprechen.

Die meisten Distributionen halten Logcheck in ihren Repositories vor. Auf Debian-Systemen stößt ein Cronjob Logcheck jede Stunde an, darüber hinaus aktiviert sich das aufmerksame Werkzeug automatisch bei jedem Systemstart. Den Versand der E-Mails übernimmt ein beliebiges passendes Kommandozeilen-Programm, standardmäßig bekommt Sendmail den Auftrag erteilt.

Logwatch

Wie Logcheck wartet auch Logwatch [3] in den Repositories der meisten großen Distributionen auf seine Installation. Das Tool steht unter der MIT-Lizenz und setzt Perl 5.8 voraus. Sobald Logwatch startet, greift es sich alle ihm bekannten Logs und prüft darin sämtliche Ereignisse aus den letzten 24 Stunden. Diesen Betrachtungszeitraum erweitert oder verkürzt der Administrator nach eigenem Gutdünken.

Anders als der Konkurrent Logcheck erzeugt Logwatch aus den gelesenen Ereignissen eine übersichtliche Zusammenfassung (Abbildungen 5 und 6). Den auf dem System laufenden Diensten widmet sich dabei jeweils ein eigener Abschnitt, die dort angezeigten Informationen richten sich nach dem jeweiligen Dienst. Für den Paketmanager Dpgk listet Logwatch beispielsweise alle in den letzten 24 Stunden installierten Pakete auf. War Logwatch nicht in der Lage, ein Ereignis sinnstiftend zu interpretieren, hängt das Tool dieses Ereignis einfach als Attachement an den Bericht an.

Abbildung 5: Logwatch erzeugt die Zusammenfassung wahlweise in Textform …

Der Administrator teilt Logwatch über zahlreiche Konfigurationsdateien mit, welche Dienste auf dem System laufen und in welchen Logdateien sie gewöhnlich ihre Informationen ablegen. Die Konfigurationsdateien wiederum verteilen sich auf mehrere Unterverzeichnisse. Für viele wichtige und bekannte Systemdienste bringt Logwatch bereits fertige Konfigurationsdateien mit, einige Distributoren ergänzen diese noch um weitere Services. Dank dieser Vorgaben durchkämmt Logwatch direkt nach der Installation weitaus mehr Logfiles als Konkurrent Logcheck.

Die Logdateien eines Dienstes wertet ein darauf spezialisiertes Perl-Skript aus. So verarbeitet beispielsweise das Skript »/usr/share/logwatch/scripts/services/dpkg« die Logdateien des Paketmanagers Dpkg. Soll Logwatch für den Administrator einen individuell aufgesetzten Dienst analysieren, muss dieser in der Lage sein, ein Auswertungsskript in Perl zu verfassen. Dabei hilft ein ausführliches Howto, das Logwatch beiliegt.

Die Analyse-Skripte lesen die Ereignisse aus den Logdateien ein, erzeugen eine Zusammenfassung und übergeben diese an Logwatch. Die eingesammelten Ergebnisse verschickt das Tool schließlich in einer E-Mail, schreibt sie in eine Datei oder liefert sie über Stdout aus. Zuvor präsentiert Logwatch alle Informationen auf Wunsch auf einer simpel gestrickten HTML-Seite (Abbildung 6). Der fertige Report enthält auch einige Systeminformationen, zum Beispiel den noch freien Speicherplatz.

Abbildung 6: … oder als HTML-Datei mit ziemlich kleiner Schrift.

Die Administratoren geben auch vor, wie ausführlich Logwatch berichten soll. Insgesamt stehen zehn Detailstufen bereit. Die einzelnen Auswertungsskripte entscheiden dabei, welche (zusätzlichen) Informationen jeder Detailgrad produziert. In der Regel starten die Distributionen Logwatch via Cronjob einmal in der Nacht und verschicken den dabei erzeugten Report via E-Mail. Den eigentlichen Versand delegiert das Tool an Sendmail oder ein anderes, frei wählbares Kommandozeilen-Programm.

Multitail

Eigentlich präsentiert Multitail [4] die Enden gleich mehrerer Textdateien in nur einem (Terminal-)Fenster (Abbildung 7). Im Laufe der Zeit kamen weitere Features dazu, insbesondere Filter- und Überwachungsfunktionen für Logfiles.

Abbildung 7: Die Anordnung der Logdateien bestimmt der Administrator in Multitail selbst. Hier stellt er zwei Logdateien übereinander dar.

So filtert der Admin die Informationsflut über reguläre Ausdrücke. Trifft ein regulärer Ausdruck zu, startet Multitail auf Wunsch ein externes Programm. So lassen sich auch E-Mail-Benachrichtigungen verschicken. Alternativ arbeitet Multitail wie eine visuelle Pipe, indem es die gefilterten Informationen in Dateien schreibt oder an andere Prozesse weiterleitet. Multitail kann sogar selbst als Syslog-Server auftreten und nimmt auf Wunsch Ausgaben von anderen Programmen entgegen – wie etwa »netstat«.

Ergänzend hebt das Tool die betroffene Zeile hervor und macht über Piepser auf sich aufmerksam. Einzelne Events markiert ein Admin über reguläre Ausdrücke gezielt farblich. So hebt er etwa alle mit »Error« beginnenden Zeilen rot hervor. Multitail konvertiert zudem Eingaben automatisch. Es übersetzt IP-Adressen in die passenden Domainnamen, wandelt Signal-Nummern in -Namen um und liefert jedes Datum im lokalen Format.

Allerdings müssen Administratoren Multitail vollständig selbst einrichten. Im Gegensatz zu Logcheck oder Logwatch bringt das Tool keine vorgefertigten regulären Ausdrücke mit. Auch das Weiterleiten und Versenden einer E-Mail konfigurieren Admins per Hand. Multitail liegt allen großen Distributionen bei und untersteht der GPLv2. Das Tool kommt zudem mit einer ausführlichen Anleitung im HTML-Format.

Swatchdog

Der Simple Log Watcher, kurz Swatch [5], begann als kleines Watchdog-Tool, das ein Syslog auf Aktivitäten überwachte. Mittlerweile verdaut das unter der GPLv2 stehende Programm beliebige Logdateien. Um Problemen mit einem bekannten Schweizer Uhrenhersteller auszuweichen, heißt das Kommandozeilentool formal Swatchdog. In den meisten Distributionen steckt es jedoch weiterhin im Paket »swatch«. Die mitgelieferte Manpage stellt gleichzeitig auch die einzige Dokumentation dar.

Das Tool selbst besteht aus einem kleinen Perl-Skript, das sich die ihm per Parameter genannten Logfiles vorknöpft (Abbildung 8). Swatchdog geht in ihnen wahlweise alle enthaltenen Zeilen durch oder aber überwacht die Datei kontinuierlich. Im letzteren Fall lässt sich Swatchdog als Daemon starten und somit in den Hintergrund schieben. Auf Wunsch nimmt das Tool auch Logdaten über eine Pipe entgegen.

Abbildung 8: Swatchdog prüft hier aufgrund des Parameters »–examine« einmal die komplette Datei »/var/logs/auth.log«.

In jedem Fall gibt der Administrator in einer Konfigurationsdatei vor, bei welchen Ereignissen das Tool welche Aktionen ausführen soll. Diese Konfigurationsdatei nutzt eine Swatchdog-eigene Syntax, für die Listing 1 ein einfaches Beispiel zeigt. Den dortigen Anweisungen zufolge soll Swatchdog nach den Stichwörtern »warning« und »error« fahnden. Bei der Angabe des Suchmusters darf der Administrator einen regulären Ausdruck verwenden.

01 watchfor /warning|error/
02         echo
03         mail addresses=tim\@example.com, subject=Fehler aufgetreten

Dann führt Swatchdog alle Aktionen aus, die eingerückt folgen. So gibt »echo« die passende Zeile aus dem Logfile auf der Konsole aus, während »mail« die Meldung per E-Mail mit dem Betreff »Fehler aufgetreten« an »tim@example.com« schickt. Swatchdog ruft zudem beliebige Programme auf (»exec«) und leitet das betroffene Ereignis via Pipe weiter (»pipe Befehl«). Perl-Kenner dürfen Perl-Code hinterlegen, den das Tool ausführt.

Swatchdog starten Nutzer standardmäßig auf der Kommandozeile. Einen passenden Cronjob oder Systemd-Units müssen Administratoren selbst anlegen. Anders als bei Logwatch bringt Swatchdog keine Beispielkonfiguration mit. Nutzer sollten folglich zunächst etwas Zeit einplanen, um eine passende Konfigurationsdatei zu schreiben.

Auf den Hund gekommen

Die Wahl des passenden Tools hängt stark von den konkreten Anforderungen und den eigenen Programmierkenntnissen ab. Alle fünf Kandidaten ersetzen zudem kein ausgewachsenes Monitoring-, geschweige denn Intrusion-Detection-System. In jedem Fall muss der Administrator die verschickten Systemereignisse selbst interpretieren.

Logalyze bietet ein GUI und lässt sich zudem aus der Ferne mit dem Browser bedienen. Wer das Tool einsetzen möchte, sollte jedoch dessen hohes Alter bedenken, zudem gehört die mitgelieferte Tomcat-Fassung schleunigst ersetzt. Wie sie Logalyze bedienen, müssen Admins zudem selbst herausfinden.

Alte Kameraden

Wer im Internet nach weiteren Alternativen zu den vorgestellten Tools sucht, stolpert dabei automatisch über ein paar inzwischen veraltete Vertreter. Das Tool Logdigest [6] arbeitet wie Logcheck, liegt aber schon seit 2009 auf Eis. Der Logsurfer [7] ähnelt Swatchdog ziemlich stark, kann aber zusätzlich ähnliche Ereignisse gruppieren. Darüber hinaus ist Logsurfer in C geschrieben und sollte daher deutlich flotter zu Werke gehen. Die letzte Version des Tools erschien allerdings im September 2011.

Ungefähr genauso alt ist Petit [8], das allerdings noch immer in den Repositories von Ubuntu steckt. Das Tool nutzt Sprachanalysemethoden, um die Datenflut vor allem in Systemlogs zu bändigen. So lassen sich Administratoren beispielsweise alle Wörter auflisten, die in einer Logdatei besonders häufig vorkommen. Darüber hinaus zeichnet das Tool ein Diagramm, das die Anzahl der Meldungen in einem vorgegebenen Zeitraum präsentiert (Abbildung 9). Interessant ist auch die Hashfunktion, die ähnliche Nachrichten im Log zählt. Auf diese Weise sieht der Betrachter sofort, welche Fehler besonders häufig auftreten.

Abbildung 9: Wie dieses von Petit erzeugte Diagramm zeigt, sind in den ersten fünf Minuten der Logaufzeichnung besonders viele Ereignisse eingegangen.

Logcheck lässt sich besonders schnell in Betrieb nehmen. Wer reguläre Ausdrücke beherrscht, reduziert mit flott hinzugefügten und maßgeschneiderten Filterregeln die Datenflut. Während Logcheck nur die nackten Ereignisse an den Admin sendet, liefert ihm Logwatch eine Zusammenfassung. Will er eigene Dienste mit Logwatch überwachen, braucht er aber Perl-Skripte.

Multitail empfiehlt sich vor allem Administratoren, die sprichwörtlich mehrere Logfiles im Auge behalten und nur in bestimmten Fällen Aktionen auslösen wollen. Der Versand von E-Mails und das Weiterleiten von gefilterten Ereignissen ist zwar möglich, der Admin muss dazu jedoch passende reguläre Ausdrücke schreiben und Multitail per Hand konfigurieren. Das Tool bietet sich damit auch als sehr gute Ergänzung zu Logcheck und Logwatch an.

Swatchdog lässt sich schließlich mit Logwatch vergleichen: Es ist schnell eingerichtet, setzt aber Wissen um reguläre Ausdrücke voraus. Darüber hinaus meldet es nur einzelne, vom Administrator vorgegebene Ereignisse.