Loghost mit journald

Posted on 4. Februar 2021 by Stefan

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.

Posted in Allgemein | Tagged , | Leave a comment

OpenLDAP und Kerberos, es wächst zusammen was zusammen gehört

Posted on 18. Januar 2021 by Stefan

Immer wieder sehe ich  bei Kunden, dass sie zwar einen OpenLDAP-Server einsetzen, den in den meisten Fällen auch via TLS absichern, wenn es um Verbindungen zum und zwischen den OpenLDAP-Server geht, aber in den seltensten Fällen wird zusätzlich Kerberos eingesetzt um die Sicherheit zu erhöhen. Die folgenden Gründe werde dann immer angeführt:

  • Der Aufwand ist zu hoch.
  • Nur ein geringer Sicherheitsgewinn.
  • Die Pflege des Kerberos ist zu aufwendig.
  • Die Schulung der Mitarbeiter ist zu aufwendig.
  • Zu lange Einarbeitungszeiten.

Noch besser sind dann die folgenden Argumente die auch immer mal wieder auftauchen:

  • Wir nutzen doch schon TLS das muss reichen.
  • Hier kommt eh niemand rein.
  • Viel zu kompliziert.

Aber was stimmt denn nun?
Klar, Kerberos ist nicht in einem Tag gelernt, verstanden und implementiert. Die Einführung von Kerberos benötigt eine gute Planung und ausgebildete Administratoren. Aber der Sicherheitsgewinn rechtfertigt die Einführung auf jeden Fall. 

Welchen Mehrwert bietet mir Kerberos in Zusammenarbeit mit OpenLDAP? 
Da sich nicht nur Benutzer authentifizieren müssen, sondern die Authentifizierung auf Dienste und Hosts erweitert wird, steigt die Sicherheit. Denn nur System und Dienste die im Kerberos ein Konto (Principal) besitzen können sich überhaupt gegen den Kerbeors-Server authentifizieren und die Anmeldetickets (TGT) der Benutzer zur Authentifizierung nutzen. Ein weiterer wichtiger Punkt ist der, dass bei der Authentifizierung zu keiner Zeit Passwörter, seien sie verschlüsselt oder gar unverschlüsselt, über das Netzwerk übertragen werden. Der gesamte Authentifizierungsprozess findet über Tokens statt. Auch die Übertragung von Daten kann, wie zum Beispiel bei der Datenübertragung über NFS, mittels Kerberos verschlüsselt werden, so dass die Daten nicht im Netz abgefangen werden können. Auf einen kerbereisierten NFS-Server kann so auch neben der Hostauthentifizierung eine Benutzerauthentifizierung durchgeführt werden. Denn ein Benutzer der keine TGT besitzt, kann auch nicht mehr auf den NFS-Server zugreifen. Die Sicherheit im Netz steigt.
Zusammen mit Kerberos können Sie alle Abfragen an den OpenLDAP-Server mittels strong-bind durchführen und sind nicht mehr auf den simple-bind angewiesen. Der Vorteil dabei liegt ganz klar auf der Hand. Beim simple-bind ist es notwendig die Passwörter, für zum Beispiele die Replikation der OpenLDAP-Server, in Klartext in die Konfgurationsdatei zu schreiben. Bei der Verwendung von strong-bind mittels Kerberos findet die Authentifizierung bei der Replikation über Tickets statt. Der Dienst authentifiziert sich mit seinem Principal und einer verschlüsselten Keytab-Datei. So können keine Passwörter mehr aus der Konfiguration gelesen werden.
Einen ganz großen Vorteil habe ich hier noch gar nicht erwähnt: In einer vollständig kerbereisierten Umgebung geben die Benutzer nur noch einmal, bei der Anmeldung am System, ihr Passwort ein. Alle weiteren Anmeldungen an Hosts oder Services werden, automatisch und im Hintegrund, über Tickets durchgeführt. Sie erhalten eine Singel-sign-on Umgebung.
Das sind nur ein paar der Vorteile die Ihnen Kerberos bietet.

