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.
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.
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.
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.
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
<[email protected]>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an <[email protected]>.