Protokolle zentralisieren mit Journald unter Debian 10

Der Autor wählte den Free and Open Source Fund, um eine Spende im Rahmen des Programms Write for DOnations zu erhalten.

Einführung

Systemprotokolle sind ein äußerst wichtiger Bestandteil für die Verwaltung von Linux-Systemen. Sie bieten einen unschätzbaren Einblick in die Funktionsweise und Verwendung der Systeme, da sie neben Fehlern auch Betriebsinformationen wie Sicherheitsereignisse aufzeichnen. Die Standardkonfiguration für Linux-Systeme besteht darin, ihre Protokolle lokal auf demselben System zu speichern, auf dem sie aufgetreten sind. Dies funktioniert für eigenständige Systeme, wird jedoch mit zunehmender Anzahl von Systemen schnell zu einem Problem. Die Lösung für die Verwaltung all dieser Protokolle besteht darin, einen zentralen Protokollierungsserver zu erstellen, auf dem jeder Linux-Host seine Protokolle in Echtzeit an einen dedizierten Protokollverwaltungsserver sendet.

Eine zentralisierte Protokollierungslösung bietet im Vergleich zum Speichern von Protokollen auf jedem Host mehrere Vorteile:

• Reduziert den Speicherplatz, der auf jedem Host zum Speichern von Protokolldateien benötigt wird.
• Protokolle können länger aufbewahrt werden, da der dedizierte Protokollserver mit mehr Speicherkapazität konfiguriert werden kann.
• Es kann eine erweiterte Protokollanalyse durchgeführt werden, die Protokolle von mehreren Systemen und mehr Rechenressourcen erfordert, als auf den Hosts verfügbar sind.
• Systemadministratoren können auf die Protokolle aller ihrer Systeme zugreifen, bei denen sie sich aus Sicherheitsgründen möglicherweise nicht direkt anmelden können.

In diesem Leitfaden konfigurieren Sie eine Komponente der Tool-Suite systemd, um Protokollnachrichten von Client-Systemen an einen zentralen Protokollsammlungsserver weiterzuleiten. Sie konfigurieren den Server und den Client so, dass TLS-Zertifikate verwendet werden, um die Protokollnachrichten zu verschlüsseln, wenn sie über unsichere Netzwerke wie das Internet übertragen werden, und um sich gegenseitig zu authentifizieren.

Voraussetzungen

Bevor Sie diese Anleitung beginnen, benötigen Sie Folgendes:

• Zwei Debian 10-Server.
• Einen Nicht-root-Benutzer mit Sudo-Berechtigungen auf beiden Servern. Anweisungen dazu finden Sie im Leitfaden Ersteinrichtung des Servers mit Debian 10. Sie sollten auch die UFW-Firewall auf beiden Servern konfigurieren, wie im Leitfaden erläutert.
• Zwei Hostnamen, die auf Ihre Server verweisen. Ein Hostname für das Client-System, das die Protokolle generiert, und ein anderer für den Protokollsammlungsserver. In der Domains- und DNS-Dokumentation erfahren Sie, wie Sie Hostnamen auf DigitalOcean Droplets verweisen.

In diesem Leitfaden werden die folgenden zwei Beispiel-Hostnamen verwendet:

• client.your_domain: Das Client-System, das die Protokolle generiert.
• server.your_domain: Der Protokollsammlungsserver.

Melden Sie sich sowohl beim Client als auch beim Server in separaten Terminals über SSH als Nicht-root-sudo-Benutzer an, um dieses Tutorial zu starten.

Schritt 1 — Installieren von systemd-journal-remote

In diesem Schritt installieren Sie das Paket systemd-journal-remote auf dem Client und dem Server. Dieses Paket enthält die Komponenten, die der Client und der Server zum Weiterleiten von Protokollnachrichten verwenden.

Führen Sie zunächst sowohl auf dem Client als auch auf dem Server ein Systemupdate aus, um sicherzustellen, dass die Paketdatenbank und das System aktuell sind:

