Zurück

1.111.3

Konfigurieren und Nutzen der Systemlogs im Rahmen der administrativen und Sicherheitsanforderungen


Beschreibung: Prüfungskandidaten sollten in der Lage sein, die Systemaufzeichnungen zu konfigurieren. Dieses Lernziel beinhaltet das Einstellen der Art und Menge der aufgezeichneten Informationen, das manuelle Prüfen von Logdateien auf wichtige Aktivitäten, das Überwachen der Logdateien, das Einrichten automatischer Rotation und Archivierung der Logs und das Verfolgen von Problemen, die in den Logdateien aufgezeichnet

Die wichtigsten Dateien, Bezeichnungen und Anwendungen:


Unter Linux verwaltet ein spezieller Daemon-Prozess ein Systemlogbuch, das von allen Programmen und insbesondere von allen anderen Daemon-Prozessen benutzt werden kann, um Meldungen abzugeben. Dabei kann es sich um Meldungen des normalen Systemablaufs handeln oder um Alarmmeldungen, die sofortiges Eingreifen notwendig machen. Man spricht hier von unterschiedlichen Prioritäten.

Jedes Programm kann also über einen Systemaufruf solche Meldungen abgeben. Der Daemon, der diese Meldungen entgegennimmt und entscheidet, was mit ihnen zu geschehen hat heißt syslogd. Damit der Systemverwalter entscheiden kann, was mit welchen Meldungen geschehen soll kann dieser Daemon über die Datei /etc/syslog.conf konfiguriert werden.

In der Regel werden die verschiedenen Meldungen In Dateien geschrieben, die im Verzeichnis /var/log oder einem darinliegenden Unterverzeichnis abgelegt werden. Aber genau diese Frage, wohin wird welche Meldung geschrieben, wird in der Konfigurationsdatei ja eingestellt.

Die Datei /etc/syslog.conf

Jede Zeile dieser Datei, die nicht leer ist oder mit einem # beginnt, beschreibt eine Regel, was mit einer bestimmten Meldung passieren soll. die grundlegende Form jeder Zeile ist immer gleich und lautet:
  Herkunft.Priorität     Aktion
Sollen in einer Regel mehrere Herkunftskategorien angegeben werden, so können sie, durch Kommas voneinander getrennt, nacheinander aufgeführt werden. Sollen mehrere Herkunfts/Prioritäts-Paare gleichzeitig angegeben werden, so müssen diese durch Strichpunkt getrennt angegeben werden. Sowohl Herkunft, als auch Priorität können durch ein Sternchen (*) ersetzt werden, das als Wildcard dient. In diesem Fall sind alle Herkunfts- bzw. Prioritätskategorien angesprochen.

Für Herkunft, Priorität und Aktion sind die folgenden Werte gültig:

Herkunftskategorien

kern Systemmeldungen direkt vom Kernel
auth Meldungen vom Sicherheitsdienst des Systems (login, ...)
authpriv Vertrauliche Meldungen der internen Sicherheitsdienste
mail Meldungen des Mail-Systems
news Meldungen des News-Systems
uucp Meldungen des UUCP-Systems
lpr Meldungen des Druckerdaemons
cron Meldungen des Cron-Daemons
syslog Meldungen des syslog-Daemons selbst
daemon Meldungen aller anderer Daemon-Prozesse
user Meldungen aus normalen Anwenderprogrammen
local0-local7     frei verwendbar

Prioritäten in absteigender Reihenfolge

emerg Der letzte Spruch vor dem Absturz
alert Alarmierende Nachricht, die sofortiges Eingreifen erforderlich macht
crit Meldung über eine kritische Situation, die gerade nochmal gut gegangen ist
err Fehlermeldungen aller Art aus dem laufenden Betrieb
warn       Warnungen aller Art aus dem laufenden Betrieb
notice Dokumentation besonders bemerkenswerter Situationen im Rahmen des normalen Betriebs
info Protokollierung des normalen Betriebsablaufes
debug Mitteilungen interner Programmzustände bei der Fehlersuche
none Ist keine Priorität im eigentlichen Sinn, sondern dient zum Ausschluß einzelner Herkünfte

Eine angegebene Priorität meint immer die genannte oder eine höhere. Wenn jedoch vor der Priorität ein Gleichheitszeichen (=) steht, so ist nur die genannte Priorität gemeint.

Aktionen