Aber Kerberos ist doch so kompliziert!
Das Verfahren wie die Authentifizierung durchgeführt wird ist schon recht komplex und Sie benötigen schon einige Zeit um die komplette Funktion des Kerberos zu verstehen. Aber muss man da alles verstehen? Verstehen Sie die vollständige Arbeitsweise vom Active Directory (Was im übrigen auch Kerberos nutzt) oder können Sie mir erklären wie die Assistentssysteme Ihres Autos funktionieren? Aber Sie fahren Auto oder :-)?
Gerade wenn Sie Kerberos zusammen mit OpenLDAP nutzen und für die Verwaltung der Objekte dann noch den LDAP Account Manger in der Pro Version einsetzen, dann ist die Verwaltung der LDAP-Umgebung einfach. Klar können Sie OpenLDAP und Kerberos auch komplett ohne grafisches Werkzeug nutzen, aber so ein grafisches Werkzeug erleichtert die Sache manchmal und lässt Ihnen die Möglichkeit Aufgaben der Benutzerverwaltung zu delegieren. Wenn Sie Kerberos zusammen mit OpenLDAP betreiben fällt auch die Replikation der Kerberos-Datenbank weg, denn alle Kerberos-Informationen liegen im LDAP und die Ausfallsicherheit realisieren Sie über die Replikation der LDAP-Server. Die Kerberos-Server verbinden sich alle gegen den LDAP und nutzen den selben Datenbestand.

Wie funktioniert Kerberos?
Das hier komplett zu erklären würde den Rahmen erheblich sprengen, aber trotzdem möchte ich das ganze mal versuchen recht einfach zu erklären:
Jeder Teilnehmer an der Authentifizierung über Kerberos benötigt einen Prinicipal mit einem Credential (Passwort) in der Datenbank. Bei Benutzern ist es das Passwort, das der Benutzer bei der Anmeldung angeben muss,  Hosts und Services könne schlecht selber ein Passwort eingeben, sie bekommen eine Keytab-Datei mit einem verschlüsselten Passwort. So können sich alle  Teilnehmer gegen den Kerberos-Server authentifizieren. Ein Benutzer der sich Angemeldet hat, erhält vom Kerberos-Server ein Ticket (TGT). Dieses Ticket hat nur eine begrenze Gültigkeit. Wenn der Benutzer jetzt auf einen Dienst eines anderen Server zugreifen möchte, wird der Service, der sich ja auch gegen den Kerberos authentifiziert hat, das Ticket anfordern. Im Hintergrund wird das TGT an den Service übertragen, da der Service dem Kerberos-Server vertraut und das TGT vom Kerberos-Server ausgestellt wurde, vertraut der Service dem TGT und fragt nicht mehr den Kerberos-Server. Nach der erfolgreichen Anmeldung übermittelt der Service eine Service-Ticket an den Client des Benutzers. Das Ticket wird dort gespeichert und bei einem weiteren Zugriff überträgt der Client das Service-Ticket, da das Service-Ticket vom Kerberos-Server erstellt wurde, vertraut der Client dem Service-Ticket. 
Klar, der gesamte Prozess ist etwas komplizierter (wie ihr ABS im Auto) aber um die Funktion annähernd zu erklären, denke ich, reicht es aus.

Fazit:
Keine Angst vor Kerberos

Posted in LDAP | Leave a comment

Jetzt auch mit Videokonferenz

Posted on 17. Dezember 2020 by Stefan

Ab sofort kann ich Schulungen und Consulting auch via Videokonferenz anbieten. Dank mailbox.org geschieht das ganze DSGVO-konform und ohne zusätzliche Software, einfach über einen Browser. Verwendet wird dort die opensource Lösung jitsi. Bis zu 9 Teilnehmern sind möglich. Alle meine Themen können durchgeführt werden. Für bis zu vier Teilnehmern kann ich auch die Schulungsumgebung einrichten und via SSH bereitstellen.

Posted in Allgemein | Leave a comment

Kurze Einführung in Business Intelligence von checkmk

Posted on 2. Dezember 2020 by Stefan

