9.4 Logging 

Wichtige Systeminfos

Ein weiteres interessantes Thema der Systemverwaltung ist das Logging. Vor allem bei Problemen kann man in den sogenannten Logfiles häufig die Ursache oder sogar Ansatzpunkte zur Lösung des Problems in Form einer Fehler- oder Statusmeldung eines Dienstes oder des Systems finden.

9.4.1 Die Logdateien 

Der wichtigste Aspekt beim Logging ist zweifelsohne der der Logdateien. In Logdateien werden je nach Konfiguration schwere Fehler, wichtige Vorgänge oder unter Umständen sogar unwichtige Informationen verzeichnet. Dabei haben viele Softwarepakete eigene Logdateien, die jedoch im Allgemeinen immer unter /var/log oder diversen Unterverzeichnissen zu finden sind.

/var/log/messages

Die wichtigste Logdatei eines Systems ist die /var/log/messages. Sie enthält so ziemlich alles, was der Kernel und die wichtigsten Systemprozesse mitzuteilen haben.

So schreibt der Kernel eigene Meldungen in diese Datei, aber auch Anwendungen ohne eigene Logdateien haben die Möglichkeit, Nachrichten in diese Datei zu schreiben. Aber sehen wir uns einfach mal einen Auszug an:

… 
Oct 12 11:44:44 localhost kernel: eth0: no IPv6 
  routers present 
… 
Oct 12 14:59:00 localhost /USR/SBIN/CRON[2011]: 
  CMD ( rm -f /var/spool/cron/lastrun/cron.hourly) 
Okt 12 15:29:09 localhost su: FAILED SU (to root) 
  jploetner on /dev/pts/4 
Okt 12 15:29:16 localhost su: (to root) jploetner 
  on /dev/pts/4 
Okt 12 15:29:16 localhost su: pam_unix2: session 
  started for user root, service su 
Okt 12 15:31:42 localhost su: pam_unix2: session 
  finished for user root, service su

Listing 9.44    Auszug aus /var/log/messages

Hier wird auch schon der generelle Aufbau deutlich, den Logdateien oft haben: Es werden das Datum und die genaue Uhrzeit vor der eigentlichen Nachricht angegeben.

Im Fall der /var/log/messages kommt nach der Zeit der Name des Rechners, der die Meldung verursachte, dann der Name des aufrufenden Programms, gefolgt von der eigentlichen Meldung.

In unserem Fall beinhaltet die Datei ausschließlich Meldungen eines einzigen Computers, der im Logfile als localhost <Der Name localhost bezeichnet immer den aktuellen, eigenen Rechner.> identifiziert wird. In unserem Beispiel finden wir Meldungen von den Programmen cron, su und dem Kernel.

Ein fehlgeschlagenes Login

An der Ausgabe können wir zum Beispiel erkennen, dass der Benutzer jploetner einmal vergeblich versucht hat, sich per su-Kommando die root-Identität zu verschaffen, um als Systemadministrator Aufgaben zu übernehmen. Ein paar Sekunden später hat er es aber dann doch geschafft und war für ein paar Minuten in einer Session als root aktiv.

Aus den Meldungen des Kernels wurde eine beliebige herausgegriffen, in diesem Fall eine Meldung vom Bootvorgang, die beim Initialisieren der Netzwerkschnittstellen auftrat.

Eine typische Information ist der Eintrag des cron-Programms, das ein Dienst ist, um regelmäßig Programme, beispielsweise zu Administrationszwecken, auszuführen. So eine Logdatei ist ein komfortabler Weg, eine Rückmeldung über die gestarteten Programme zu bekommen – in diesem Fall wurde einfach nur eine Statusdatei mit dem Kommando rm gelöscht, um nicht mit unnützen Daten die Festplatte zu verstopfen.

/var/log/wtmp

Die letzten Logins