sudo apt update
sudo apt upgrade

Installieren Sie das Paket systemd-journal-remote:

sudo apt install systemd-journal-remote

Aktivieren und starten Sie auf dem Server die beiden systemd-Komponenten, die zum Empfangen von Protokollnachrichten benötigt werden, mit dem folgenden Befehl:

sudo systemctl enable --now systemd-journal-remote.socket
sudo systemctl enable systemd-journal-remote.service

Die Option --now im ersten Befehl startet die Dienste sofort. Sie haben es im zweiten Befehl nicht verwendet, da dieser Dienst erst gestartet wird, wenn er über TLS-Zertifikate verfügt, die Sie im nächsten Schritt erstellen.

Aktivieren Sie auf dem Client die Komponente, mit der systemd die Protokollnachrichten an den Server sendet:

sudo systemctl enable systemd-journal-upload.service

Öffnen Sie anschließend auf dem Server die Ports 19532 und 80 in der UFW-Firewall. Dadurch kann der Server die Protokollnachrichten vom Client empfangen. Port 80 ist der Port, über den Certbot das TLS-Zertifikat generiert. Die folgenden Befehle öffnen diese Ports:

sudo ufw allow in 19532/tcp
sudo ufw allow in 80/tcp

Auf dem Client müssen Sie Port 80 nur mit diesem Befehl öffnen:

sudo ufw allow in 80/tcp

Sie haben jetzt die erforderlichen Komponenten installiert und die Basissystemkonfiguration auf dem Client und dem Server abgeschlossen. Bevor Sie diese Komponenten so konfigurieren können, dass sie mit der Weiterleitung von Protokollnachrichten beginnen, registrieren Sie die Let’s Encrypt TLS-Zertifikate für den Client und den Server mithilfe des Dienstprogramms certbot.

Schritt 2 — Installieren von Certbot und Registrieren von Zertifikaten

Let’s Encrypt ist eine Zertifizierungsstelle, die kostenlose TLS-Zertifikate ausstellt. Mit diesen Zertifikaten können Computer sowohl die zwischen ihnen gesendeten Daten verschlüsseln als auch die Identität des anderen überprüfen. Mit diesen Zertifikaten können Sie Ihr Surfen im Internet mit HTTPS sichern. Dieselben Zertifikate können von jeder anderen Anwendung verwendet werden, die dieselbe Sicherheitsstufe wünscht. Der Prozess der Registrierung des Zertifikats ist der gleiche, unabhängig davon, wofür Sie es verwenden.

In diesem Schritt installieren Sie das Dienstprogramm certbot und registrieren damit die Zertifikate. Außerdem wird es automatisch darum kümmern, die Zertifikate zu erneuern, wenn sie ablaufen. Der Registrierungsvorgang ist hier der gleiche auf dem Client und dem Server. Sie müssen nur den Hostnamen ändern, um ihn an den Host anzupassen, auf dem Sie den Registrierungsbefehl ausführen.

Installieren Sie zunächst certbot und das Dienstprogramm curl auf beiden Hosts:

sudo apt install certbot curl

Nachdem Sie certbot installiert haben, führen Sie den folgenden Befehl aus, um die Zertifikate auf dem Client und Server zu registrieren:

sudo certbot certonly --standalone --agree-tos --email sammy@your_domain -d your_domain

Die Optionen in diesem Befehl bedeuten Folgendes:

• certonly: Registrieren Sie das Zertifikat und führen Sie keine anderen Änderungen am System vor.
• --standalone: Verwenden Sie den integrierten Webserver von certbot zur Verifizierung der Zertifikatsanforderung.
• --agree-tos: Stimmen Sie automatisch den Nutzungsbedingungen von Let’s Encrypt zu.
• --email your-email: Dies ist die E-Mail-Adresse, mit der Let’s Encrypt Sie über den Ablauf des Zertifikats und andere wichtige Informationen benachrichtigt.
• -d your_domain: Der Hostname, für den das Zertifikat registriert wird. Dies muss dem System entsprechen, in dem Sie es ausführen.

