9.5. syslog Systemereignisse

9.5. `syslog` Systemereignisse

9.5.1. Prinzip und Mechanismus

Der rsyslogd-Daemon ist für das Sammeln von Meldungen zuständig, die von den Anwendungen und vom Kernel kommen, und für ihre Verteilung auf weitere Protokolldateien (die normalerweise im Verzeichnis /var/log/ gespeichert werden). Er richtet sich nach der Konfigurationsdatei /etc/rsyslog.conf.

Jede Protokollmeldung ist einem Anwendungsuntersystem zugeordnet (in der Dokumentation „facility“ genannt):

auth und authpriv: für die Authentifizierung;
cron: kommt von den Diensten für die Aufgabenterminierung cron und atd;
daemon: betrifft einen nicht näher bestimmten Daemon (DNS, NTP usw.);
ftp: bezieht sich auf den FTP-Server;
kern: eine vom Kernel kommende Meldung;
lpr: kommt vom Druck-Subsystem;
mail: kommt vom E-Mail-Subsystem;
news: Usenet-Subsystemmeldung (insbesondere von einem NNTP-Server [Network News Transfer Protocol], der Nachrichtenforen verwaltet);
syslog: Meldungen vom syslogd-Server selbst;
user: Benutzermeldungen (allgemein);
uucp: Meldungen vom UUCP-Server (Unix to Unix Copy Program, ein altes vor allem zur Verteilung von E-Mails verwendetes Protokoll);
local0 bis local7: für die lokale Verwendung reserviert.

Jeder Meldung ist auch eine Prioritätsstufe zugeordnet. Hier sind sie in abnehmender Reihenfolge:

emerg: „Hilfe!“ Es gibt einen Notfall, das System ist möglicherweise unbrauchbar.
alert: Beeilung! Jede Verzögerung kann gefährlich sein, es muss sofort etwas unternommen werden;
crit: die Umstände sind kritisch;
err: Fehler;
warn: Warnung (möglicher Fehler);
notice: die Umstände sind normal, aber die Meldung ist wichtig;
info: aufschlussreiche Meldung;
debug: Fehlerbeseitigungsmeldung.

9.5.2. Die Konfigurationsdatei

Die Syntax der Datei /etc/rsyslog.conf ist auf der Handbuchseite rsyslog.conf(5) ausführlich erläutert, im Paket rsyslog-doc findet sich aber auch eine HTML-Dokumentation (/usr/share/doc/rsyslog-doc/html/index.html). Das Grundprinzip besteht darin, Paare von „selector“ und „action“ zu verfassen. Der Selektor bestimmt alle relevanten Meldungen, und die Aktionen beschreiben, wie mit ihnen umzugehen ist.

9.5.2.1. Syntax des Selektors

Der Selektor ist eine durch Semikolon getrennte Liste von subsystem.priorität-Paaren (Beispiel: auth.notice;mail.info). Ein Stern kann für alle Subsysteme oder alle Prioritäten stehen (Beispiele: *.alert oder mail.*). Mehrere Subsysteme können in einer Gruppe zusammengefasst werden, indem sie durch ein Komma getrennt werden (Beispiel: auth,mail.info). Die angezeigte Priorität bezieht sich auch auf Meldungen gleicher oder höherer Priorität; so bezeichnet auth.alert Meldungen des auth-Subsystems mit der Priorität alert oder emerg. Mit einem vorangestellten Ausrufezeichen (!) bezeichnen sie das Gegenteil, mit anderen Worten nur die niedrigeren Prioritäten; so bezeichnet auth.!notice Meldungen, die von auth mit den Prioritäten info oder debug verschickt worden sind. Mit einem vorangestellten Gleichheitszeichen (=) beziehen sie sich genau und ausschließlich auf die angegebene Priorität (bei auth.=notice handelt es sich ausschließlich um Meldungen von auth mit der Priorität notice).

Jedes Element in der Selektorliste setzt vorhergehende Elemente außer Kraft. Es ist somit möglich, eine Menge einzugrenzen oder bestimmte Elemente von ihr auszuschließen. Zum Beispiel bezeichnet kern.info;kern.!err Meldungen vom Kernel mit einer Priorität zwischen info und warn. Die Priorität none bezeichnet die leere Menge (keine Prioritäten) und kann dazu dienen, ein Subsystem von einer Menge von Meldungen auszuschließen. So bezeichnet *.crit;kern.none alle Meldungen mit der Priorität crit oder höher, die nicht vom Kernel kommen.

9.5.2.2. Syntax der Aktionen

ZURÜCK ZU DEN GRUNDLAGEN Die benannte Pipe, eine beständige Pipe

Eine benannte Pipe ist eine besondere Dateiart, die wie eine gewöhnliche Pipe funktioniert (die Pipe, die man mit dem Symbol „|“ auf der Befehlszeile erstellt), aber mittels einer Datei. Dieses Vorgehen hat den Vorteil, dass sich so zwei unzusammenhängende Prozesse verknüpfen lassen. Alles, was in eine benannte Pipe geschrieben wird, hält den schreibenden Prozess an, bis ein anderer Prozess die geschriebenen Daten zu lesen versucht. Dieser zweite Prozess liest die Daten, die vom ersten geschrieben wurden, der daraufhin seinen Ablauf wieder aufnehmen kann.

Eine derartige Datei wird durch den Befehl mkfifo erstellt.

Die verschiedenen möglichen Aktionen sind:

die Meldung zu einer Datei hinzufügen (Beispiel: /var/log/messages);
die Meldung an einen entfernten syslog-Server schicken (Beispiel: @log.falcot.com);
die Meldung an eine bestehende benannte Pipe schicken (Beispiel: |/dev/xconsole);
die Meldung an einen oder mehrere Benutzer schicken, falls sie angemeldet sind (Beispiel: root,rhertzog);
die Meldung an alle angemeldeten Benutzer schicken (Beispiel: *);
die Nachricht in eine Textkonsole schreiben (Beispiel: /dev/tty8).

SICHERHEIT Protokolle weiterleiten

Es empfiehlt sich, die wichtigsten Protokolle auf einem getrennten Rechner aufzuzeichnen (vielleicht auf einem, der speziell diesem Zweck dient), da dies einen möglichen Eindringling daran hindert, Spuren seines Eindringens zu verwischen (es sei denn natürlich, dass er auch diesen anderen Server kompromittiert). Außerdem sind im Falle eines wesentlichen Problems (wie einem Kernel-Crash) die Protokolle auf einem anderen Rechner verfügbar, was die Chancen erhöht, den Ablauf der Ereignisse, die den Crash verursacht haben, zu bestimmen.

Für den Empfang von Protokollmeldungen, die von anderen Rechnern geschickt werden, müssen Sie die Konfiguration von rsyslog ändern: im Prinzip reicht es aus, die gebrauchsfertigen Einträge in /etc/rsyslog.conf ($ModLoad imudp und $UDPServerRun 514) zu aktivieren.