Die wtmp-Datei enthält Informationen über die letzten Logins bzw. Login-Versuche für jeden einzelnen Nutzer. Leider ist die Datei in keinem für Menschen lesbaren (Text-)Format gespeichert, daher kann man diese Informationen nur über das lastlog-Programm anzeigen lassen:

$ lastlog 
Username  Port   From         Latest 
root      tty2               Don Sep 18 16:35:01 2005 
bin                           **Never logged in** 
… 
jploetner :0     console     Son Okt 16 11:46:30 2005 
swendzel  pts/5  jupiter.wg  Son Okt 16 20:05:22 2005 
…

Listing 9.45    Die letzten Logins mit lastlog

Beim einfachen Aufruf von lastlog werden also alle Benutzer mit den entsprechenden Daten ausgegeben. Zu diesen Daten gehört natürlich auf der einen Seite der Zeitpunkt, auf der anderen Seite beispielsweise aber auch der Ort, von dem aus sich der entsprechende Benutzer eingeloggt hat. Das kann eine lokale Konsole, wie beispielsweise tty2, oder auch ein fremder Rechner (jupiter.wg) sein, der eine virtuelle Konsole (pts/5) zum Einloggen nutzt.

Alle aktuell eingeloggten User

Eng im Zusammenhang mit diesem Logfile steht nun die /var/run/utmp. <Auf einigen Systemen ist die utmp auch unter /var/log gespeichert. Da diese Datei jedoch Laufzeitparameter speichert, ist sie unter /var/run besser aufgehoben.> Diese Datei speichert nämlich Informationen über die momentan eingeloggten Benutzer.

Da auch diese Datei in einem unlesbaren Format geschrieben ist, kann man zum Beispiel das Programm w nutzen, um die entsprechenden Informationen auszulesen:

# w 
13:40:18 up 1:12, 2 users, load average: 0.34,0.4,0.51 
USER     TTY   FROM       LOGIN@ IDLE  JCPU  PCPU WHAT 
jploetne :0    –          12:29  ?xdm?  5:24 0.00s -:0 
root     pts/3 jupiter.wg 13:40  0.00s 0.00s 0.00s w

Listing 9.46    Alle eingeloggten User mit w

Hier sind also gerade zwei Benutzer – »root« und »jploetner« – eingeloggt. Dabei ist jploetner lokal auf der grafischen Oberfläche (»:0«, siehe Kapitel 19, »X11-Programme«) eingeloggt, während root von einem anderen Rechner (»jupiter.wg«) aus eine virtuelle Konsole benutzt.

/var/log/Xorg.log

Ein typisches Beispiel für eine anwendungsspezifische Logdatei ist die /var/log/Xorg.log. Bei dieser Datei handelt es sich um eine Logdatei der grafischen Oberfläche X11. Sie enthält zahlreiche Informationen zum Start des sogenannten X-Servers. Vor allem bei unerklärlichen Abstürzen findet man hier häufig einen Anhaltspunkt zur Lösung des Problems.

9.4.2 Der syslogd 

Zentrale Anlaufstelle

Als Nächstes wollen wir uns ansehen, wie die Nachrichten in die Logfiles kommen. Bei einer anwendungsspezifischen Datei wie der Xorg.log ist der Fall klar: Die Anwendung öffnet die Datei und schreibt die Nachrichten einfach hinein. Im schlimmsten Fall muss die Anwendung beim Logging mehrere Instanzen verkraften können, falls mehrere User dieses Programm gleichzeitig nutzen.

Für eine zentrale Logdatei wie die /var/log/messages ist so eine Vorgehensweise jedoch nicht praktikabel.

Schließlich könnte es sowohl zu Synchronisations- als auch zu Sicherheitsproblemen kommen. Vermischte oder von »bösen«

Programmen gelöschte Meldungen wären möglich. Um solche Schwierigkeiten auszuschließen, braucht man eine zentrale Instanz zur Verwaltung der Logdateien. Unter Linux ist eine solche Instanz durch den syslogd realisiert.

Zugriff auf den syslogd

