Das FreeBSD-Handbuch
Zurück | Kapitel 30. Netzwerkserver | Weiter

# 30.11. Protokollierung von anderen Hosts mittels `syslogd`

Beigetragen von Tom Rhodes. Übersetzt von Benedict Reuschling.

Die Interaktion mit Systemprotokollen ist ein wichtiger Aspekt, sowohl was Sicherheit als auch Systemadministration anbelangt. Überwachen der Protokolldateien von mehreren Hosts kann sehr unhandlich werden, wenn diese Hosts über mittlere oder grosse Netze verteilt sind oder wenn sie Teile von unterschiedlichen Netzwerken sind. In diesen Fällen macht die Konfiguration der Protokollierung von anderen Hosts diesen Prozess wesentlich komfortabler.

Die zentralisierte Protokollierung auf einen bestimmten Protokollierungshost kann manche der administrativen Belastungen der Protokolldateiadministration reduzieren. Protokolldateiaggregation, -zusammenführung und -rotation kann an einer zentralen Stelle mit den FreeBSD-eigenen Werkzeugen wie syslogd(8) und newsyslog(8) konfiguriert werden. In der folgenden Beispielkonfiguration sammelt Host `A`, genannt `logserv.example.com`, Protokollinformationen für das lokale Netzwerk. Host `B`, genannt `logclient.example.com` wird seine Protokollinformationen an den Server weiterleiten. In realen Konfigurationen benötigen beide Hosts passende Vorwärts- und Umkehr-Einträge im DNS oder in `/etc/hosts`. Andernfalls werden die Daten vom Server abgelehnt.

## 30.11.1. Konfiguration des Protokollierungs-Servers

Protokollierungs-Server sind Maschinen, die konfiguriert sind, Protokollinformationen von anderen Hosts zu akzeptieren. In den meisten Fällen wird dies zur Vereinfachung der Konfiguration eingesetzt, in anderen Fällen ist es einfach nur ein Schritt in eine bessere Verwaltung. Was auch immer die Gründe sind, ein paar Anforderungen müssen vorher erfüllt sein.

Ein richtig konfigurierter Protokollierungs-Server muss minimal die folgenden Anforderungen erfüllen:

- Das Regelwerk der Firewall muss UDP auf Port 514 sowohl auf Client- als auch auf Serverseite erlauben;

- syslogd wurde so konfiguriert, dass es Nachrichten von anderen Clientrechnern akzeptiert;

- Der syslogd-Server und alle Clientrechner müssen gültige Einträge für sowohl Vorwärts- als auch Umkehr-DNS besitzen, oder in `/etc/hosts` korrekt eingetragen sein.

Um den Protokollierungs-Server zu konfigurieren, muss der Client in `/etc/syslog.conf` eingetragen sein und der Verbindungsweg der Protokollierung muss spezifiziert sein:

    +logclient.example.com
    *.*     /var/log/logclient.log

> Anmerkung: Weitere Informationen zu den verschiedenen unterstützten und verfügbaren Verbindungswegen finden sich in der Manualpage syslog.conf(5).

Einmal hinzugefügt, werden alle Nachrichten über den `Verbindungsweg` in die zuvor angegebene Datei, `/var/log/logclient.log` protokolliert.

Der Server benötigt ausserdem die folgenden Zeilen in der `/etc/rc.conf`:

    syslogd_enable="YES"
    syslogd_flags="-a logclient.example.com -v -v"

Die erste Option aktiviert den `syslogd`-Dienst während des Systemstarts und die zweite Option erlaubt es, Daten von dem spezifizierten Client auf diesem Server zu akzeptieren. Die Verwendung von `-v -v` im letzten Teil erhöht die Anzahl von Protokollnachrichten. Dies ist sehr hilfreich für die Feineinstellung der Verbindungspfade, da Administratoren auf diese Weise erkennen, welche Arten von Nachrichten unter welchen Einstellungen protokolliert werden.

Mehrere `-a`-Optionen können angegeben werden, um die Protokollierung von mehreren Clients zu erlauben. IP-Adressen und ganze Netzblöcke können ebenfalls spezifiziert werden. Lesen Sie dazu die syslog(3)-Manualpage, um eine vollständige Liste von möglichen Optionen zu erhalten.