Eine Aktion ist immer eine Weiterleitung einer Nachricht. Es gibt vier verschiedene Arten, wie solche Nachrichten weitergeleitet werden können:

  1. Ausgabe der Nachricht in eine Datei.
    Dazu muß als Aktion der Dateiname mit absolutem Pfad (mit führendem Slash) angegeben werden. Normalerweise wird nach jedem Schreibvorgang des Syslog-Daemons eine Synchronisation des Dateisystems durchgeführt, weil sonst evt. Nachrichten bei einem Absturz nicht mehr physikalisch in die Datei geschrieben werden. Das ist allerdings eine sehr zeitaufwendige Aktion, daher gibt es die Möglichkeit, diese Synchronisation zu übergehen. Dazu wird dem absoluten Pfadnamen ein Bindestrich (-) vorangestellt.
  2. Weiterleitung der Nachricht an einen Syslog-Daemon eines anderen Rechners im Netz.
    Dazu muß als Aktion der Rechnername des Rechners angegeben werden, an dessen Syslog-Daemon die Messages geschickt werden sollen. Dem Rechnernamen muß ein Klammeraffe (@) vorangestellt werden. Damit der angesprochene Syslog-Daemon auf dem anderen Rechner auch die Meldungen annimmt, muß er mit der Kommandozeilenoption -r (remote) gestartet worden sein.
  3. Ausgabe der Nachricht auf den Bildschirm von bestimmten Usern
    Durch die Nennung des Usernamens (oder einer durch Kommas getrennten Liste von Usernamen) wird die Nachricht auf dem Bildschirm dieser User angezeigt, sofern sie eingeloggt sind.
  4. Ausgabe der Nachricht auf den Bildschirm aller eingeloggten User
    In diesem Fall steht einfach ein Sternchen (*) im Aktionsfeld.

Ein paar Beispiele

Wie können nun solche Regelzeilen aussehen? Nehmen wir an, wir wollen dafür sorgen, daß alle Meldungen des Systems in die Datei /var/log/messages geschrieben werden. Das erledigt die Zeile
  *.*         /var/log/messages
Wollen wir aber die Meldungen des Login-Systems, die eventuell Passwörter in Klarschrift enthalten ausschließen, so können wir das mit der Priorität none erledigen:
  *.*;authpriv.none         /var/log/messages                    
Wir können dafür sorgen, daß Meldungen des Kernels, ab der Priorität warn immer auf den Bildschirm von root geschickt werden, sofern er eingeloggt ist. Falls der User foo eingeloggt ist, soll er die Meldungen auch bekommen:
  kern.warn      root,foo
Auch Gerätedateien sind Dateien. Schreiben wir alle Meldungen des Kernels die mindestens die Priorität warn haben und alle Meldungen ab error aller anderen Kategorien auf die Konsole 10 (/dev/tty10). Die Meldungen von authpriv lassen wir aber wieder weg. Auf Konsole 10 können sie dann auf dem Bildschirm mitgelesen werden:
  kern.warn;*.err;authpriv.none   /dev/tty10
Die nächsten drei Zeilen schreiben Alle Dateien werden nicht sofort synchronisiert (-)
  news.=crit                      -/var/log/news/news.crit
  news.=err                       -/var/log/news/news.err  
  news.=notice                    -/var/log/news/news.notice
Wenn wir einen zentralen Rechner haben, nennen wir ihn admhost, der das Logbuch für alle Rechner im Netz mitschreiben soll, so müssten alle Rechner im Netz die Zeile
  *.*;authpriv.none          @admhost
in der syslog.conf eingetragen haben. Der syslogd auf admhost müsste dazu mit der Option -r gestartet sein.

Durch eine durchdachte Einteilung kann sich ein Systemverwalter viel Arbeit ersparen. Es ist ja möglich, daß alle denkbaren Ereignisse in verschiedene Dateien geschrieben werden, die dann schnell und effizient durchsucht werden können. Werden z.B. alle Meldungen ab der Priorität error (oder für vorsichtige Systemverwalter besser warn) in eine spezielle Datei geschrieben, so kann der Systemverwalter diese Datei regelmäßig überprüfen und muß sich nicht lange durch einen Berg von alltäglichen Meldungen kämpfen, um kritische Meldungen zu entdecken.

Verfolgen von Logdateien in Echtzeit

Manchmal ist es notwendig, Logdateien während einer bestimmten Aktion zu beobachten, um bestimmte Meldungen zu verfolgen. Um eine solche Beobachtung in "Echtzeit" zu ermöglichen gibt es zwei verschiedene Möglichkeiten. Die erste und am häufigsten angewandte Methode wird mit dem Befehl tail realisiert. tail kennt den Parameter -f, der eben diese Fähigkeit zur Verfügung stellt. Der Befehl
  tail -f /var/log/messages