Wenn Sie diesen Befehl ausführen, werden Sie gefragt, ob Sie die E-Mail-Adresse mit Let’s Encrypt teilen möchten, damit diese Ihnen Nachrichten und andere Informationen zu ihrer Arbeit per E-Mail senden können. Dies ist optional. Wenn Sie Ihre E-Mail-Adresse nicht teilen, wird die Zertifikatsregistrierung weiterhin normal abgeschlossen.

Wenn der Zertifikatregistrierungsprozess abgeschlossen ist, werden die Zertifikat- und Schlüsseldateien in /etc/letsencrypt/live/your_domain/ abgelegt, wobei your_domain der Hostname ist, für den Sie das Zertifikat registriert haben.

Schließlich müssen Sie eine Kopie der Let’s Encrypt-Zertifizierungsstelle und der Zwischenzertifikate herunterladen und in dieselbe Datei einfügen. journald verwendet diese Datei, um die Authentizität der Zertifikate auf dem Client und dem Server zu überprüfen, wenn sie miteinander kommunizieren.

Mit dem folgenden Befehl werden die beiden Zertifikate von der Let’s Encrypt-Website heruntergeladen und in einer einzigen Datei mit dem Namen letsencrypt-combined-certs.pem im Home-Verzeichnis Ihres Benutzers abgelegt.

Führen Sie diesen Befehl auf dem Client und dem Server aus, um die Zertifikate herunterzuladen und die kombinierte Datei zu erstellen:

curl -s https://letsencrypt.org/certs/{isrgrootx1.pem.txt,letsencryptauthorityx3.pem.txt} > ~/letsencrypt-combined-certs.pem

Verschieben Sie als Nächstes diese Datei in das Verzeichnis Let’s Encrypt, das die Zertifikate und Schlüssel enthält:

sudo cp ~/letsencrypt-combined-certs.pem /etc/letsencrypt/live/your_domain/

Sie haben nun die Zertifikate und Schlüssel registriert. Im nächsten Schritt konfigurieren Sie den Protokollsammlungsserver so, dass er Protokollnachrichten vom Client abhört und speichert.

Schritt 3 — Konfigurieren des Servers

In diesem Schritt konfigurieren Sie den Server so, dass er die im letzten Schritt generierten Zertifikat- und Schlüsseldateien verwendet, damit er Protokollnachrichten vom Client akzeptieren kann.

systemd-journal-remote ist die Komponente, die auf Protokollnachrichten wartet. Öffnen Sie ihre Konfigurationsdatei unter /etc/systemd/journal-remote.conf mit einem Texteditor, um die Konfiguration auf dem Server zu starten:

sudo nano /etc/systemd/journal-remote.conf

Entfernen Sie anschließend die Kommentare in allen Zeilen im Abschnitt [Remote] und legen Sie die Pfade so fest, dass sie auf die soeben erstellten TLS-Dateien verweisen:

[Remote]
Seal=false
SplitMode=host
ServerKeyFile=/etc/letsencrypt/live/server.your_domain/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/server.your_domain/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/server.your_domain/letsencrypt-combined-certs.pem

Hier sind die Optionen, die Sie hier verwendet haben:

• Seal=false: Melden Sie die Protokolldaten im Journal an. Aktivieren Sie diese Option, wenn Sie maximale Sicherheit benötigen; andernfalls können Sie es als false belassen.
• SplitMode=host: Die Protokolle der Remoteclients werden nach Host in /var/log/journal/remote geteilt. Wenn Sie möchten, dass alle Protokolle einer einzelnen Datei hinzugefügt werden, setzen Sie dies auf SplitMode=false.
• ServerKeyFile: Die private Schlüsseldatei des Servers.
• ServerCertificateFile: Die Zertifikatdatei des Servers.
• TrustedCertificateFile: Die Datei mit den Let’s Encrypt CA-Zertifikaten.

