Loghost mit journald

Heute möchte ich mal zeigen, wie einfach es ist mithilfe des journald einen zentralen Loghost einzurichten.

Wie auch mit einigen der älteren Log-Daemons, lässt sich mit dem journald ein Log-Host einrichten um alle Meldungen Ihrer Server zentral an einer Stelle zu speichern. Die Übertragung der Daten wird dabei über TLS verschlüsselt, sodass ein Mitlesen mit einem Netzwerksniffer nicht möglich ist.

Für das Beispiel werde ich einen LDAP-Server als Log-Client einrichten, der seine Log-Informationen dann auf den Log-Host speichert. Auf allen Clients und dem Server installieren Sie das Paket systemd-journal-remote.

Achten Sie bei der Einrichtung des Servers darauf, dass Sie ausreichend Festplattenplatz bereitgestellt haben. Je mehr Clients die Logs dort ablegen und je länger Sie die Logs speichern wollen, um so mehr Plattenplatz wird benötigt. Damit der Server, für den Fall, dass der Plattenplatz nicht ausreicht, nicht abstürzt, lagern Sie das Verzeichnis /var auf eine eigene Partition aus. Die Standardgröße einer Log-Datei ist 8 MB, auch wenn noch keine Meldungen im Log eingetragen sind.

Im ersten Schritt aktivieren Sie den Dienst und den dazugehörigen Socket auf dem Server, über den sich die Clients verbinden. Das folgende Listing zeigt die entsprechenden Kommandos:

root@loghost:~# systemctl enable –now systemd-journal-remote.socket
Created symlink /etc/systemd/system/sockets.target.wants/systemd-
journal-remote.socket -> /lib/systemd/system/systemd-journal-remote.socket.
root@loghost:~# systemctl enable systemd-journal-remote.service

Im ersten Kommando wird der Dienst durch die Option –now sofort gestartet. Der zweite Dienst wird erst gestartet wenn Sie das TLS-Zertifikat bereitgestellt haben. Der Port, der hier verwendet wird, ist der Port 19532. Prüfen Sie mit dem Kommando ss, ob der Port geöffnet wurde.

Erstellen Sie ein Zertifikat für den Server, falls noch keins vorhanden ist.

Auf allen Clients, die sich mit dem Log-Host verbinden sollen, aktivieren Sie jetzt auch den systemd-journal-remote.service. Auch auf den Clients wird der Dienst aber noch nicht gestartet.

Einrichten des Servers

Die Konfiguration des Log-Servers finden Sie in der Datei /etc/systemd/journal-remote.conf. In der Datei sind schon bestimmte Vorgaben vorhanden, die aber alle auskommentiert sind. Im folgenden Listing sehen Sie die Datei für unser Beispiel:

[Remote]
# Seal=false
SplitMode=host
ServerKeyFile=/etc/ssl/zertifikate/loghost-key.pem
ServerCertificateFile=/etc/ssl/zertifikate/loghost-cert.pem
TrustedCertificateFile=/etc/ssl/zertifikate/demoCA/cacert.pem

Die Variablen haben die folgenden Bedeutungen:

Seal
Wenn Sie maximale Sicherheit haben wollen, was das Manipulieren der Einträge angeht, können Sie diese Variable aktivieren und auf true setzen. Dann werden die einzelnen Einträge zusätzlich signiert.

SplitMode
Alle Einträge, werden aufgrund des Hostnamen, in eigene Dateien gespeichert. Das verbessert die Übersichtlichkeit der Daten, gerade wenn Sie viele Hosts auf dem Server loggen wollen.

ServerKeyFile
Der Pfad und der der Name des Keyfiles Ihres Zertifikats.

ServerCertificateFile
Der Name und der Pfad zum Zertifikat.

TrustedCertificateFile
Der Name und Pfad zum root-Zertifikat. Ohne diese Angabe das kann die Gültigkeit der Zertifikate nicht geprüft werden.

Damit die Zertifikate auch vom Log-Daemon genutzt werden können, ist es notwendig, dass Sie die Rechte wie im folgenden Listing anpassen:

root@loghost:~# chgrp systemd-journal-remote /etc/ssl/zertifikate/loghost-*
root@loghost:~# chmod 640 /etc/ssl/zertifikate/loghost-*

Sollten Sie das Zertifikat auch noch für andere Dienste benötigen, setzen Sie die erweiterten Dateisystem-ACLs für die Gruppe.

Erst jetzt können Sie den Dienst mit dem Kommando systemctl start systemd-journal-remote.service starten. Danach ist der Log-Host bereit, die Log-Daten der Clients anzunehmen.