Heute geht es mal um ein ganz anderes Thema, um checkmk. Wer bereits checkmk einsetzt wird vielleicht schon mal über das WATO-Modul Business Intelligence (BI) gestolpert sein. Für die, die sich noch nie mit dem Thema auseinandergesetzt haben, soll dieses kleine Beispiel sein.

Mit BI können Sie zusammenhängende Dienste in Abhängigkeit bringen und das Gesamtergebnis darstellen.

Stellen Sie sich vor, Sie betreiben eine Webseite die über mehrer Webserver bereitgestellt wird, zusätzlich kommen noch mehrere Datenbank-Server im Cluster dazu. Jede einzelne Komponente, sprich Sever, kann bei einem Ausfall die Bereitstellung der Webseite nicht unterbrechen. Alle Dienste sind redundant ausgelegt. Fällt also einer von drei Webserver und zusätzlich noch einer von drei Datenbankserver aus, kann der Service „Webseite“ immer noch bereitgestellt werden. Diese Abhängigkeiten können mit BI abgebildet werden. In dem kleinen Beispiel (die Anleitung finden Sie hier) sehen Sie, wie Sie die Internetverbindung Ihres Unternehmens mit BI darstellen können und wie Sie die Darstellung auch dafür nutzen können beim Ausfall des Internets eine Meldung zu erzeugen.

In der aktuellen Version gibt es zwar eine einfachere Lösung der Überprüfung des Internets, aber darum solle es hier nicht gehen. Dieser Artikel soll Ihnen BI an Hand eines kleine Beispiels näherbringen.

Viele Spaß beim Ausprobieren

Posted in checkmk | Leave a comment

OpenLDAP delta-syncrepl mit Ansible

Posted on 29. November 2020 by Stefan

Im ersten Teil habe ich die Einrichtung von OpenLDAP-Servern mit einfacher Replikation beschrieben. Hier geht es jetzt um die Replikation mit delta-syncrepl. Die komplette Einrichtung aller Server wird via Ansible durchgeführt. Die Konfiguration der OpenLDAP-Server wird im Backend cn=config erstellt. Im Gegensatz zur Konfiguration über die slpad.conf ist es hier wichtig die richtige Reihenfolge der Overlays und Datenbanken einzuhalten. HIER finden Sie die Rollen für Ansible. Die Anleitung liegt in den entsprechenden REDME-Dateien. 

Posted in Ansible | Leave a comment

Samba DC und Ansible

Posted on 22. Oktober 2020 by Stefan

Nachdem ich im vorherigen Beitrag OpenLDAP mit Ansible eingerichtet habe, ist dieses Mal Samba dran. Auch hier ist es so, dass ich zu Testzwecken häufig eine Domäne einrichte und mir das ganze durch die Automatisierung mit Ansible etwas einfacher machen wollte. Ziel war es, mehrere DCs einzurichten, ohne ein Kommando eingeben zu müssen. Auch wollte ich keine zwei Rollen erstellen, eine für das Provisioning des ersten DCs und eine für das Join der nachfolgenden DCs. Ich wollte alles in einer Rolle vereinen. Das ganze hat etwas gedauert, aber jetzt läuft es. Jetzt ist es so, dass auf Grund der Gruppe im Inventory entschieden wird ob es sich bei der Installation um den Ersten oder einen weiteren DC handelt. 

Eine genau Beschreibung der Rolle steht im README der Rolle. Alle Variablen sind (hoffe ich doch) gut beschrieben und auch die Tasks selber sind alle dokumentiert. Mit ein paar Vorkenntnissen an Ansible sollte es kein Problem geben die DCs zu installieren.

Posted in Ansible | Leave a comment

Using Ansible to set up an OpenLDAP environment

Posted on 20. August 2020 by Stefan

Because I need an OpenLDAP environment for testing purposes I wrote three Ansible-roles to create an environment with three OpenLDAP-servers, one provider and two consumers.
Everything you need are three Debian-VMs with ssh-rootlogin with password. This will  be revoked at the end of the first script, after setting up a sudo-user.
The name of the first role is setup_server, this role will do the first equal steps on all servers:

  • All the needed packages will be installed
  • An ansible user will be created on all servers
  • The public-key from ansible-user on the control-host will be copied to all servers
  • Setting up sudo with no-password for the ansible-user
  • The certificate for all servers will be copied to all servers, depending on the hostname (see README.md)
  • Some ACLs will be set
  • Setting the loglevel 