Zum Schluss muss noch die Protokolldatei erstellt werden. Auf welche Weise dies geschieht ist nicht wichtig, aber in den meisten Fällen funktioniert touch(1) grossartig, wie hier dargestellt:

    # touch /var/log/logclient.log

Zu diesem Zeitpunkt sollte der `syslogd`-Dienst neu gestartet und überprüft werden:

    # /etc/rc.d/syslogd restart
    # pgrep syslog

Wenn eine PID zurückgegeben wird, wurde der Server erfolgreich neu gestartet und die Clientkonfiguration kann beginnen. Wenn der Server nicht neu gestartet wurde, suchen Sie im `/var/log/messages`-Protokoll nach eventuellen Fehlermeldungen.

## 30.11.2. Konfiguration des Protokollierungs-Clients

Ein Protokollierungs-Client ist eine Maschine, die Protokollinformationen an einen Protokollierungs-Server sendet, zusätzlich zu ihren lokalen Kopien.

Ähnlich wie Protokollierungs-Server müssen Clients auch ein paar minimale Anforderungen erfüllen:

- syslogd(8) muss so konfiguriert sein, dass es Nachrichten eines bestimmten Typs an einen Protokollierungs-Server schickt, welcher diese akzeptieren muss;

- Die Firewall muss UDP-Pakete durch Port 514 erlauben;

- Sowohl Vorwärts- als auch Umkehr-DNS muss konfiguriert sein oder es müssen passende Einträge in `/etc/hosts` vorhanden sein.

Die Clientkonfiguration ist ein bisschen entspannter, verglichen mit der des Servers. Der Clientrechner muss ebenfalls die folgenden Einträge in der `/etc/rc.conf` besitzen:

    syslogd_enable="YES"
    syslogd_flags="-s -v -v"

Wie zuvor aktivieren diese Einträge den `syslogd`-Dienst während des Systemstarts und erhöhen die Anzahl der Protokollnachrichten. Die Option `-s` verhindert, dass dieser Client Protokolle von anderen Hosts akzeptiert.

Verbindungspfade beschreiben den Systemteil, für den eine Nachricht generiert wird. Beispielsweise sind ftp und ipfw beides Verbindungspfade. Wenn Protokollnachrichten für diese beiden Dienste generiert werden, sind diese beiden Werkzeuge normalerweise in jeder Protokollnachricht enthalten. Verbindungspfade sind mit einer Priorität oder Stufe verbunden, die dazu verwendet wird, zu markieren, wie wichtig eine Nachricht im Protokoll ist. Die Häftigste ist `warning` und `info`. Bitte lesen Sie die syslog(3) Manualpage, um eine komplette Liste der verfügbaren Verbindungspfade und Prioritäten zu erhalten.

Der Protokollierungs-Server muss in der `/etc/syslog.conf` des Clients eingetragen sein. In diesem Beispiel wird das `@`-Symbol benutzt, um Protokolldaten an einen anderen Server zu senden. Der Eintrag sieht wie folgt aus:

    *.*               @logserv.example.com

Einmal hinzugefügt, muss `syslogd` neu gestartet werden, damit diese Änderungen wirksam werden:

    # /etc/rc.d/syslogd restart

Um zu testen, ob Protokollnachrichten über das Netzwerk gesendet werden, kann logger(1) auf dem Client benutzt werden, um eine Nachricht an `syslogd` zu schicken:

    # logger "Test message from logclient"

Diese Nachricht sollte jetzt sowohl in `/var/log/messages` auf dem Client, als auch in `/var/log/logclient.log` auf dem Server vorhanden sein.

## 30.11.3. Fehlerbehebung beim Protokollierungs-Server