Einrichten des Clients

Nachdem der Server im vorherigen Abschnitt eingerichtet wurde, geht es jetzt darum, den ersten Client anzubinden, der seine Log-Daten an den Log-Server schickt.

Für die Übermittlung der Daten wird ein eigener Benutzer benötigt. Legen Sie einen neuen Benutzer an, indem Sie das Kommando aus dem folgenden Listing übernehmen:

root@loghost:~# adduser –system –home /run/systemd –no-create-home \
–disabled-login –group systemd-journal-upload
Lege Systembenutzer »systemd-journal-upload« (UID 107) an …
Lege neue Gruppe »systemd-journal-upload« (GID 113) an …
Lege neuen Benutzer »systemd-journal-upload« (UID 107) mit \
Gruppe »systemd-journal-upload« an …
Erstelle Home-Verzeichnis »/run/systemd« nicht.

Bei dem neuen Benutzer handelt es sich um einen Systembenutzer, der sich nicht lokal anmelden kann. Vergeben Sie auch kein Passwort für den Benutzer.

Sorgen Sie auf dem Client dafür, dass das Zertifikat von der Gruppe systemd-journal-remote gelesen werden kann.

Auch auf dem Client folgt jetzt die Anpassung der Konfiguration, dieses Mal in der Datei /etc/systemd/journal-upload.conf. Auch auf dem Client ist die Datei schon vorhanden, aber alle Optionen sind noch auskommentiert. Im folgenden Listing sehen Sie die an mein Beispiele angepasste Datei:

[Upload]
URL=https://loghost.example.net:19532
ServerKeyFile=/etc/ssl/zertifikate/provider-stat-key.pem
ServerCertificateFile=/etc/ssl/zertifikate/provider-stat-cert.pem
TrustedCertificateFile=/etc/ssl/zertifikate/demoCA/cacert.pem

Im Unterschied zur Konfiguration des Servers, wird hier die URL angegeben, unter der der Server erreichbar ist. Die drei Zeilen für die Zertifikate sind identisch mit denen auf dem Server.

Starten Sie den Log-Daemon jetzt mit dem Kommando systemctl restart systemd-journal-upload.service auf dem Client.

Testen der Log-Umgebung

Wechseln Sie auf den Log-Server, und lassen Sie sich den Inhalt des Verzeichnisses /var/log/journal/remote anzeigen. Dort sehen Sie jetzt eine neue Datei. Ihr Name enthält den vollständigen Namens des Clients, wie er im Zertifikat genannt ist. Einen Eintrag zu meinem Beispiel sehen Sie im folgenden Listing:

root@loghost:~# ls /var/log/journal/remote/
‚remote-C=DE,ST=SH,L=St.\\x20Michel,O=Adminbuch,OU=CA\
,CN=provider-stat.example.net.journal‘

Sollten Sie, so wie im Beispiel, ein Leerzeichen im Namen des Zertifikats haben, dann wird das Leerzeichen durch die Zeichenfolge \x20 ersetzt. Der Backslash muss später, beim einlesen der Datei, zusätzlich mit einem Backslash entwertet werden, auch wenn Sie den Pfad in gerade Hochkommata setzen.

Ist die Datei vorhanden, hat alles geklappt und der Server nimmt Meldungen vom Client entgegen. Sie können jetzt warten, bis der Client eine Nachricht generiert und auf den Server überträgt. Sie können aber auch selber eine Testmeldung mit dem Kommando logger generiert,  so wie im folgenden Listing:

root@provider-stat:~# logger -p syslog.debug „Das ist ein Test vom \\
Client provider-stat“

Auf dem Log-Server können Sie jetzt das Log genau so auswerten, wie ich es in den Abschnitten vorher beschrieben habe, aber mit einen Unterschied, als Quelle geben Sie die Datei des Clients an, den Sie auswerten wollen. In folgenden Listing sehen Sie das Kommando und das Ergebnis der durch logger erzeugten Meldung:

root@loghost:~# journalctl –file=’/var/log/journal/remote/remote-C=DE\
,ST=SH,L=St.\\x20Michel,O=Adminbuch,OU=CA,CN=provider-stat.\
example.net.journal‘

Jan 11 19:48:18 provider-stat root[1081]: Das ist ein Test vom Client\ provider-stat\

So können Sie jetzt alle weiteren Clients einrichten und testen und haben damit eine zentrale Log-Umgebung geschaffen.

This entry was posted in Allgemein and tagged , . Bookmark the permalink.