3.1.1 Meldungsbeschreibung

Die Meldungsbeschreibung ist eine Liste aus Facility/Priority-Paaren. Das wird so verwendet: Ist eine Meldung der entsprechenden Facility mindestens so wichtig, wie die Priority angibt, wird die rechte Seite verwendet (die Aktion wird ausgeführt). Hat man viele Regeln, so werden wichtige Meldungen damit oft in mehrere Dateien geloggt; dies ist erwünscht.

Der Grundaufbau der durch Semikolon (;) getrennten Facility/Priority-Paaren ist einfach: Facility und Priority stehen in dieser Reihenfolge durch einen Punkt getrennt. Wichtige Kernelmeldungen lassen sich beispielsweise durch:

kern.warning

beschreiben. Hier sind nicht nur die Meldungen der Priorität warning, sondern auch alle höheren (also err, crit, alert und emerg) gemeint. Man kann auch Wildcards verwenden, so zum Beispiel *.warning für alle wichtigen Meldungen und kern.* für alle Kernelmeldungen. Hierbei ist jedoch zu beachten, daß nicht alle Syslogdienste Wildcard verstehen (aber die unter GNU/Linux verwendeten können dies). Bei GNU/Linux-Syslog kann man auch mehrere Facilities durch Komma (,) getrennt aufführen. Dies ist jedoch nur zulässig, wenn diese alle die gleiche Priorität haben (die nur an der letzten Facility angehängt steht). Nach dieser komplizierten Erklärung ein einfaches Beispiel: Wichtige Meldungen von News oder Mail:

news,mailwarning

Oft wird jedoch auch hier lieber eine durch Semikolon getrennte Liste verwendet, weil es als lesbarer und weniger verwirrend empfunden wird:

news.warning;mail.warning

Verwendet man Wildcards, kann man sämtliche Meldungen mit *.* erfassen. GNU/Linux-Syslog bietet neben Wildcards weitere nützliche Erweiterungen: Möchte man nicht, dass alle Meldungen auch höherer Priorität passen, kann man vor die Priority ein Gleichheitszeichen (=) setzen, beispielsweise *.=warning. In solchen Fällen muß man aber unbedingt Regeln haben, die auch die wichtigeren Meldungen verarbeiten, sonst fehlen am Ende die wichtigsten Meldungen!

Es ist auch möglich, mit einem Ausrufezeichen (!) eine Priorität auszuschließen, zum Beispiel *.=!warning, was man aber sehr selten sieht.

Widersprechen sich Bedingungen einer durch Semikolon getrennten Bedingungsliste, so gilt die zuletzt beschriebene, also

kern.=!info;kern.*

loggt jegliche Kernelmeldung (hier meinte man vermutlich einfach kern.=!info). Solche Konstrukte sind natürlich zu vermeiden.

Es gibt eine spezielle Priority none, die für keine Priority der dazugehörigen Facility steht:

*.info;mail.none

bezeichnet alle Meldungen mit Priority info, außer von der Facility mail.

3.1.2 Meldungsaktion

Auf der rechten Seite steht dann, was mit Meldungen geschehen soll. Im einfachsten Fall steht hier ein Dateiname. Diese müssen mit vollem Pfad angegeben werden, sie beginnen also mit einem Slash (/). Beispiel: /var/log/messages. Möchte man nicht-synchronisiert schreiben (später mehr dazu), schreibt man noch ein Minus (-) davor: -/var/log/messages. Als spezielle Datei kann man auch ein Terminal, zum Beispiel /dev/tty10, verwenden. Dann erscheinen die Meldungen auf der Konsole 10 (die man meist über ATL+F10 oder STRG+ALT+F10 erreicht).

Neben Dateien kann man auch sogenannte named FIFOs verwenden. Diese beginnen mit einem Pipezeichen (|), gefolgt vom Dateinamen. Für diese Spezialität erfolgt an dieser Stelle jedoch keine detaillierte Diskussion.

Soll die Meldung an einen anderen Server übertragen werden, schreibt man ein At-Zeichen (@) und den Hostnamen oder besser eine IP-Adresse des Systems, zum Beispiel @192.168.1.14.