After the first run the root-login via ssh with password is no longer possible. 

The second role setup_provider will do the following tasks:

  • Loading the sycprov-modul and configure it
  • Create a user for replication with read-permission to all objects and all attributes
  • Create a user with write-permission to all object and all attributes this user will be used to manage the objects
     

The third role will setup the two consumers:

  • Configuring the replication 

You can download all roles here.

Posted in Ansible | Leave a comment

Tutorial SambaXP 2020

Posted on 31. Mai 2020 by Stefan

This year everything was different, due to corona the SambaXP was planned as a online conference. Also my tutorial on the first day of the conference was an online-event. So I had to find a way for my participants to set up the virtual machines to follow my tutorial. So I created a Vagrant-box and a install-script to setup one Samba4 Domaincontroller two Linux-machines for the cluster and one Linux-client. So everyone could set up the machines before the tutorial starts. Here you find all files to setup the environment. The vm are Debian 10 with kernel 5.4, Samba 4.12 from Louis van Belle and GlusterFS 7.x. You will also find the handout in English in the file.

Nachtrag:
Die Videos zu meinem Tutorial können auf der Seite sambaxp.org heruntergeladen werden

Posted in Samba | Leave a comment

Ubuntu 20.04 PXE-Installation mit NFS-Server

Posted on 26. April 2020 by Stefan

Gerade habe ich mir mal die neue Ubuntu-Version 20.04 angesehen und wollte testen, wie sich die neue Version über PXE booten und installieren lässt. Das Einrichten der PXE-Umgebung ging wie gewohnt. Ein DHCP-Server, ein TFTP-Server und ein NFS-Server waren schnell aufgesetzt. Nach der Einrichtung eine VM über das Netz gebootet, der DHCP-Server vergibt auch eine IP-Adresse. Sowohl im Log des DHCP-Servers als auch beim Bootprozess des neuen Systems wird die vergeben IP-Adresse angezeigt. Die initrd und der Kernel werden gefunden und das System bootet. Aber dann ging es los, der NFS-Server konnte nicht gefunden werden. Ich habe dann nochmal alles geprüft. Der NFS-Server lief und ich konnte auch, von einem anderen System, die Freigabe mounten. Also nochmal starten, aber der Fehler blieb, keine Verbindung zum NFS-Server.

Ich habe dann mal das Timeout abgewartet, bis der Prompt des Systems erreichbar war. Ein „ip a“ meinte „Ich habe gar keine IP-Adresse“. HÄÄÄÄÄ, DHCP hat doch eindeutig einen IP an das System vergeben? Dann mal etwas gesucht im Netz und tatsächlich habe ich was gefunden. Ein Bugreport der genau das anspricht, zum Glück gab es auch eine Lösung. Einfach and die „APPEND“-Zeil den Parameter „ip=dhcp“ anhängen. Siehe da, während des Ladens des Kernels wurde erneut eine IP-Adresse angefordert und jetzt auch der Netzwerkkarte zugewiesen. Jetzt wird der NFS-Server gefunden und die Installation startet wie gewohnt.

Posted in Allgemein | Leave a comment

Hurra, das neue Buch ist da

Posted on 15. April 2020 by Stefan

Im Mai ist es endlich soweit, das neue Buch zum Thema openLDAP erscheint im Hanser-Verlag. Nach gut neun Monaten Arbeit haben Andreas und ich es zusammen mit dem Verlag geschafft und das Projekt abgeschlossen. Eigentlich war geplant das Buch auf der SLAC in Berlin vorzustellen, aber da hat uns leider Corona einen Strich durch die Rechnung gemacht. Aber trotzdem freuen wir uns, dass das Buch so schnell fertig geworden ist. Wie immer, Anregungen und ein sinnvolles Feedback sind immer gerne gelesen. 

Posted in Allgemein | Leave a comment