Um nun eine Nachricht in die Systemlogfiles zu schreiben, muss ein Programmierer eine entsprechende Bibliotheksfunktion nutzen. Diese Funktion heißt »syslog()« und nimmt als Argumente zum einen einen Integerwert sowie den einzutragenden Text entgegen, der ähnlich wie bei »printf()« formatiert werden kann. Wie das Ganze nun aussehen kann, zeigt dieser Beispielcode:

#include <syslog.h> 
 
int main() 
{ 
  syslog( LOG_USER | LOG_INFO, "Nachricht\n" ); 
  return 0; 
}

Listing 9.47    Ein syslog()-Testcode

Hier wird der Text »Nachricht« an den syslogd übergeben, damit er diesen in die Logfiles schreibt. Dabei spezifiziert das erste Integer-Argument von syslog() offensichtlich die Priorität – den Loglevel – sowie die Herkunft der Nachricht und wird aus der »Oder«-Verknüpfung der Konstanten LOG_INFO und LOG_USER gebildet. Diese letzte Konstante – die Facility – zeigt im Beispiel an, dass die Nachricht von einem normalen Benutzerprogramm kommt. Sie kann jedoch unter anderem auch die folgenden Werte annehmen:

• LOG_AUTHPRIV

• Diese Facility wird bei sicherheitsrelevanten Authentifizierungsnachrichten benutzt. Ein Beispiel dafür wäre das su-Programm, über das sich ja Benutzer eine andere Identität verschaffen können, wofür sie das benötigte Passwort kennen müssen.

• LOG_CRON

• Diese Facility wird von den später noch vorgestellten Diensten cron und at genutzt. Diese Dienste erledigen automatisiert und selbstständig verschiedene Aufgaben im System, wodurch die eine eigene Facility rechtfertigende Bedeutung dieser Dienste gegeben ist.

• LOG_DAEMON

• LOG_DAEMON ist für alle Dienste gedacht, die keine eigene Facility besitzen. Es lässt sich jedoch sehr oft konfigurieren, welche Facility und welchen Loglevel ein bestimmter Dienst haben soll. Für eine bessere Differenzierung beim späteren Filtern nach dieser Facility können in einem solchen Fall auch die Facilities
  
  
• LOG_LOCAL0 bis
  
  
• LOG_LOCAL7
  

• genutzt werden. Diese sind zwar vom Namen her weniger aussagekräftig, bieten aber lokal doch eine gewisse Flexibilität. Vorsicht bei der Bedeutungstreue ist nur geboten, wenn im Netzwerk geloggt wird.

• LOG_FTP

• FTP-Serverdienste können diese Facility nutzen, um ihre Lognachrichten zu speichern.

• LOG_KERN

Logging des Kernels

• Diese Facility wird für Kernel-Nachrichten genutzt; ein normales Benutzerprogramm hat mit dieser Facility nichts zu tun. In den Linux-Implementierungen des Syslog-Dienstes bedient ein eigener Prozess die Requests des Kernels: der klogd. <Daher bezeichnet man das entsprechende Paket auch als sysklogd, um diese Trennung zu betonen und von der traditionellen Implementierung aus der BSD-Welt zu unterscheiden, bei der es diese Trennung so noch nicht gab.> Dieser Dienst wurde aus Konsistenzgründen eingeführt und macht nichts anderes, als die Nachrichten des Kernels an den Syslog weiterzuleiten. Dieser verarbeitet diese Nachrichten dann ganz normal.

• LOG_LPR

• Druckerdienste wie der lpd oder cupsd setzen über diese Facility ihre Nachrichten ab.

• LOG_MAIL

• Entsprechend nutzen Maildienste wie exim, sendmail und postfix diese Logfacility, um Meldungen in den Systemlogfiles zu speichern.

• LOG_NEWS

• Newsserver wie der cdpnntpd nutzen die LOG_NEWS-Facility.

• LOG_SYSLOG

• Diese Facility hingegen wird nur vom Syslogd selbst genutzt und ist nicht für die Nutzung in normalen Benutzerprogrammen oder Systemdiensten bestimmt.