Um die Meldung auf die Terminals von Benutzern zu schreiben, schreibt man einfach dessen Accountnamen, beispielsweise root. Hier darf auch ein * stehen. Dann werden alle Benutzer (also alle Terminals) informiert. Das kann jedoch stören, denn die Meldungen erscheinen dann "mitten im Terminaltext" und "verunstalten" das Layout der laufenden Anwendung (wenn man zum Beispiel gerade einen Editor offen hat. Etliche Anwendungen haben eine Möglichkeit, die Anzeige neuzuzeichnen, häufig STRG+L ).

3.1.3 Beispielkonfigurationsdatei

Es folgt ein Beispiel mit ausführlichen Kommentaren.

 
#/etc/syslog.conf: Syslogkonfigurationsdatei
#Zur Trennung der "linken" und "rechten" Seite sollten
#   Tabstops verwendet werden (moderne GNU/Linux Syslog
#   Implementierungen kommen meist auch mit Leerzeichen klar)

#sehr wichtige Warnungen vom Kernel, und alle Fehler außer
#   evtl. Passwortvertipper auf die Konsole ALT-F10 loggen.
#   Zur Erinnerung: .warn schließt höhere Meldungen (also err,
#   crit, alert, emerg) mit ein. Diese landen also auch auf
#   ALT-F10.
kern.warning;*.err;authpriv.none        /dev/tty10

#Die gleichen Meldungen für die xconsole bereitstellen
#  (Hier wird ein FIFO verwendet, der von xconsole
#   ausgelesen wird)
kern.warn;*.err;authpriv.none           |/dev/xconsole

#ALLE Meldungen auf ALT-F9. Das ist für einen schnellen Überblick
#  bei "Echtzeit-Fehleranalyse" hilfreich
*.*                                     /dev/tty9

#alle sehr schweren Fehler direkt an alle Benutzer in die Konsolen
#  schreiben. In solchen Fällen ist das System vermutlich eh kaum
#  noch benutzbar. Eventuell sieht man aber kurz vor dem Absturz
#  noch eine Fehlermeldung und kann nach einem Neustart etwas
#  ändern
*.emerg                                 *

#Root möchte eventuell auch schon "crit" auf der Console sehen,
#  wenn er zufällig gerade an dem System arbeitet:
#*.crit                                 root

#Alle EMail-Meldungen in eine eigene Datei. Diese Datei wird
#  aus Performance-Gründen nicht nach jeder Zeile synchronisiert,
#  (aber schwere Fehler schreiben wir nochmal in eine extra Datei)
mail.*                                  -/var/log/mail

#Warnungen in eine extra Datei. Diese wird hier nicht sync'd (bei
#  langsameren Systemen hilfreich)
*.=warn;*.=err                          -/var/log/warn

#"crit" und höhere kommen in die gleiche Datei, aber sync'd
*.crit                                  /var/log/warn

#alles außer "debug" und mail in eine andere Datei
*.info;mail.none                        -/var/log/messages

#Für die Fehlersuche hilft oft eine Datei, die sämtliche
#Informationen enthält
#*.*                                    -/var/log/allmessages

#Hat man einen Loghost, soll dieser eine Kopie von allen
#  Meldungen erhalten
#*.*                                    @192.168.1.1

#Weniger wichtige Systeme sollen das Netzwerk nicht unnötig
#  belasten
#*.warn                                 @192.168.1.1
      

  SYSLOGD_PARAMS=""  

3.3.1 Vorteile des Remote-Logging

Oft hat man in LANs einen zentralen Host, der Netzwerk-Syslog-Meldungen erhält, und diese in Dateien schreibt. Diesen Host nennt man Loghost.

Diese Konfiguration hat etliche Vorteile: So kommen die Meldungen zentral auf einer Maschine an, so dass man auch komplexere Störungen analysieren kann (wenn diese mehrere Server betreffen, zum Beispiel einen Mailserverausfall, weil DNS ausgefallen ist).

Ein weiterer Vorteil liegt im Fall von erfolgreichen Angriffen vor. Wenn ein Angreifer ein System kompromitiert hat, wird er in den meisten Fällen die Syslogdateien löschen oder manipulieren, um sich zu tarnen und seine Herkunft zu verschleiern. Wenn nun aber der Administrator einen Loghost verwendet, ist es unwahrscheinlicher, dass auch dieser gleichzeitig gehackt wird. So kann er auf dem Loghost die Meldungen analysieren und wichtige Informationen über den Angriff erlangen.

Ein dritter Vorteil der Zentralisierung ist die Vereinfachung automatischer Behandlung von Logfiles, zum Beispiel wird das Aufbereiten/Filtern und als Mail Verschicken erleichtert: Man muß diesen Vorgang nur auf einer Maschine pflegen.