Jetzt müssen Sie die Berechtigungen für die Let’s Encrypt-Verzeichnisse ändern, die die Zertifikate und den Schlüssel enthalten, damit die systemd-journal-remote sie lesen und verwenden kann.

Ändern Sie zunächst die Berechtigungen so, dass das Zertifikat und der private Schlüssel lesbar sind:

sudo chmod 0755 /etc/letsencrypt/{live,archive}
sudo chmod 0640 /etc/letsencrypt/live/server.your_domain/privkey.pem

Ändern Sie als Nächstes das Gruppeneigentum des privaten Schlüssels in die Gruppe von systemd-journal-remote:

sudo chgrp systemd-journal-remote /etc/letsencrypt/live/server.your_domain/privkey.pem

Jetzt können Sie systemd-journal-remote starten:

sudo systemctl start systemd-journal-remote.service

Ihr Protokollsammlungsserver wird jetzt ausgeführt und ist bereit, Protokollnachrichten von einem Client zu akzeptieren. Im nächsten Schritt konfigurieren Sie den Client so, dass die Protokolle an Ihren Sammlungsserver weitergeleitet werden.

Schritt 4 — Konfigurieren des Clients

In diesem Schritt konfigurieren Sie die Komponente, die die Protokollnachrichten an den Protokollsammlungsserver weiterleitet. Diese Komponente wird systemd-journal-upload genannt.

Die Standardkonfiguration für systemd-journal-upload ist, dass ein temporärer Benutzer verwendet wird, der nur vorhanden ist, während der Prozess ausgeführt wird. Dies erschwert das Lesen der TLS-Zertifikate und -Schlüssel durch systemd-journal-upload. Um dies zu beheben, erstellen Sie einen neuen Systembenutzer mit demselben Namen wie der temporäre Benutzer, der an seiner Stelle verwendet wird.

Erstellen Sie zunächst den neuen Benutzer mit dem Namen systemd-journal-upload auf dem Client mit dem folgenden adduser-Befehl:

sudo adduser --system --home /run/systemd --no-create-home --disabled-login --group systemd-journal-upload

Diese Optionen für den Befehl lauten:

• --system: Erstellen Sie den neuen Benutzer als Systembenutzer. Dadurch wird dem Benutzer eine UID-Nummer (Benutzerkennung) unter 1000 gegeben. UIDs über 1000 werden normalerweise an Benutzerkonten vergeben, mit denen sich ein Mensch anmeldet.
• --home/run/systemd: Legen Sie /run/systemd als Home-Verzeichnis für diesen Benutzer fest.
• --no-create-home: Erstellen Sie das Home-Verzeichnis nicht, da es bereits vorhanden ist.
• --disabled-login: Der Benutzer kann sich beispielsweise nicht über SSH beim Server anmelden.
• --group: Erstellen Sie eine Gruppe mit demselben Namen wie der Benutzer.

Legen Sie als Nächstes die Berechtigungen und den Besitz der Let’s Encrypt-Zertifikatdateien fest:

sudo chmod 0755 /etc/letsencrypt/{live,archive}
sudo chmod 0640 /etc/letsencrypt/live/client.your_domain/privkey.pem
sudo chgrp systemd-journal-upload /etc/letsencrypt/live/client.your_domain/privkey.pem

Bearbeiten Sie nun die Konfiguration für systemd-journal-upload unter /etc/systemd/journal-upload.conf. Öffnen Sie diese Datei mit einem Texteditor:

sudo nano /etc/systemd/journal-upload.conf

Bearbeiten Sie diese Datei, damit sie wie folgt aussieht:

[Upload]
URL=https://server.your_domain:19532
ServerKeyFile=/etc/letsencrypt/live/client.your_domain/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/client.your_domain/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/client.your_domain/letsencrypt-combined-certs.pem