zeigt die letzten 10 Zeilen der Datei /var/log/messages am Bildschirm an. Statt aber dann zur Eingabeaufforderung zurückzukehren verharrt tail (durch den Parameter -f - forever) und wartet, ob die Datei "wächst", also neue Zeilen angefügt bekommt. Sobald neue Zeilen in die Datei geschrieben werden, werden sie auch auf dem Bildschirm ausgegeben.

Somit kann die Datei also "beim Wachsen beobachtet werden", erst ein Strg-C beendet diese fortlaufende Beobachtung. Diese Fähigkeit ist natürlich ideal geeignet, Log-Dateien zu beobachten, während ein Fehler gesucht wird.

Die zweite angesprochene Möglichkeit bietet das Programm less, der uns wohlbekannte Pager. less kennt auch die Möglichkeit einer Datei beim Wachsen zuzusehen, dazu muß der Befehl F eingegeben werden. Auch dieser Modus muß mit einem Strg-C abgebrochen werden.

Automatische Rotation der Logbuchdateien

Logbuchdateien werden zwangsläufig ziemlich schnell wachsen. Im normalen Betriebsablauf eines Linux-Rechners, der nicht nur untätig in der Ecke steht können pro Tag problemlos 50 bis 100 Kilobyte Meldungen entstehen. Da bietet es sich doch an, diese Logbücher hin und wieder zu löschen oder zu archivieren.

Im professionellen Umfeld sollten Logdateien niemals gelöscht werden. Sie sollten besser archiviert und abgespeichert werden, am besten zusammen mit dem Datum der Speicherung oder noch besser mit dem Start- und Enddatum. Einmal archiviert kann eine solche Datei dann komprimiert werden, Programme wie gzip sind bestens geeignet, Textdateien wie Logbücher mit immer wiederkehrenden Textpassagen auf eine sehr geringe Größe zu bringen. Eine Logdatei kann so tatsächlich weniger als ein Zehntel ihrer ursprünglichen Größe bekommen.

Verschiedene Linux-Distributionen gehen hier verschiedene Wege. Aber es zeichnet sich ein Standard ab, der dazu geeignet ist, zu große Logbuchdateien regelmäßig zu komprimieren und optional auch regelmäßig per Mail zu verschicken. Das Programm, das diesen Job übernimmt heißt logrotate und wird regelmäßig von cron (siehe Kapitel 1.111.4) aufgerufen.

logrotate bezieht seine Informationen aus einer (oder mehrerer) Konfigurationsdateien, die ihm als Kommandozeilenparameter mitgegeben wurden. Das genaue Format dieser Dateien ist auf der Handbuchseite erklärt.

Vielleicht sollte der Begriff Rotation noch einmal genauer erklärt werden. Er stammt aus der Welt des Backup, in der meist mehrere Bänder für ein Backup verwendet werden. Wenn wir beispielsweise jeden Freitag ein Backup machen, dann benutzen wir nicht jedesmal das selbe Band, sondern wir haben vielleicht 5 Bänder. Nun "rotieren" wir diese Bänder, das heißt, das wir in der ersten Woche das erste Band benutzen, in der zweiten das zweite usw. In der sechsten Woche benutzen wir dann also wieder das erste Band. So stehen uns immer die letzten 5 Wochen zur Verfügung.

Genauso läuft es mit den Logdateien. Das Programm logrotate rotiert die Logdateien, das heißt die gegenwärtige Logdatei wird - wenn ein bestimmtes Kriterium (Größe, Tag, Woche, Monat) erfüllt ist - in eine andere Datei kopiert (und optional komprimiert). Die Orginal-Logdatei wird dann gelöscht und neu angelegt. Die Anzahl der Rotationen (analog zu der Anzahl der verwendeten Bänder aus dem Backup-Beispiel) ist einstellbar. Das würde bedeuten, daß nach beispielsweise fünf Rotationen die älteste Datei gelöscht wird und statt dessen die neue Rotationsdatei angelegt wird. So haben wir die Sicherheit, daß immer nur eine begrenzte Anzahl von Dateien (und eine begrenzte Menge Speicherplatz) verwendet wird.

Optional kann man es aber auch so einrichten, daß die Logdatei, bevor sie dann endgültig gelöscht wird, an eine anzugebende E-Mail-Adresse gemailt wird.

 

 

 


[Zurück zur LPIC 102 Seite]  [Zurück zur Startseite]  [Zurück zur LPI Seite]  [Kontakt]  [Impressum


Diese und die darunterliegenden Seiten wurden erstellt von F. Kalhammer

© 2002 by F.Kalhammer -
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License..