• LOG_USER (default)

• Wird keine Facility weiter angegeben, so ist LOG_USER die Vorgabe des Systems. Diese Facility wird so auch für jedes nicht weiter spezifizierte Programm aus dem Userland genutzt.

Über die Facility kann ein Programm also dem syslogd mitteilen, woher eine Nachricht kommt. Inwieweit der Logging-Dienst diese Information zur Verarbeitung der Nachricht heranzieht, werden wir bei der Konfiguration des Dienstes noch näher erläutern. Im Folgenden soll jedoch erst einmal eine Übersicht über die unterschiedlichen Loglevel beziehungsweise Prioritäten einer Nachricht gegeben werden:

• LOG_EMERG

• Nachrichten dieser Priorität zeigen ein unbenutzbares System an.

• LOG_ALERT

• Bei dieser Gefahrenstufe muss sofort gehandelt werden.

• LOG_CRIT

• Nachrichten dieser Priorität bezeichnen einen kritischen Zustand.

• LOG_ERR

• Mit diesem Wert kann man einfache Fehlernachrichten belegen.

• LOG_WARNING

• Entsprechend bezeichnet LOG_WARNING einfache Warnungen, die also weniger kritisch sind.

• LOG_NOTICE

• Diese Nachricht bezeichnet eine normale, aber immer noch wichtige Nachricht.

• LOG_INFO

• Diese Stufe bezeichnet eine einfache Information ohne größere Wichtigkeit, die durchaus auch ignoriert werden kann.

• LOG_DEBUG

• Debug-Nachrichten sind die am wenigsten relevanten Nachrichten und werden vor allem zum Debugging, also zum Überprüfen frisch geschriebener Software auf eventuelle Fehler genutzt.

Inwieweit diese Informationen nun relevant für die Verarbeitung der Nachrichten vom syslogd sind, wird spätestens bei der Konfiguration des Dienstes klar, die wir im Folgenden besprechen werden. Dazu müssen wir aber noch zwischen zwei Implementierungen differenzieren: dem Syslog und dem Syslog-ng.

syslog-ng

Der Syslog-ng-Dienst ist dabei eine Alternative zum traditionellen Syslog. Der Dienst kann auf fast allen Distributionen nachinstalliert werden. Die Vorteile des Dienstes sind auf jeden Fall eine etwas größere Flexibilität und die bessere I/O-Performance bei vielen Log-Einträgen. Die erhöhte Flexibilität führt aber zu einer komplexeren Konfigurationsdatei.

Daher wollen wir mit der Konfiguration der /etc/syslog.conf die Konfiguration des traditionellen Syslogs erläutern. Mit dem dadurch vermittelten grundlegenden Wissen und der Manpage zum Syslog-ng sollte sich auch dieser einfach an die eigenen Bedürfnisse anpassen lassen.

Die /etc/syslog.conf

Den Syslog konfigurieren

Im Folgenden wollen wir also die Konfiguration des traditionellen, ursprünglich aus der BSD-Welt kommenden Syslogs über die /etc/syslog.conf behandeln. Die ganze Datei ist dabei als eine Ansammlung von unterschiedlichen Regeln zu verstehen, die bestimmen, wie mit Nachrichten aus bestimmten Facilities und Logleveln verfahren werden soll.

Um diese Regel nun zu erklären, werden wir im Folgenden einzelne, typische Beispiele erläutern.

Eine Regel ist dabei wie folgt aufgebaut: Sie steht in einer Zeile, die einen Selektor enthält und eine Aktion definiert. Dabei können über einen Backslash (»\«) auch mehrere Zeilen zu einer Regel zusammengefasst werden.

Ein Selektor besteht aus mehreren Paaren der Form »facility.log- level« und spezifiziert damit die Herkunft einer Nachricht. Eine Aktion ist dann typischerweise die Datei, in die die Nachricht auf geschrieben wird. Möglich ist jedoch auch, die gewählten Nachrichten mit »@« auf einen fremden Rechner, eine lokale Konsole oder direkt auf die Shell eines angemeldeten Users zu schicken. Außerdem kann man die Selektoren noch über Symbole wie »=«, »!=«, »!« oder auch »*« recht flexibel handhaben.

