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:
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
:
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:
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:
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:
#
/etc/rc.d/syslogd restart
Fehlerausgabedaten ähnlich der Folgenden werden sofort nach dem Neustart auf dem Bildschirm erscheinen:
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:
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/messagesZu 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.
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>.