Knechtschaft

Damit die Samhain-Installationen die Logs überhaupt an den Server übermitteln können, muss man sie auf den Clients schon entsprechend übersetzen. Dazu dient der Configure-Parameter »--enable-network=client« :

./configure --enable-network=client --with-↩
logserver=server.example.com --with-config-↩
file=REQ_FROM_SERVER --with-data-file=REQ_FROM↩
_SERVER/var/lib/samhain/samhain_file
make

Bitte noch nicht installieren, da gleich noch ein paar Nacharbeiten fällig sind. Die übrigen <Configure-Parameter sorgen nacheinander dafür, dass Samhain zukünftig sowohl seine Konfiguration als auch die Signaturdatenbank vom Server »server.example.com« bezieht. Das »REQ_FROM_SERVER« verweist auf den Log-Server, der Pfad hinter »--with-data-file« bezieht sich auf den lokalen Rechner. Er ist notwendig, da Samhain die Ergebnisse der Initialisierung zunächst in eine (lokale) Datei schreibt – nämlich die oben angegebene.

Schlüsselmeister

Damit niemand die übertragenen Informationen und Signaturen stört, verwenden Client und Server eine gesicherte Verbindung. Um diese aufzubauen, muss sich Samhain bei Yule authentifizieren. Dazu braucht das Programm ein Passwort, das der folgende Befehl auf dem Server generiert ( Abbildung 3 ):

yule -G
Abbildung 3: Hier hat Yule zunächst den Schlüssel 2D1993AF832288D07 erzeugt und anschließend daraus den schwarz eingefärbten Eintrag für seine Konfigurationsdatei generiert.

Mit der ausgespuckten Zeichenkette geht der Administrator wieder zum Client und bettet sie dort in das Samhain-Programm ein:

./samhain_setpwd samhain new <passwort>

Das Hilfsprogramm »samhain_setpwd« wurde zusammen mit Samhain erstellt. Es tauscht das von Samhain generierte Passwort gegen das neue aus. Dabei verändert »samhain_setpwd« das existierende Binärprogramm »samhain« und legt das Ergebnis unter dem Namen »samhain.new« ab. Diese Datei kopiert der Administrator über die alte Version:

mv samhain.new samhain

Erst jetzt ist endlich die IDS-Installation auf dem Client möglich:

sudo make install

und dann die Signatur-Datenbank aufbauen:

samhain -t init

Die dabei erstellte Datei (nach den bisherigen Beispielen »/var/lib/samhain/samhain_file« ) muss der Administrator anschließend per Hand auf dem Server in das Verzeichnis »/var/lib/yule« kopieren und ihr einen Namen der Form »file.<rechnername>« geben. Läuft Samhain beispielsweise auf dem Rechner »client.example.com« , erhält die Signatur-Datenbank den Namen »file.client.example.com« .

Um das Passwort des Clients überprüfen zu können, muss Yule es kennen. Dazu dient auf dem Server der folgende Befehl:

yule -P <passwort>

Hierbei erzeugt Yule eine ziemlich lange, kryptische Zeichenkette mit allen zur Authentifizierung notwendigen Informationen der Form (in Abbildung 3 die schwarz markierte Zeile):

Client=HOSTNAME@123456789123456@123456789ABC...

Diese Zeile hängt der Admin nun in der Konfigurationsdatei »yulerc« unter die letzte Sektion »[Clients]« und ersetzt in einem letzten Schritt die Zeichenkette »HOSTNAME« gegen den Rechnernamen des entsprechenden Clients, wie etwa:

[Clients]
Client=client.example.com@123456789123456↩
@123456789ABC...

Alle diese Schritte wiederholt der Administrator nun für alle anderen Clients, die ihre Daten an Yule schicken sollen. Am Ende muss in der »yulerc« unter »[Clients]« für jeden Samhain-Client ein Eintrag bestehen. Anschließend startet er Yule als Daemon im Hintergrund:

yule -D

Alternativ aktiviert auch hier »make install-boot« Yule beim Systemstart. Eigene Fehlermeldungen protokolliert Yule standardmäßig unter »/var/log/yule/yule_log« . Zusätzlich generiert der Server im gleichen Verzeichnis die HTML-Datei »yule.html« , die er standardmäßig alle 120 Sekunden aktualisiert. Sie liefert einen Statusbericht der jeweils gerade angeschlossenen Clients.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023