3.3.2 Nachteile des Remote-Logging

Remote-Logging hat aber auch Nachteile, gerade, wenn man Syslog einsetzt. Syslog verwendet ausschließlich das UDP Protokoll. UDP Pakete werden direkt verschickt, ihr Empfang wird nicht bestätigt. Auf stark ausgelasteten Netzen kann es daher vorkommen, dass Meldungen verloren gehen, ohne dass man es bemerkt. Weiterhin kann ein Angreifer den Loghost überfluten, in dem er sehr viele sinnlose Meldungen verschickt. Dies kann die Last auf dem Loghost stark erhöhen, und im Extremfall dazu führen, dass er nur noch einen Teil der wichtigen Meldungen erhält, und die Netzwerklast kann zu weiteren Störungen führen. Bei sehr massiven Flut-Angriffen ist auch ein Vollaufen der Festplatte denkbar. In diesem Fall ist neben dem Verlust von Logmeldungen in der Regel mit weitereren empfindlichen Störungen zu rechnen, oft mit einem Totalausfall sämtlicher Dienste des Loghosts!

Ein Angreifer, der eine Maschine gehackt hat, und hier über root-Rechte verfügt, kann auch einen Netzwerk-Sniffer verwenden, um die Syslog-Nachrichten, die über das Netzwerk verschickt werden, mitzulesen. Er kann dadurch wichtige Informationen ausspionieren. Syslog gestattet leider keine Verschlüsselung oder andere Absicherung der Netzwerkkommunikation.

3.3.3 Konfiguration des Loghosts

Die Konfiguration des Loghosts ist einfach. Man muß lediglich den Empfang aktivieren, in dem man Syslog mit der Option -r startet. Bei SuSE-Systemen öffnet man dazu einfach die Datei /etc/rc.config, und ändert

  SYSLOGD_PARAMS=""  

so, dass die Startoption -r verwendet wird. Die IP Adressen der Hosts, die den Loghost verwenden, sollte man in die Datei /etc/hosts eintragen, um Fehlern bei DNS Ausfällen vorzubeugen.

Kommt nun eine Nachricht über das Netzwerk, schaut Syslog anhand der Sender-IP Adresse nach, wie der Hostname des Systems lautet. Ist dieser beispielsweise  www.selflinux.de, so wird dieser Name im Logfile eingetragen. Dies ist unübersichtlich, und man möchte vermutlich die Ausgaben von ".selflinux.de unterdrücken (sofern der Teil davor eindeutig ist). Dazu verwendet man am einfachsten die Option -s, die die Domainanteile abschneidet. In unserem Beispiel würde der Administrator also -r -s selflinux.de verwenden. Hat er ein SuSE-System, trägt er einfach in /etc/rc.config ein:

 SYSLOGD_PARAMS="-r -s selflinux.de"  

Syslog verwendet den UDP Port syslog. Dieser wird in der Datei /etc/services nachgesehen. Normalerweise soll Syslog die Portnummer 514 verwenden. Demzufolge muß folgende Zeile in der Datei /etc/services vorhanden sein:

 syslog          514/udp  

Dies ist bei gängigen Distributionen (SuSE, RedHat) jedoch bereits richtig eingetragen.

Nun muß Syslog neu gestartet werden, damit die Änderungen aktiv werden. Dazu schreibt man beispielsweise:

Auf SuSE Systemen kann man auch schreiben:

Nun akzeptiert der Syslog Nachrichten vom Netzwerk.

3.3.4 Konfiguration der anderen Hosts

Die Maschinen, die nun den Loghost verwenden sollen, müssen hierzu angepaßt werden. Ein neuer Eintrag in der Datei /etc/syslog.conf ist auf jedem Server notwendig. Möchte man alle Nachrichten auf den Loghost 192.168.1.1 loggen, verwendet man:

  *.*                   @192.168.1.1  

Um nur wichtige Meldungen zu verschicken, kann man

  *.warn                @192.168.1.1  

verwenden. Es kann auch mehrere solcher Zeilen geben, so kann man sich auch eine Konfiguration mit zwei Loghosts vorstellen. Über den Sinn solchen Vorgehens kann man natürlich streiten.

Nach dem Ändern dieser Datei muß Syslog neu geladen oder neu gestartet werden. Dazu kann man Syslog ein Hangup-Signal senden (SIGHUP), in dem man beispielsweise schreibt:

oder auf SuSE-Systemen das Startscript verwenden:

Man kann Syslog aber auch einfach neu starten (stop/start). Allerdings gehen hier möglicherweise für einige Sekunden Meldungen verloren.

3.3.5 Beispiel für Logeinträge

Auf dem Loghost kann man dann gut das Netzwerksystem beobachten. Ein fiktives Beispiel:

      
Mar 10 13:30:30 atlas syslogd 1.3-3: restart.

Apr  1 13:02:01 ns1 named[124]: XX+/127.0.0.1/1.1.168.192.
                                in-addr.arpa/PTR/IN
Apr  1 13:02:01 www httpd[123]: GET /login.cgi?username=steffen
Apr  1 13:02:03 www httpd[123]: Starting authorization for
                                "steffen" from "ws1.selflinux.de"
Apr  1 13:02:04 radius radiusd[125]: autorization request from
                                "www.selflinux.de" for "steffen"
Apr  1 13:02:04 db kernel: end_request: I/O error, dev 03:02 (hda),
                                sector 58138452
Apr  1 13:02:04 db postmaster[111]: Database error: disk read failed
                                (I/O error)
Apr  1 13:02:04 radius radiusd[125]: authorization request for
                                "steffen" failed (database error)
Apr  1 13:02:03 www httpd[123]: Authorization for "steffen" failed
                                (incorrect password)
      
      

In diesem fiktiven Szenario sieht man eine fehlgeschlagene Web-Anmeldung. Der Webserver (httpd) löste die IP Adresse auf (über "named" auf "ns1") und fragte dann bei einem Radius-Dienst auf einem separten Server nach. Dieser wiederum verwendete eine PostgreSQL Datenbank auf einem anderen Server. Diese hat ein großes Problem: Eine kaputte Festplatte ( sector 58138452 konnte nicht gelesen werden). Demzufolge kann PostgreSQL (postmaster) die Anfrage nicht bestätigen. Radius meldet also einen Fehler, den der Webserver als incorrect password fehlinterpretiert. Nicht das falsche Passwort war das Problem, sondern eine kaputte Festplatte! In diesem Fall würde man im Webserverlog sehr viele incorrect password finden, und einen Angriff vermuten. Doch durch die Verwendung eines Loghosts sind die Meldungen aller Komponenten zentral verfügbar. Hier hat das die Fehlersuche erheblich beschleunigt (der Administrator hat die Festplatte sofort gewechselt und die Bandsicherung zurückgespielt).

3.4.1 Serverkonfiguration

Bei der Installation eines Servers kann man überlegen, wie man mit großen Logfiles umgehen möchte. Hier ist zunächst von Interesse, dass große Logdateien Filesysteme füllen können. Hat man die Logdateien (in der Regel also das Verzeichnis /var/log) im selben Filesystem gemoutet wie beispielsweise das Root-Filesystem /, so ist damit zu rechnen, dass nach einer Logflut das System vollkommen unbenutzbar ist, also mit dem Ausfall sämtlicher Dienste.

Diese Gefahr kann man durch den Einsatz von Werkzeugen wie logrotate oder dem SuSE-Linux /etc/logfiles Mechanismus senken. Auf SuSE-Systemen trägt man hierzu jede Logdatei in /etc/logfiles ein. Hinter den Dateinamen schreibt man die Größe (z.B. +1024k) und den Zugriffsmodus (beispielsweise 640) und den Eigentümer (beispielsweise root.root). Die erste Option wird für das Dienstkommando find als Parameter verwendet, der zweite für chmod und der dritte für chown. Die manpages dieser drei Werkzeuge geben Auskunft über Art der verwendbaren Werte. Auf SuSE-Systemen sind in dieser Datei die voreingestellten Logdateien bereits eingetragen. Eigene Dateien muß man hier natürlich hinzufügen.

Eine weitere Möglichkeit wäre der Einsatz von separaten Filesystemen. Man kann z.B. /var auf eine andere Partition oder ein anderes LVM LV (logical volume) mounten. Dies hat jedoch auch Nachteile: es wird nicht der gesamte verfügbare Platz für Logfiles verwendet (demzufolge fällt das Logging früher aus), und insbesondere Angriffe und Störungen sind damit nicht mehr rekonstruierbar. Daher ist eine regelmäßige Überprüfung der freien Plattenkapazität durchzuführen, vorzugsweise automatisch, dann kann man es nicht vergessen.