*.=crit;kern.none            /var/log/critical.log

Listing 9.48    Was kommt in /var/log/critical.log?

Diese Regel würde alle Nachrichten des Loglevels »LOG_CRIT« ausgenommen aller Kernel-Messages in der Datei /var/log/critical.log speichern. Dazu wurde im Selektor zuerst für die Facility eine Wildcard (»*«) eingesetzt, der Loglevel mittels »=« jedoch auf »crit« festgelegt. Die Wildcard von eben wird jedoch im nächsten Schritt durch »kern.none« wieder eingeschränkt, da dadurch eben Nachrichten der LOG_KERN-Facility ausgeschlossen werden.

kern.*                       /var/log/kern.log 
kern.crit                    @gateway 
kern.crit                    /dev/console 
kern.info;kern.!err          /var/log/kern-info.log

Listing 9.49    Nachrichten des Kernels

Kernel-Logging

Diese Anweisungen sind schon etwas komplizierter. Die erste Regel gibt an, dass alle Nachrichten der LOG_KERN-Facility in der /var/log/kern.log gesichert werden sollen.

Die zweite Zeile und damit die zweite Regel leitet zusätzlich alle mindestens kritischen Nachrichten dieser Facility zum Rechner gateway. Es ist sinnvoll, zumindest diese kritischen Nachrichten noch extern zu speichern, da im Falle eines Festplattencrashs oder eines entsprechenden Treiberproblems die Meldungen nicht verloren gehen und noch nachvollzogen werden können.

Sollte natürlich der Netzwerk-Stack des Kernels ebenfalls ein Problem haben, wird auch eine Weiterleitung nichts bringen. Daher sollen alle diese Nachrichten ebenfalls auf der Konsole des aktuell eingeloggten Users ausgegeben werden, die durch das Device /dev/console repräsentiert wird.

Schließlich sollen alle Nachrichten der Facilities LOG_INFO, LOG_NOTICE und LOG_WARNING in der /var/log/kern-info.log gespeichert werden. Mit »kern.info« wählt man alle Nachrichten aus, die mindestens den Loglevel LOG_INFO beitzen, und mit »kern.!err« schließen wir alle Meldungen aus, die als LOG_ERR oder wichtiger klassifiziert wurden, sodass die genannten übrig bleiben.

mail.=info                   /dev/tty12

Listing 9.50    Auf die 12. Konsole!

Dieser Ausdruck leitet alle Nachrichten der Facility LOG_MAIL im Level LOG_INFO auf das Device /dev/tty12, die zwölfte Konsole, weiter. So können Nachrichten durch Drücken von Strg+Alt+F12 auf eben dieser Konsole gelesen werden. Durch Drücken von Strg+Alt+F7 oder Alt+F7 kommt man anschließend wieder auf die grafische Oberfläche oder durch Drücken einer anderen F-Taste eben wieder auf die entsprechende Textkonsole.

Ein Grund für die Sonderbehandlung dieses einen Facility/Loglevel-Paares könnte der Umstand sein, dass zum Beispiel der TCP-Wrapper tcpd standardmäßig diese Einstellungen benutzt und man ihn von der »normalen« Behandlung des Mail-Loggings ausnehmen möchte.

mail.*;mail.!=info           /var/log/mail.log

Listing 9.51    Das restliche Mail-Logging

Möchte man alle anderen Nachrichten der LOG_MAIL-Facility in der /var/log/mail.log sammeln, so genügt die folgende Regel. In ihr wird eigentlich nach Facility geloggt (»mail.*«) und nur genau der Loglevel LOG_INFO ausgeschlossen (»mail.!=info«).