In bestimmten Fällen ist die Fehlerbehebung notwendig, wenn Nachrichten nicht auf dem Protokollierungs-Server empfangen werden. Es gibt mehrere Gründe dafür, jedoch treten am häufigsten Probleme bei der Netzwerkverbindung und beim DNS auf. Um diese Fälle zu überprüfen, stellen Sie sicher, dass beide Hosts in der Lage sind, sich gegenseitig über den Hostnamen zu erreichen, der in `/etc/rc.conf` angegeben ist. Wenn das funktioniert, ist möglicherweise eine Änderung der `syslogd_flags`-Option in `/etc/rc.conf` notwendig.

Im folgenden Beispiel ist `/var/log/logclient.log` leer und die `/var/log/messages`-Dateien enthalten keine Gründe für den Fehler. Um die Fehlerausgabe zu erhöhen, ändern Sie die `syslogd_flags`-Option so, dass diese wie in dem folgenden Beispiel aussieht und initiieren Sie dann einen Neustart:

    syslogd_flags="-d -a logclien.example.com -v -v"

    # /etc/rc.d/syslogd restart

Fehlerausgabedaten ähnlich der Folgenden werden sofort nach dem Neustart auf dem Bildschirm erscheinen:

    logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart
    syslogd: restarted
    logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel
    Logging to FILE /var/log/messages
    syslogd: kernel boot file is /boot/kernel/kernel
    cvthname(192.168.1.10)
    validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com;
    rejected in rule 0 due to name mismatch.

Es scheint klar zu sein, dass die Nachrichten aufgrund eines fehlerhaften Namens abgewiesen werden. Nach genauer Untersuchung der Konfiguration, kommt ein Tippfehler in der folgenden Zeile der `/etc/rc.conf` als Fehler in Betracht:

    syslogd_flags="-d -a logclien.example.com -v -v"

Die Zeile sollte `logclient` und nicht `logclien` enthalten. Nachdem die entsprechenden Veränderungen gemacht wurden, ist ein Neustart fällig, mit den entsprechenden Ergebnissen:

    # /etc/rc.d/syslogd restart
    logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart
    syslogd: restarted
    logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel
    syslogd: kernel boot file is /boot/kernel/kernel
    logmsg: pri 166, flags 17, from logserv.example.com,
    msg Dec 10 20:55:02 <syslog.err> logserv.example.com syslogd: exiting on signal 2
    cvthname(192.168.1.10)
    validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com;
    accepted in rule 0.
    logmsg: pri 15, flags 0, from logclient.example.com, msg Dec 11 02:01:28 trhodes: Test message 2
    Logging to FILE /var/log/logclient.log
    Logging to FILE /var/log/messages

Zu diesem Zeitpunkt werden die Nachrichten korrekt empfangen und in die richtige Datei geschrieben.

## 30.11.4. Sicherheitsbedenken

Wie mit jedem Netzwerkdienst, müssen Sicherheitsanforderungen in Betracht gezogen werden, bevor diese Konfiguration umgesetzt wird. Manchmal enthalten Protokolldateien sensitive Daten über aktivierte Dienste auf dem lokalen Rechner, Benutzerkonten und Konfigurationsdaten. Daten, die vom Client an den Server geschickt werden, sind weder verschlüsselt noch mit einem Passwort geschützt. Wenn ein Bedarf für Verschlüsselung besteht, ist es möglich, `security/stunnel` zu verwenden, welches die Daten über einen verschlüsselten Tunnel versendet.

Lokale Sicherheit ist ebenfalls ein Thema. Protokolldateien sind während der Verwendung oder nach ihrer Rotation nicht verschlüsselt. Lokale Benutzer versuchen vielleicht, auf diese Dateien zuzugreifen, um zusätzliche Einsichten in die Systemkonfiguration zu erlangen. In diesen Fällen ist es absolut notwendig, die richtigen Berechtigungen auf diesen Dateien zu setzen. Das newsyslog(8)-Werkzeug unterstützt das Setzen von Berechtigungen auf gerade erstellte oder rotierte Protokolldateien. Protokolldateien mit Zugriffsmodus `600` sollten verhindern, dass lokale Benutzer darin herumschnüffeln.

Zurück | Zum Anfang | Weiter
Die Uhrzeit mit NTP synchronisieren | Nach oben | Firewalls

Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an <de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an <de-bsd-translators@de.FreeBSD.org>.