3.4.2 Bootkonfiguration

Syslog sollte stets laufen. Syslog benötigt meist Schreibzugriff auf Festplatten. Bei Konfigurationen mit einem zentralen Loghost wird weiterhin das Netzwerk benötigt. Daher sollte man Syslog unmittelbar nach dem Hochfahren des Netzwerkes starten. Auf SuSE-Systemen verhält sich das bereits so.

Es ist denkbar, den Start von Syslog vor dem des Netzwerkes durchzuführen, wenn man keinen Loghost verwendet. Eventuell erhält man so mehr Meldungen.

Nach dem Start von Syslog sollte man den Kernel-Logger klogd starten. Sicherheitshalber wartet man z.B. eine Sekunde dazwischen. Die GNU/Linux-Startscripte sollten dies bereits so machen (bei SuSE-Systemen ist es der Fall).

3.4.3 Syslog-Konfiguration

Man sollte darauf achten, dass keine Meldungen überhaupt nicht geloggt werden. Meistens möchte man verschiedene Dateien haben, um schnell Meldungen zu finden. Oft werden mindestens die Dateien /var/log/messages und /var/log/warn verwendet. Letzere enthält nur wichtige Meldungen. Sehr üblich ist auch eine Datei /var/log/mail und eventuell /var/log/news für Meldungen des Mail- bzw. Newssystems. Häufig sieht man auch /var/log/allmessages oder /var/log/allinone, die sämtliche Meldungen enthalten.

Zusätzlich empfiehlt es sich, Meldungen auf einer virtuellen Konsole zu haben.

Weitere Informationen und ein Beispiel finden sich im Abschnitt "Die Konfigurationsdatei", siehe oben.

3.4.4 Einheitliche Netzwerkzeit

Bei der Analyse von Störungen ist es wichtig, Reihenfolgen und Abstände von Fehlermeldungen oder Fehlermails richtig feststellen zu können. Oft sind Zeitstempel bekannt. Diese sind natürlich Rechner-übergreifend nur verwendbar, wenn auch alle Maschinen die gleiche Vorstellung der Netzwerkzeit haben, deren Uhren also genau gleich bzw. synchron sind. Es empfiehlt sich also (insbesondere, wenn man keinen Loghost verwendet), die Netzwerkzeiten zu synchronisieren. Dazu verwendet man üblicherweise einen NTP (Network Time Protocol) Dienst, beispielsweise xntpd.

3.4.5 Firewall-Konfiguration

Firewalls sollten verhindern, dass UDP/514 Pakete vom Internet in das LAN geroutet werden, um Flut-Angriffen zu entgehen. Selbst wenn man keinen Loghost verwendet, könnte möglicherweise ein interner Host den Empfang von Netzwerk-Meldungen aktiviert haben. Auskunft darüber gibt das Kommando:

Sicherheitshalber sollten Firewalls ohnehin alle nicht benötigten und nicht verwendeten Ports sperren.

Interne Firewalls müssen diese Pakete natürlich zwischen Loghost und den Logsystemen erlauben, aber sollten so eingestellt werden, daß nur die betreffenden IP-Adressen erlaubt sind.

Es ist zu beachten, dass die Absender-Adresse von UDP Paketen sehr einfach fälschbar ist. Demzufolge kann man bei Firewalls diese Adressen nicht zum Filtern verwenden. Man sollte hier an Interfaces blocken. Hat eine Firewall beispielsweise ein externes Interface eth1, sollte eine entsprechende Firewall-Regel den Empfang und Versand von Syslog-Paketen über dieses Interface unterbinden. Wenn die Firewall über eth0 an das interne Netz angebunden ist, kann hier dennoch ein Loghost verwendet werden, der die Firewallmeldungen empfängt.

Bei der Verwendung von Firewalls und Loghosts ist zu beachten, daß normalerweise unerlaubte Pakete geloggt werden, was zu einen hohen Aufkommen an Meldungen führt. Hier sollte Syslog so konfiguriert werden, dass diese Meldungen nicht über das Netzwerk geschrieben werden, wenn sich hier Probleme ergeben (Portscans könnten beispielsweise zu Flut-Verhalten führen).

Häufig sind aber die Außenanbindungen vergleichsweise langsam (beispielsweise E1 (2MBit) extern und 100Mbit intern), so daß hier interne Netzwerküberlastungen eher unwahrscheinlich sind.