Die Aufzeichnung und Kontrolle von Log-Meldungen ist ein wichtiger Aspekt der Systemadministration. Die Informationen werden nicht nur verwendet um Hard- und Softwarefehler ausfindig zu machen, auch zur Überwachung der Sicherheit und der Reaktion bei einem Zwischenfall spielen diese Aufzeichnungen eine wichtige Rolle. Die meisten Systemdienste und Anwendungen erzeugen Log-Meldungen.
FreeBSD stellt mit syslogd ein
Werkzeug zur Verwaltung von Protokollen bereit. In der
Voreinstellung wird syslogd beim
Booten automatisch gestartet. Dieses Verhalten wird über die
Variable syslogd_enable
in
/etc/rc.conf
gesteuert. Dazu gibt es noch
zahlreiche Argumente, die in der Variable
syslogd_flags
in
/etc/rc.conf
gesetzt werden können. Lesen
Sie syslogd(8) für weitere Informationen über die
verfügbaren Argumente.
Dieser Abschnitt beschreibt die Konfiguration und Verwendung des FreeBSD Protokollservers, und diskutiert auch die Log-Rotation und das Management von Logdateien.
Die Konfigurationsdatei
/etc/syslog.conf
steuert, was
syslogd mit Log-Meldungen macht,
sobald sie empfangen werden. Es gibt verschiedene Parameter,
die das Verhalten bei eingehenden Ereignissen kontrollieren.
facility beschreibt das
Subsystem, welches das Ereignis generiert hat. Beispielsweise
der Kernel, oder ein Daemon.
level hingegen beschreibt den
Schweregrad des aufgetretenen Ereignisses. Dies macht es
möglich, Meldungen in verschiedenen Logdateien zu
protokollieren, oder Meldungen zu verwerfen, je nach
Konfiguration von facility und
level. Ebenfalls besteht die
Möglichkeit auf Meldungen zu reagieren, die von einer
bestimmten Anwendung stammen, oder von einem
spezifischen Host erzeugt wurden.
Die Konfigurationsdatei von syslogd(8) enthält für
jede Aktion eine Zeile. Die Syntax besteht aus einem
Auswahlfeld, gefolgt von einem Aktionsfeld. Die Syntax für
das Auswahlfeld ist facility.level
.
Dies entspricht Log-Meldungen von
facility
mit einem Level von
level
oder höher. Um noch präziser
festzulegen was protokolliert wird, kann dem Level optional
ein Vergleichsflag vorangestellt werden. Mehrere Auswahlen
können, durch Semikolon (;
) getrennt, für
die gleiche Aktion verwendet werden. *
wählt dabei alles aus. Das Aktionsfeld definiert, wohin die
Log-Meldungen gesendet werden, beispielsweise in eine Datei
oder zu einem entfernten Log-Server. Als Beispiel dient hier
/etc/syslog.conf
aus FreeBSD:
# $FreeBSD$
#
# Spaces ARE valid field separators in this file. However,
# other *nix-like systems still insist on using tabs as field
# separators. If you are sharing this file between systems, you$
# may want to use only tabs as field separators here.
# Consult the syslog.conf(5) manpage.
*.err;kern.warning;auth.notice;mail.crit /dev/console
*.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err /var/log/messages
security.* /var/log/security
auth.info;authpriv.info /var/log/auth.log
mail.info /var/log/maillog
lpr.info /var/log/lpd-errs
ftp.info /var/log/xferlog
cron.* /var/log/cron
!-devd
*.=debug /var/log/debug.log
*.emerg *
# uncomment this to log all writes to /dev/console to /var/log/console.log
#console.info /var/log/console.log
# uncomment this to enable logging of all log messages to /var/log/all.log
# touch /var/log/all.log and chmod it to mode 600 before it will work
#*.* /var/log/all.log
# uncomment this to enable logging to a remote loghost named loghost
#*.* @loghost
# uncomment these if you're running inn
# news.crit /var/log/news/news.crit
# news.err /var/log/news/news.err
# news.notice /var/log/news/news.notice
# Uncomment this if you wish to see messages produced by devd
# !devd
# *.>=info
!ppp
*.* /var/log/ppp.log
!*
In diesem Beispiel:
Zeile 8 selektiert alle Meldungen vom Level
err
, sowie
kern.warning
,
auth.notice
und
mail.crit
und schickt diese zur Konsole
(/dev/console
).
Zeile 12 selektiert alle Meldungen von
mail
ab dem Level
info
oder höher und schreibt diese in
/var/log/maillog
.
Zeile 17 benutzt ein Vergleichsflag
(=
), um nur Meldungen vom Level
debug
zu selektieren und schreibt
diese in /var/log/debug.log
.
Zeile 33 zeigt ein Beispiel für die Nutzung einer
Programmspezifikation. Die
nachfolgenden Regeln sind dann nur für Programme gültig,
welche der Programmspezifikation stehen. In diesem Fall
werden alle Meldungen von ppp
(und keinem anderen Programm) in
/var/log/ppp.log
geschrieben.
Die verfügbaren level,
beginnend mit den höchst kritischen, hin zu den weniger
kritischen, sind:
emerg
, alert
,
crit
, err
,
warning
, notice
,
info
und
debug
.
Die facilities, in
beliebiger Reihenfolge, sind: auth
,
authpriv
, console
,
cron
, daemon
,
ftp
, kern
,
lpr
, mail
,
mark
, news
,
security
, syslog
,
user
, uucp
, sowie
local0
bis local7
.
Beachten Sie, dass andere Betriebssysteme hiervon abweichende
facilities haben
können.
Um alle Meldungen vom Level notice
und
höher in /var/log/daemon.log
zu
protokollieren, fügen Sie folgenden Eintrag hinzu:
daemon.notice /var/log/daemon.log
Für weitere Informationen zu verschiedenen Level und
faclilities, lesen Sie
syslog(3) und syslogd(8). Weitere Informationen
zu /etc/syslog.conf
, dessen Syntax und
erweiterten Anwendungsbeispielen, finden Sie in
syslog.conf(5).
Logdateien können schnell wachsen und viel Speicherplatz belegen, was es schwieriger macht, nützliche Informationen zu finden. Log-Management versucht, diesen Effekt zu mildern. FreeBSD verwendet newsyslog für die Verwaltung von Logdateien. Dieses in FreeBSD integrierte Programm rotiert und komprimiert in regelmäßigen Abständen Logdateien. Optional kann es auch fehlende Logdateien erstellen und Programme benachrichtigen, wenn Logdateien verschoben wurden. Die Logdateien können von syslogd oder einem anderen Programm generiert werden. Obwohl newsyslog normalerweise von cron(8) aufgerufen wird, ist es kein Systemdämon. In der Standardkonfiguration wird dieser Job jede Stunde ausgeführt.
Um zu wissen, welche Maßnahmen zu ergreifen sind, liest
newsyslog seine Konfigurationsdatei
/etc/newsyslog.conf
. Diese
Konfigurationsdatei enthält eine Zeile für jede Datei, die von
newsyslog verwaltet wird. Jede
Zeile enthält Informationen über den Besitzer der Datei, die
Dateiberechtigungen, wann die Datei rotiert wird, optionale
Flags, welche die Log-Rotation
beeinflussen (bspw. Komprimierung) und Programme, denen ein
Signal geschickt wird, wenn Logdateien rotiert werden. Hier
folgt die Standardkonfiguration in FreeBSD:
# configuration file for newsyslog
# $FreeBSD$
#
# Entries which do not specify the '/pid_file' field will cause the
# syslogd process to be signalled when that log file is rotated. This
# action is only appropriate for log files which are written to by the
# syslogd process (ie, files listed in /etc/syslog.conf). If there
# is no process which needs to be signalled when a given log file is
# rotated, then the entry for that file should include the 'N' flag.
#
# The 'flags' field is one or more of the letters: BCDGJNUXZ or a '-'.
#
# Note: some sites will want to select more restrictive protections than the
# defaults. In particular, it may be desirable to switch many of the 644
# entries to 640 or 600. For example, some sites will consider the
# contents of maillog, messages, and lpd-errs to be confidential. In the
# future, these defaults may change to more conservative ones.
#
# logfilename [owner:group] mode count size when flags [/pid_file] [sig_num]
/var/log/all.log 600 7 * @T00 J
/var/log/amd.log 644 7 100 * J
/var/log/auth.log 600 7 100 @0101T JC
/var/log/console.log 600 5 100 * J
/var/log/cron 600 3 100 * JC
/var/log/daily.log 640 7 * @T00 JN
/var/log/debug.log 600 7 100 * JC
/var/log/kerberos.log 600 7 100 * J
/var/log/lpd-errs 644 7 100 * JC
/var/log/maillog 640 7 * @T00 JC
/var/log/messages 644 5 100 @0101T JC
/var/log/monthly.log 640 12 * $M1D0 JN
/var/log/pflog 600 3 100 * JB /var/run/pflogd.pid
/var/log/ppp.log root:network 640 3 100 * JC
/var/log/devd.log 644 3 100 * JC
/var/log/security 600 10 100 * JC
/var/log/sendmail.st 640 10 * 168 B
/var/log/utx.log 644 3 * @01T05 B
/var/log/weekly.log 640 5 1 $W6D0 JN
/var/log/xferlog 600 7 100 * JC
Jede Zeile beginnt mit dem Namen der Protokolldatei, die
rotiert werden soll, optional gefolgt von Besitzer und Gruppe
für rotierende, als auch für neu erstellte Dateien. Das Feld
mode
definiert die Zugriffsrechte der
Datei. count
gibt an, wie viele rotierte
Dateien aufbewahrt werden sollen. Anhand der
size
- und
when
-Flags
erkennt newsyslog, wann die Datei
rotiert werden muss. Eine Logdatei wird rotiert, wenn ihre
Größe den Wert von size
überschreitet, oder
wenn die Zeit im when
-Feld abgelaufen ist.
Ein *
bedeutet, dass dieses Feld ignoriert
wird. Das flags
-Feld gibt
newsyslog weitere Instruktionen,
zum Beispiel wie eine Datei zu rotieren ist, oder eine Datei
zu erstellen falls diese nicht existiert. Die letzten beiden
Felder sind optional und bestimmen die
PID-Datei und wann die Datei rotiert
wird.
Weitere Informationen zu allen Feldern, gültigen Flags und wie Sie die Rotationszeit angeben können, finden Sie in newsyslog.conf(5). Denken Sie daran, dass newsyslog von cron(8) aufgerufen wird und somit Dateien auch nur dann rotiert, wenn es von cron(8) aufgerufen wird, und nicht häufiger.
Die Überwachung der Protokolldateien kann bei steigender Anzahl von Rechnern sehr unhandlich werden. Eine zentrale Protokollierung kann manche administrativen Belastungen bei der Verwaltung von Protokolldateien reduzieren.
Die Aggregation, Zusammenführung und Rotation von
Protokolldateien kann in FreeBSD mit
syslogd und
newsyslog 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.
Ein Protokollserver ist ein System, welches Protokollinformationen von anderen Hosts akzeptiert. Bevor Sie diesen Server konfigurieren, prüfen Sie folgendes:
Falls eine Firewall zwischen dem Protokollserver und den -Clients steht, muss das Regelwerk der Firewall UDP auf Port 514 sowohl auf Client- als auch auf Serverseite freigegeben werden.
Der syslogd
-Server und alle
Clientrechner müssen gültige Einträge für sowohl
Vorwärts- als auch Umkehr-DNS
besitzen. Falls im Netzwerk kein
DNS-Server vorhanden ist, muss auf
jedem System die Datei /etc/hosts
mit den richtigen Einträgen gepflegt werden. Eine
funktionierende Namensauflösung ist zwingend
erforderlich, ansonsten würde der Server die
Protokollnachrichten ablehnen.
Bearbeiten Sie /etc/syslog.conf
auf
dem Server. Tragen Sie den Namen des Clients ein, den
Verbindungsweg und den Namen der Protokolldatei. Dieses
Beispiel verwendet den Rechnernamen
B
, alle Verbindungswege, und die
Protokolle werden in
/var/log/logclient.log
gespeichert.
Fügen Sie für jeden Client zwei Zeilen hinzu, falls Sie mehrere Clients in diese Datei aufnehmen. Weitere Informationen über die verfügbaren Verbindungswege finden Sie in syslog.conf(5).
Konfigurieren Sie als nächstes
/etc/rc.conf
:
syslogd_enable="YES" syslogd_flags="-a logclient.example.com -v -v"
Der erste Eintrag startet syslogd
während des Bootens. Der zweite Eintrag erlaubt es, Daten
von dem spezifizierten Client auf diesem Server zu
akzeptieren. Die Verwendung von -v -v
erhöht die Anzahl von Protokollnachrichten. Dies ist
hilfreich für die Feineinstellung der Verbindungswege, da
Administratoren auf diese Weise erkennen, welche Arten von
Nachrichten von welchen Verbindungswegen 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. Eine
vollständige Liste der Optionen finden Sie in
syslogd(8).
Zum Schluss muss die Protokolldatei erstellt werden:
#
touch
/var/log/logclient.log
Zu diesem Zeitpunkt sollte syslogd
neu gestartet und überprüft werden:
#
service
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 in
/var/log/messages
nach dem
Fehler.
Ein Protokollclient sendet Protokollinformationen an einen Protokollserver. Zusätzlich behält er eine lokale Kopie seiner eigenen Protokolle.
Sobald der Server konfiguriert ist, bearbeiten Sie
/etc/rc.conf
auf dem Client:
syslogd_enable="YES" syslogd_flags="-s -v -v"
Der erste Eintrag aktiviert den
syslogd
-Dienst während des Systemstarts.
Der zweite Eintrag erhöht die Anzahl der
Protokollnachrichten. Die Option -s
verhindert, dass dieser Client Protokolle von anderen
Hosts akzeptiert.
Als nächstes muss der Protokollserver in der
/etc/syslog.conf
des Clients
eingetragen werden. In diesem Beispiel wird das
@
-Symbol benutzt, um sämtliche
Protokolldaten an einen bestimmten Server zu senden:
*.* @logserv.example.com
Nachdem die Änderungs gespeichert wurden, muss
syslogd
neu gestartet werden, damit die
Änderungen wirksam werden:
#
service 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.
Wenn der Server keine Nachrichten empfängt, ist die
Ursache wahrscheinlich ein Netzwerkproblem, ein Problem bei
der Namensauflösung oder ein Tippfehler in einer
Konfigurationsdatei. Um die Ursache zu isolieren, müssen
Sie sicherstellen, dass sich Server und Client über den in
/etc/rc.conf
konfigurierten Hostnamen
mit ping
erreichen lässt. Falls dies
nicht gelingt sollten Sie die Netzwerkverkabelung
überprüfen, außerdem Firewallregeln sowie die Einträge für
Hosts im DNS und
/etc/hosts
. Überprüfen Sie diese Dinge
auf dem Server und dem Client, bis der
ping
von beiden Hosts erfolgreich
ist.
Wenn sich die Hosts gegenseitig mit
ping
erreichen können, der Server aber
immer noch keine Nachrichten empfängt, können Sie
vorübergehend die Ausführlichkeit der Protokollierung
erhöhen, um die Ursache für das Problem weiter einzugrenzen.
In dem folgenden Beispiel ist auf dem Server die Datei
/var/log/logclient.log
leer und in der
Datei /var/log/messages
auf dem Client
ist keine Ursache für das Problem erkennbar. Um nun die
Ausführlichkeit der Protokollierung zu erhöhen, passen Sie
auf dem Server den Eintrag syslogd_flags
an. Anschließend starten Sie den Dienst neu:
syslogd_flags="-d -a logclient.example.com -v -v"
#
service syslogd restart
Informationen wie diese werden sofort nach dem Neustart auf der Konsole 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.
In diesem Beispiel werden die Nachrichten aufgrund eines
fehlerhaften Namens abgewiesen. Der Hostname sollte
logclient
und nicht
logclien
sein. Beheben Sie den
Tippfehler, starten Sie den Dienst neu und überprüfen Sie
das Ergebnis:
#
service 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 ein Protokollserver eingesetzt 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 Protokolldateien ü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. Es ist
absolut notwendig, die richtigen Berechtigungen auf diesen
Dateien zu setzen. Das Werkzeug
newsyslog unterstützt
das Setzen von Berechtigungen auf gerade erstellte oder
rotierte Protokolldateien. Protokolldateien mit
Zugriffsmodus 600
sollten verhindern,
dass lokale Benutzer darin herumschnüffeln. Zusätzliche
Informationen finden Sie in newsyslog.conf(5).
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>.