*.=info;*.=notice;*.=warn; 
        auth,authpriv.none; 
        cron,daemon.none; 
        mail,news.none          -/var/log/messages

Listing 9.52    Die /var/log/messages

/var/log/messages

In dieser Regel wird definiert, was alles in die /var/log/messages kommt. Dabei wären unter anderem alle Nachrichten der Loglevel LOG_INFO, LOG_NOTICE und LOG_WARNING. Nicht mit von der Partie sind jedoch alle Nachrichten der Facilities LOG_AUTH, LOG_AUTHPRIV oder auch LOG_CRON.

An diesem Beispiel waren vor allem zwei Dinge neu: Mehrere Facilities konnten durch Kommas getrennt werden, und es stand ein Minus vor der Datei. Dieses Minus verhindert das sofortige Schreiben neuer Nachrichten auf die Platte und ermöglicht durch die so mögliche Pufferung eine bessere Performance bei vielen Log-Einträgen.

*.=emerg                     *

Listing 9.53    Alle Notfälle an alle User schicken

Diese Regel schickt nun alle LOG_EMERG-Meldungen auf die Konsolen aller momentan eingeloggten Benutzer. Dieses Feature wird vom wall-Programm angeboten, dessen Features wie immer auf der entsprechenden Manpage gefunden werden können.

*.alert                      root,jploetner

Listing 9.54    Den Administrator benachrichtigen

Remote-Logging

Hier geben wir an, dass alle Nachrichten vom Level LOG_ALERT oder wichtiger direkt auf die Konsolen der User root und jploetner geleitet werden, so diese denn eingeloggt sind.

*.*                          @gateway

Listing 9.55    Remote-Logging komplett

Besonders bei einem mittleren bis größeren Rechenzentrum oder einem Rechner-Cluster ist es oft sinnvoll, das gesamte Logging auf einem Rechner vorzunehmen. Mit einer solchen Regel würde man offensichtlich alles – der Selektor »*.*« trifft keine Einschränkungen – auf den Rechner gateway weiterleiten.

Damit der syslogd auf dem entsprechenden Rechner auch Nachrichten aus dem Netzwerk annimmt, muss er mit der Option »-r« gestartet werden. Um dies zu automatisieren, muss diese Option im Startup-Skript des Dienstes eingetragen werden. Unter Debian wäre dies die /etc/init.d/sysklogd, in der man folgende Zeilen findet:

# Options for start/restart the daemons 
#   For remote UDP logging use SYSLOGD="-r" 
SYSLOGD=""

Listing 9.56    Den syslogd netzwerkfähig machen

Verfährt man nun wie in dem Kommentar beschrieben, können alle Rechner im Netzwerk auf diesem System loggen. Wie Sie allerdings Ihr Netzwerk korrekt konfigurieren, ist wieder ein anderes Thema.

9.4.3 logrotate 

Logfiles aufräumen

Nun werden Logdateien mit der Zeit immer größer, und übergroße Logdateien können potenziell ein System außer Gefecht setzen, indem sie irgendwann die ganze Festplatte füllen. Um dieser Probleme Herr zu werden, gibt es das Programm logrotate. Wird eine Logdatei zu groß oder ist ein bestimmter Zeitabschnitt vorüber, so wird die Logdatei gepackt beziehungsweise gelöscht und eine neue, leere Logdatei erstellt.

Dabei ist logrotate jedoch kein Dämonprozess – und das hat auch seine Gründe. Es ist nicht notwendig, dass das Programm die gesamte Zeit im Hintergrund läuft und Speicher sowie Rechenzeit frisst. Stattdessen läuft logrotate als Cronjob, wird also vom cron-Dämon in einem regelmäßigen Intervall gestartet.

Viele Distributionen haben logrotate schon als cron-Job sinnvoll vorkonfiguriert, und wenn Sie in Ihrem Logverzeichnis /var/log ein paar durchnummerierte und gepackte Dateien finden, ist logrotate schon am Werk.

… 
$ls /var/log/messages* 
/var/log/messages 
/var/log/messages-20050510.gz 
/var/log/messages-20050629.gz 
$

