Kaffeefilter

Samhain überwacht die Dateien des Linuxsystems und schlägt bei einer Veränderung Alarm. Allerdings verändern sich viele Dateien schon im normalen Betrieb. Beispielsweise wachsen die Logdateien beständig, temporäre Dateien entstehen unter »/tmp« und Benutzer verändern bei der täglichen Arbeit die Zeitstempel ihrer Open-Office-Dokumente. Würde Samhain alle diese Fälle melden, gingen die eigentlichen Angriffe gnadenlos im entstehenden Datenwust unter. Man sollte Samhain deshalb schon vor seiner Inbetriebnahme mitteilen, welche Dateien es überwachen soll und welche Aktivitäten es melden soll. Dies geschieht in der Konfigurationsdatei »/etc/samhainrc« . Die mitgelieferte Vorlage sieht auf den ersten Blick etwas wüst aus, bietet aber dennoch eine gute Ausgangsbasis für eigene Ergänzungen.

Ähnlich wie die älteren (Windows-)INI-Dateien besteht sie aus Abschnitten, die jeweils mit einem Namen in eckigen Klammern beginnen. Jede Einstellung folgt dem Schema »Einstellung=Wert« , Zeilen mit einer Raute »#« ignoriert Samhain.

Als erstes legt der Administrator fest, wohin Samhain seine Warnmeldungen sendet. Der Weg dazu führt über die »[Log]« -Sektion, wo jede »...Severity« -Einstellung für eine bestimmte Ausgabemöglichkeit steht: »LogSeverity« speichert beispielsweise die Meldungen in einer Log-Datei, »MailSeverity« versendet sie per E-Mail, »PrintSeverity« spuckt die Informationen auf der Konsole aus und »SyslogSeverity« nutzt das Syslog.

Um eines dieser Nachrichtenziele zu aktivieren, entfernt der Administrator die Raute »#« und bestimmt dann nach dem Gleichheitszeichen, wie dringlich die Meldung mindestens sein muss, um dort zu landen. Gilt beispielsweise

LogSeverity=err

erscheinen später in der Log-Datei nur Fehler, kritische Probleme und Samhains eigener Tod. Tabelle 2 nennt alle zur Verfügung stehenden Dringlichkeitsstufen und ihre jeweiligen Inhalte.

Tabelle 2

Dringlichkeitsstufen (aufsteigend)

Jede Stufe schließt alle unter ihr liegenden ein, »warn« meldet deshalb beispielsweise auch Fehler.

Stufe

Bedeutung

debug

Nur zur Fehlersuche für Programmierer

info

Alle Informationen

notice

Hinweise

warn

Warnungen

mark

Zeitmarken

err

Fehler

crit

Kritische Probleme

alert

Fehler, die Samhain beenden

Wer sich per E-Mail benachrichtigen lassen möchte, muss anschließend noch den entsprechenden »[Misc]« -Abschnitt aufsuchen (Vorsicht: In der Beispielkonfiguration gibt es die Sektion mehrfach) und dort die Daten aus Listing 1 nachtragen.

Listing 1

Einstellungen für den E-Mail-Versand

[Misc]
# Empfänger:
SetMailAdress = name@example.com
# Falls notwendig, Relay:
SetMailRelay = relay.example.com
# Sende in einer Mail immer so viele Meldungen auf einmal:
SetMaiNum = 10
# Max. Zeitspanne (in Sek.) bis zum Versand der Nachrichten:
SetMailTime = 86400
# Betreff-Zeile der verschickten E-Mail:
MailSubject = betreff
Abbildung 1: Configure erzeugt schon beim Übersetzen des Quellcodes einen so genannten Base Key, mit dem es unter anderem die verschickten E-Mails bestückt. Über den Befehl samhain -M /pfad/zur/datei kann man dann die Herkunft der gespeicherten Post prüfen.

Die Log-Datei liegt später standardmäßig unter »/var/log/samhain_log« . Ein anderer Speicherort lässt sich entweder schon Configure über den Parameter »--with-log-file=/pfad/zur/datei« übergeben oder der Sektion »[Misc]« über die folgende Zeile hinzufügen:

SetLogfilePath = /pfad/zur/datei

Politiker

Als nächstes legt der Administrator fest, welche Dateien und Verzeichnisse Samhain auf welche Art beobachtet. Mit den folgenden Zeilen schlägt Samhain beispielsweise Alarm, wenn jemand auf »/meine/datei.txt« , »/wichtiger/ordner« und »/var/logs/a.log« anders als lesend zugreift:

[ReadOnly]
dir=/wichtiger/ordner
file=/meine/datei.txt
file=/var/logs/a.log

Die absoluten Pfade sind übrigens immer Pflicht. Das »[ReadOnly]« teilt Samhain mit, dass sich nur die Zeit des letzten Zugriffs der darunter aufgeführten Dateien ändern darf. Allerdings gibt es noch einen kleinen Fallstrick: Die Log-Datei wächst beständig, das IDS würde also mehrfach falschen Alarm schlagen. Deshalb wandert »a.log« in den speziellen Abschnitt »[GrowingLogFiles]« . Das vollständige Ergebnis zeigt Listing 2.

Listing 2

Konfigurationsdatei (Ausschnitt)

[ReadOnly]
dir=/wichtiger/ordner
file=/meine/datei.txt
[GrowingLogFiles]
file=/var/logs/a.log

»[ReadOnly]« und »[GrowingLogFiles]« bezeichnet Samhain als Policys. Welche das IDS außerdem noch kennt, verrät Tabelle 3.

Tabelle 3

Alle vordefinierten Policys

Policy

Bedeutung

IgnoreNone

Nichts darf sich ändern

ReadOnly

Nur die Zeit des letzten Zugriffs darf sich ändern

LogFiles

Zeitstempel, Prüfsumme und Dateigröße dürfen sich ändern

GrowingLogFiles

Zeitstempel und Prüfsumme dürfen sich ändern, Dateigröße darf wachsen

Attributes

Samhain meldet Änderungen an Eigentümer und Gruppe, sowie Zugriffsrechten

IgnoreAll

Samhain prüft nur die Existenz einer Datei und ignoriert alles andere

Prelink

Wie ReadOnly, aber für Programme und Bibliotheken, die mit »prelink« verändert wurden

Soll Samhain bei einem Verzeichnis nur bis in eine bestimmte Tiefe vordringen, stellt der Administrator diese Zahl dem Pfad voran:

dir=3/wichtiger/ordner

Um einzelne (enthaltene) Unterverzeichnisse auszuschließen, setzt er sie unter die Policy »[IgnoreAll]« mit der Rekursionstiefe »-1« :

[IgnoreAll]
dir=-1/wichtiger/ordner/nicht

Wie die mitgelieferte Beispielkonfigurationsdatei in ihrem oberen Teil zeigt, dürfen einzelne Abschnitte durchaus mehrfach vorkommen. Samhain zieht sie dann bei der Auswertung selbständig wieder zusammen. Die bereits vorgegebenen Verzeichnisse sollte man belassen. Sie legen für die wichtigsten Dateien eines Linux-System einige sinnvolle Grundregeln fest.

Samhain ist äußerst penibel, was die Zugriffsrechte auf seine wichtigsten Dateien angeht – das gilt erst recht für die Konfigurationsdatei. Nur Root und der Benutzer, mit dessen ID Samhain gerade läuft, dürfen Schreibrechte besitzen. Sollen außer den beiden noch weitere Personen an der Konfiguration drehen dürfen, muss der Administrator sie Samhain als "vertrauenswürdige" Benutzer bekanntgeben. Dazu fügt er ihre jeweilige Benutzerkennung (UID) der Configure-Option »--with-trusted=0,<uid>,<uid>...« hinzu. Um gegen Manipulationen geschützt zu sein, sollte man bei den Voreinstellungen bleiben, also nur Root Schreibrechte gewähren und die im Folgenden genannten Befehle als dieser aufrufen.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
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

Google+

Ausgabe /2019