Starten Sie abschließend den systemd-journal-upload-Dienst neu, damit er die neue Konfiguration verwendet:

sudo systemctl restart systemd-journal-upload.service

Ihr Client ist jetzt eingerichtet und wird ausgeführt und sendet seine Protokollnachrichten an den Protokollsammlungsserver. Im nächsten Schritt überprüfen Sie, ob die Protokolle korrekt gesendet und aufgezeichnet werden.

Schritt 5 — Testen des Clients und des Servers

In diesem Schritt testen Sie, ob der Client Protokollnachrichten an den Server weiterleitet und ob der Server sie korrekt speichert.

Der Protokollsammlungsserver speichert die Protokolle von den Clients in einem Verzeichnis unter /var/log/journal/remote/. Wenn Sie den Client am Ende des letzten Schritts neu gestartet haben, wurden Protokollnachrichten gesendet, sodass sich jetzt eine Protokolldatei in /var/log/journal/remote/ befindet. Die Datei wird nach dem Hostnamen, den Sie für das TLS-Zertifikat verwenden, benannt.

Verwenden Sie den Befehl Is, um zu überprüfen, ob die Protokolldatei des Clients auf dem Server vorhanden ist:

sudo ls -la /var/log/journal/remote/

Dadurch wird der Verzeichnisinhalt mit der Protokolldatei gedruckt:

Output
total 16620
drwxr-xr-x  2 systemd-journal-remote systemd-journal-remote     4096 Jun 30 16:17  .
drwxr-sr-x+ 4 root                   systemd-journal            4096 Jun 30 15:55  ..
-rw-r-----  1 systemd-journal-remote systemd-journal-remote 8388608 Jul  1 10:46 'remote-CN=client.your_domain'

Schreiben Sie als Nächstes eine Protokollnachricht auf den Client, um zu überprüfen, ob der Server die Nachrichten des Clients wie erwartet empfängt. Mit dem Dienstprogramm logger erstellen Sie eine benutzerdefinierte Protokollnachricht auf dem Client. Wenn alles funktioniert, leitet systemd-journal-upload diese Nachricht an den Server weiter.

Führen Sie auf dem Client den folgenden logger-Befehl aus:

sudo logger -p syslog.debug "### TEST MESSAGE from client.your_domain ###"

-p syslog.debug in diesem Befehl legt Funktion und Schweregrad der Nachricht fest. Wenn man dies auf syslog.debug setzt, wird deutlich, dass es sich um eine Testnachricht handelt. Dieser Befehl zeichnet die Nachricht ### TEST MESSAGE from client.your_domain ### im Journal des Clients auf, das dann vom systemd-journal-upload an den** Server** weitergeleitet wird.

Lesen Sie als Nächstes die Journaldatei des Clients auf dem Server, um zu überprüfen, ob die Protokollnachrichten vom Client eingehen. Diese Datei ist eine binäre Protokolldatei, sodass Sie sie mit Tools wie less nicht lesen können. Lesen Sie die Datei stattdessen mit journalctl mit der Option --file =, mit der Sie eine benutzerdefinierte Journaldatei angeben können:

sudo journalctl --file=/var/log/journal/remote/remote-CN=client.your_domain.journal

Die Protokollnachricht wird wie folgt angezeigt:

Test log message
. . .
Jun 29 13:10:09 client root[3576]: ### TEST MESSAGE from client.your_domain ###

Ihr Protokollzentralisierungsserver sammelt jetzt erfolgreich Protokolle von Ihrem Client-System.

Zusammenfassung

In diesem Artikel haben Sie einen zentralen Protokollsammlungsserver eingerichtet und einen Client so konfiguriert, dass eine Kopie seiner Systemprotokolle an den Server weitergeleitet wird. Mit den hier verwendeten Client-Konfigurationsschritten können Sie so viele Clients konfigurieren, wie Sie zum Weiterleiten von Nachrichten an den Protokollsammlungsserver benötigen.