Listing 9.57    logrotate am Werk

Die Konfiguration

Konfiguriert werden kann logrotate über die /etc/logrotate.conf. Eine Beispieldatei sieht so aus:

# see "man logrotate" for details 
# rotate log files weekly 
weekly 
 
# keep 4 weeks worth of backlogs 
rotate 4 
 
# create new (empty) log files after rotating old ones 
create 
 
# we want our log files compressed 
compress 
 
# packages drop log rotation information into this 
# directory 
include /etc/logrotate.d 
 
/var/log/wtmp { 
    missingok 
    monthly 
    create 0664 root utmp 
    rotate 1 
}

Listing 9.58    Eine einfache logrotate.conf

Die Datei ist also wie folgt aufgebaut: Zuerst stehen »globale« Optionen, die – falls keine speziellen, überdeckenden Regelungen getroffen wurden – für alle Dateien gelten. In unserem Beispiel wäre mit diesen Optionen geregelt, dass die Logfiles wöchentlich rotiert (also als Backup gespeichert) werden, dass 4 dieser Backups komprimiert vorgehalten werden und dass nach dem Rotieren die Logfiles selbst wieder leer initialisiert werden.

Außerdem werden bei diesem der Debian-Standardinstallation entnommenen Beispiel alle im Verzeichnis /etc/logrotate.d befindlichen Dateien eingebunden. So können Softwarepakete die Rotation ihrer Logfiles selbst bestimmen, indem sie einfach eine entsprechende Datei in dem Verzeichnis ablegen.

Die Logfiles an sich werden in den von geschweiften Klammern eingefassten Blöcken ähnlich dem hier aufgeführten /var/log/wtmp-Beispiel noch einmal genau spezifiziert. Erst jetzt weiß logrotate, welche Dateien genau überwacht werden sollen und ob eventuell globale Optionen wie hier im Beispiel teilweise geändert wurden.

9.4.4 logcheck 

Gerade bei mehreren Servern oder großen Datenvolumen ist es umständlich, die Logdateien regelmäßig nach auffälligen Meldungen zu durchforsten. So kommt es oft zu der paradoxen Situation, dass Sicherheitsvorfälle zwar protokolliert, aber schlicht nicht beachtet werden.

Logfiles überprüfen

Abhilfe kann man zum Beispiel durch den Einsatz von logcheck erreichen, einem Tool, das bei den meisten Distributionen erst noch nachinstalliert werden muss. Über die sehr einfache Konfigurationsdatei /etc/logcheck/logcheck.conf kann man dem Programm sagen, welche der drei Alarmstufen »paranoid«, »server« und »workstation« man benutzen möchte und an welchen Mail-Account die Reports geschickt werden sollen.

# Controls the level of filtering: 
# Can be Set to "workstation", "server" or "paranoid" 
# for different levels of filtering. Defaults to 
# paranoid if not set. 
REPORTLEVEL="server" 
 
# Controls the address mail goes to: 
SENDMAILTO="admin@ihrefirma.de" 
 
# Should the hostname of the generated mails be 
# fully qualified? 
FQDN=1

Listing 9.59    Eine minimale logcheck.conf

Standardmäßig werden nur die /var/log/syslog und die /var/log/auth.log überprüft, aber über die Datei logcheck.logfiles, die sich wie die logcheck.conf meist in /etc/logcheck befindet, können weitere Logfiles hinzugefügt werden.

# these files will be checked by logcheck 
# This has been tuned towards a default syslog install 
/var/log/syslog 
/var/log/auth.log

Listing 9.60    logcheck

Intern arbeitet logcheck mit einer Datenbank von Filterausdrücken, die sich für die einzelnen Reportlevel in ihrer Ausführlichkeit unterscheiden. Diese Filter anzupassen ist im Allgemeinen jedoch unnötig, daher werden wir an dieser Stelle nicht weiter darauf eingehen.

Ihr Kommentar