Stiller Wächter

Einbrüche erkennen mit dem IDS Tripwire

Intrusion-Detection-Systeme erkennen Angriffe auf Rechner und Netzwerke, indem Sie den Netzwerkverkehr überwachen und dabei Angriffsmuster und Anomalien erkennen oder womöglich unerwünschte Änderungen auf zu schützenden Rechnern feststellen. Funktionieren sie wie gedacht, alarmieren sie bei Attacken den für das System verantwortlichen Administrator zeitnah. So lassen sich die mit dem Angriff einhergehenden Schäden zumindest eindämmen oder sogar verhindern.

Für das freie Betriebssystem gibt es zahlreiche Intrusion-Detection-Systeme (IDS), entweder für ganze Netzwerke (netzwerkbasiertes IDS, NIDS) oder einzelne Hosts (hostbasiertes IDS, HIDS). In die erstere Kategorie fallen Snort, Suricata und Prelude, die im Idealfall Angriffe auf gesamte Netzwerke erkennen. Zur Kategorie der HIDS zählen Anwendungen wie PortsEntry, Logcheck, Samhain, OSSEC und nicht zuletzt Tripwire [1], um das es in diesem Artikel geht.

Bei Tripwire ("Stolperdraht") handelt es sich um einen Datei-Integritätschecker. Das System wurde 1992 von Gene Kim und Dr. Eugene Spafford an der Purdue-Universität [2] in West Lafayette (USA, Indiana) entwickelt. Seit 1999 entwickelt das Unternehmen Tripwire Inc. [3] die Anwendung als Tripwire Enterprise weiter. Das Tripwire Open Source Projekt wurde 2002 ins Leben gerufen und nutzte als Grundlage die Tripwire-Quelltexte aus dem Jahr 2000. Es eignet sich laut Tripwire Inc. für eine kleine Anzahl von Servern, für die man auf zentralisierte Administration und Berichtsfunktionen verzichten kann.

Funktionsweise

Man kann davon ausgehen, dass Angreifer das attackierte System mit Trojanern, Backdoors und veränderten Dateien kontaminieren, um jederzeit zurückkehren und den zur Strecke gebrachten Server in ihre Machenschaften involvieren zu können. Dem wirkt Tripwire entgegen, indem es Informationen (Prüfsummen, Dateigröße, Mtime, Ctime, Inode etc.) wichtiger Verzeichnisse und Dateien verschlüsselt in einer Datenbank ablegt. So kann es später die Eigenschaften der zu überwachenden Dateien mit den gespeicherten Informationen vergleichen und Abweichungen dem verantwortlichen Administrator melden. Im Idealfall ist alles in Ordnung und der Bericht fällt kurz und knapp aus. Etwas längere Berichte gibt es, wenn Dateien gewollt oder ungewollt geändert wurden – dann muss der Admin handeln.

Das Prinzip hat den Vorteil, dass man den Vergleich diskret periodisch oder bei Verdacht eines Einbruchs ausführen kann. Das IDS beansprucht so kaum Systemressourcen, da es nicht permanent im Hintergrund läuft und so meist auch nicht als laufender Prozess auffällt. Fehlalarme treten relativ selten auf: In der Regel wissen Administratoren, dass Tripwire ihre Server überwacht, und können so schnell dessen Datenbanken aktualisieren beziehungsweise sehen, ob sie selbst für eine gemeldete Änderung verantwortlich sind.

Der Nachteil dieser Vorgehensweise: Das System kann nicht vorab vor einem gerade stattfindenden Angriff warnen. Sobald Tripwire eine Meldung über eine unberechtigten Änderung an einen Administrator versendet, darf dieser getrost von einem gelungenem Angriff ausgehen, sich mental auf einen harten Arbeitseinsatz vorbereiten, eine Standleitung Kaffee ordern, in die Hände spucken und eine Konsole öffnen.

Installation

In den Repositories der gängigen Distributionen findet sich eine recht aktuelle Version des Open-Source-Zweigs von Tripwire, sodass Sie das System in aller Regel bequem über den Paketmanager installieren. Das Programm erfüllt seine Aufgaben bereits sehr gut, sodass die Entwickler nicht permanent neue Versionen nachlegen. Aktuell ist die Version 2.4.2.2, die Sie gegebenenfalls mit dem klassischen Dreischritt aus den Quellen [4] übersetzen.

Während der Installation legt Tripwire einen Site- und einen Local-Key an. Den ersteren benutzt es, um die Konfigurations- und Policy-Dateien zu signieren. Der Local-Key dient der Absicherung der Tripwire-Datenbank. Wurde die Schlüsselgenerierung bei der Installation aus irgendeinem Grund ausgelassen, lässt sie sich mit den Befehlen aus Listing 1 nachholen (Abbildung 1). Für die Passphrase gilt das gleiche wie für gute Passwörter: Mehr als acht Zeichen, Groß- und Kleinschreibung sowie Sonderzeichen erhöhen die Sicherheit.

Listing 1

twadmin --generate-keys --site-keyfile /etc/tripwire//site.key
twadmin --generate-keys --local-keyfile /etc/tripwire/$HOSTNAME-local.key
Abbildung 1

Abbildung 1: Der Site-Key und der Local-Key schützen Konfigurationsdateien und die Tripwire-Datenbank.

Eventuell müssen Sie auch noch die Datei /etc/tripwire/twcfg.txt anpassen. Dort hinterlegen Sie die Pfade zu den Schlüsseldateien, den Richtlinien, der Datenbank und den Berichten. Über weitere Variablen legen Sie den Standard-Editor (EDITOR) fest und geben an, ob Tripwire so lange wie möglich wartet, bis es eine Passworteingabe vom Nutzer verlangt (LATEPROMPTING). Auch Doppelmeldungen (Datei, Verzeichnis) bei Veränderungen einer überwachten Datei lassen sich hier unterbinden (LOOSEDIRECTORYCHECKING).

Da Tripwire auf entfernten Servern oft via Cronjob startet, kann es sinnvoll sein, auch Mails zu versenden, wenn alles in Ordnung ist (MAILNOVIOLATIONS=true). Bleibt dann eine Mail aus, darf der Admin schon einmal in Alarmstellung gehen. Die Reportlevel geben an, wie umfangreich Berichte ausfallen sollen (siehe Tabelle "Reportlevel"). Weiterhin könnten Art (SMTP oder Sendmail) und die für den Mailversand nötigen Server Aufmerksamkeit verlangen.

Reportlevel

Level Beschreibung
0 Zusammenfassung auf einer Zeile. Listet Anzahl der Änderungen, Hinzufügungen und Löschungen auf.
1 Parsbare Liste aller Verletzungen.
2 Zusammenfassung, Auflistung der Verletzungen nach Sektion im Polfile und Regelname.
3 Standardlevel, zeigt erwartete und erkannte Eigenschaften für überwachte Objekte, die geändert wurden.
4 Kompletter Bericht, der bis ins kleinste Detail geht.

Stolperdrähte spannen

Sind die Keys vorhanden und die Konfigurationsdatei im Klartext angepasst, dann geht es daran, die Stolperdrähte in Form von Policies auf dem Server aufzuspannen. In Tripwires Konfigurationsverzeichnis /etc/tripwire/ befindet sich mit hoher Wahrscheinlichkeit bereits eine kommentierte Datei twpol.txt mit Standard-Richtlinien: die Policy-Datei ("Polfile"). Da jedes System anders ist, können Sie nicht davon ausgehen, dass diese den Schutz bietet, den der individuelle Server benötigt. Die Datei dient vielmehr als gute Ausgangsbasis für eigene Anpassungen.

Die Policy-Datei ist recht übersichtlich aufgebaut. Es gibt einige Schlüsselwörter, sogenannte Direktiven, denen jeweils ein @@ vorangeht (siehe Tabelle "Direktiven"). Mit diesen Direktiven unterteilen Sie die Richtlinien in Bereiche mit spezifischen Bedingungen und individuellen Meldungen.

Direktiven

Direktive Beschreibung
@@section leitet Bereich im Polfile ein, OS-abhängig
@@ifhost Fallunterscheidungen, falls ein Polfile auf verschiedenen Hosts eingesetzt wird
@@else dito
@@endif dito
@@print gibt folgenden String auf der Standardausgabe aus
@@error gibt folgenden String auf der Fehlerausgabe aus
@@end Ende Polfile, alle folgenden Einträge werden ignoriert

Regeln im Polfile beginnen mit dem zu überwachendem Objekt (einer Datei oder einem Verzeichnis), gefolgt von ->, den zu überwachenden Eigenschaften ("Properties") und optionalen, in Klammern gesetzten Regelattributen. Häufig benötigte Properties haben die Entwickler bereits in einigen Variablen zusammengefasst. Daneben dürfen Sie eigene Variablen definieren, die Sie innerhalb der Datei mit $(Variable) aufrufen. Eine Regel erstreckt sich meist über eine Zeile und endet mit einem Semikolon. Regeln lassen sich zudem zu Gruppen zusammenfassen, wodurch sie sich später leichter verwalten lassen.

Tripwire kann zahlreiche Kriterien einer Datei im Blick behalten. Dazu gehören unter anderem Atime und Mtime, die von einem Objekt belegten Blöcke, die ID der Festplatte, die Inode-Nummer, die Dateigröße, UID und GID sowie die Rechte. Ferner lässt sich über die Properties das Hash-Verfahren auswählen. Einen Überblick über die wichtigsten Properties und die oben erwähnten vordefinierten Variablen gibt die Tabelle "Eigenschaften".

Eigenschaften

Property Beschreibung
a Atime
b vom Objekt belegte Blöcke
c Erstellungs- oder Modifizierungszeit des Inodes
d Device-ID
f Flags (betriebssystemabhängig)
g Group-ID des Besitzers
i Inode-Nummer
l wachsende Datei
m Mtime
n Anzahl der Links
p Dateirechte
s Dateigröße
u User-ID des Besitzers
A ACL-Einstellungen
C CRC-32-Prüfsumme
G Inode-Generation-Number
H HAVAL-Hash
M MD5-Hash
S SHA-Hash
Vordefinierte Variablen
ReadOnly entspricht +pinugsmdbfCMAG
Dynamic entspricht +pinugdfAG
Growing entspricht +pinugdlfAG
IgnoreAll prüft nur, ob ein Objekt existiert
IgnoreNone prüft alle Properties
Device entspricht +pugsdrfA

Die Regelattribute erlauben, die Regeln mit berichtsfreundlichen Namen zu versehen, die Schärfe einer Regel einzustellen, eine E-Mail-Adresse und ein auszuführendes Kommando für den Fall eines Angriffs anzugeben oder Wildcard-Muster für zu berücksichtigende Dateitypen festzulegen. Darüber hinaus können Sie die Tiefe der Rekursion anzugeben, mit der Tripwire die Inhalte eines Verzeichnisses berücksichtigt (siehe Tabelle "Regelattribute").

Regelattribute

Attribut Beschreibung
rulename Vergibt einen Namen für eine Regel, in der Vorgabe das letzte Element des Objektnamens.
severity Schärfe als Wert von 0 bis 1 000 000. Geben Sie die Severity bei der Integritätscheck an, prüft Tripwire nur Regeln ab diesem Level.
emailto E-Mail-Adresse des Administrators.
recurse Rekursionstiefe für Verzeichnisse. Mögliche Werte: True, False und Zahlen von -1 bis 1 000 000.
onviolation Führt bei Unstimmigkeiten das angegebene Kommando aus.
match Wildcard-Muster für Dateitypen, welche die Integritätsprüfung berücksichtigt.

anhand der E-Mail-Adressen informiert Tripwire bei einem Angriff gegebenenfalls verschiedene Verantwortliche, beispielsweise Webmaster bei geänderten PHP-Dateien und den Systemadministrator bei Auffälligkeiten in Verzeichnissen wie /etc oder /sbin. Dabei dürfen Sie mehrere Adressen durch Kommas getrennt angeben. Mit dem ausführenden Kommando (onviolation) lassen sich beispielsweise Dienste sicherheitshalber stoppen. Bei der Rekursion wirken -1 und True identisch: In beiden Fällen berücksichtigt Tripwire den gesamten Inhalt eines Verzeichnisses. Bei 0 oder False dagegen prüft es nur den Inode des Verzeichnisses. Eine 1 würde bedeuten, dass Tripwire auch die in einem Verzeichnis enthaltenen Dateien auf ihre Integrität prüft, aber die Inhalte in Unterverzeichnissen fallen bereits hinten runter.

Um eine besondere Art von Regeln handelt es sich bei den Stop-Points, die Sie in der Form !Objekt; definieren. Dabei handelt es sich um Verzeichnisse oder Dateien, die Tripwire nicht prüfen soll. Mit Stop-Points lassen sich auch innerhalb eines zu prüfenden Verzeichnisses Ausnahmen festlegen.

Jeder Server bedarf individueller Schutzmaßnahmen, sodass Sie das Policy-File für jeden Rechner entsprechend anpassen müssen. Die Default-Policy-Datei bietet immerhin bereits einen Mindestschutz, der sich auf die Verzeichnisse /boot, /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin, /usr/lib, /usr/local/lib und /etc erstreckt.

Listing 2 zeigt eine Erweiterung mit Regeln, die den Schutz auf 64-Bit-Bibliotheken und eine Nginx-Installation im Verzeichnis /opt ausweiten. Die Regel für die 64-Bit-Libraries zeigt auch, wie sich mehrere Objekte gruppieren lassen. Über die hinterlegten E-Mail-Adressen erhalten die Verantwortlichen mehr oder weniger erfreuliche Mails.

Listing 2

(
  rulename = "64 Bit Libs",
  severity = 100,
  emailto = "falko@mail.de";"chef@mail.de"
)
{
  /lib64 -> $(ReadOnly) ;
  /usr/lib64 -> $(ReadOnly) ;
}
/opt/nginx -> $(ReadOnly) (rulename = "Nginx", severity = 100, emailto = "falko@mail.de") ;

Haben Sie die Konfigurations- und Policy-Dateien erstellt, gilt es diese zu verschlüsseln, bevor Sie die Tripwire-Datenbank initialisieren können. Das erledigen Sie auf der Kommandozeile mit den Befehlen aus Listing 3. Anschließend liegen beide Dateien in einer Form vor, in der sie nicht mehr ohne weiteres lesbar sind. Die Klartext-Dateien sollten Sie entfernen, nachdem Sie die Tripwire-Datenbank erfolgreich angelegt haben. Falls Sie später einmal einen Blick darauf werfen möchten, genügt dazu der Befehl twadmin --print-polfile beziehungsweise twadmin --print-cfg-file.

Listing 3

twadmin --create-cfgfile --cfgfile tw.cfg --site-keyfile site.key twcfg.txt
twadmin --create-polfile --polfile tw.pol --cfgfile tw.cfg --site-keyfile site.key twpol.txt

Die Tripwire-Datenbank legen Sie mit dem Befehl tripwire --init. Sie findet sich anschließend standardmäßig als Datei mit der Endung .twd im Verzeichnis /var/lib/tripwire/ wieder. Eventuell meldet Tripwire beim Anlegen ein paar Fehler, weil die Policy-Datei ungültige Einträge enthält, wie etwa nicht vorhandene Dateien. In dem Fall passen Sie die Policy-Datei an und generiert sie neu, bis Tripwire die Datenbank ohne Gemecker erstellt.

Prüfen und berichten

Bevor Sie Tripwire jetzt munter in einen Cronjob verpacken und auf möglichst wenig unangenehme Post vom IDS hoffen, sollten Sie erst einmal testen, ob Tripwire anstandslos E-Mails versendet. Dazu rufen Sie es folgendermaßen auf:

# tripwire --test --email adresse@tld.de

Passt alles, fahren Sie anschließend mit tripwire --check den ersten richtigen Integrationscheck (Abbildung 2). Tripwire gibt die Berichte in Kurzform auf der Konsole aus und schreibt sie parallel dazu etwas ausführlicher in die Datei Hostname-Zeitstempel.twr im Verzeichnis /var/lib/tripwire/report/ . Soll es diese auch gleich per E-Mail versenden, gilt es zusätzlich den Schalter --email-report anzugeben. Die Berichte landen dann bei den in den jeweiligen Regeln im Policy-File hinterlegten Empfängern.

Abbildung 2

Abbildung 2: Tripwire gibt beim Integritätscheck eine kurze Zusammenfassung auf der Standardausgabe aus. Die zugehörigen Berichte fallen meist detaillierter aus.

Hin und wieder soll es vorkommen, dass ein Admin die ein oder andere Kleinigkeit am System ändert. Da Tripwire nicht weiß, dass es sich um erlaubte Modifikationen handelt, führt das unter Umständen dazu, dass die Berichte vor Regelverletzungen nur so strotzen. Damit das nicht so bleibt, passen Sie die Tripwire-Datenbank schnell auf Basis des Berichts an. Dazu öffnet das Kommando

# tripwire --update -twrfile /var/lib/tripwire/report/${HOSTNAME}-Zeitstempel.twr<C>

einen Editor, der alle Regelverstöße auflistet (Abbildung 3). Alternativ kann Tripwire mit tripwire --check --interactive Änderungen auch sofort übernehmen.

Abbildung 3

Abbildung 3: Änderungen, die nachvollziehbar und erlaubt sind, lassen sich fix in die Tripwire-Datenbank übernehmen.

Tut der Admin sein Einverständnis durch Nichtstun kund, passt Tripwire die Datenbank entsprechend an, die Meldungen treten bei zukünftigen Prüfungen nicht mehr auf. Bei nicht genehmigten Regelverletzungen, die Tripwirebei jeder Prüfung wieder vorlegen soll, entfernen Sie lediglich das Kreuzchen in der zugehörigen Checkbox.

Möchten Sie einen Blick in die Tripwire-Datenbank werfen, klappt das mit dem Befehl twprint --print-dbfile. Ähnlich funktioniert das für eine binäre Berichtsdatei (Abbildung 4) mit dem Kommando

# twprint --print-report --twrfile /var/lib/tripwire/report/${HOSTNAME}-Zeitstempel.twr<C>
Abbildung 4

Abbildung 4: Der Tripwire-Report zeigt recht ausführlich, wo es Unstimmigkeiten gibt.

Laufen alle manuellen Checks zufriedenstellend, delegieren Sie die Integritätsprüfung an einen Cronjob. Dazu öffnen Sie als Root mit crontab -e die Crontabelle geöffnet und fügen beispielsweise folgende Zeile ein:

00 5 * * * /usr/sbin/tripwire --check --email-report

Damit weiß das System, dass es künftig täglich um 5:00 Uhr einen Check vornehmen und per Mail berichten soll.

Sicherheitstipps

Idealerweise richten Sie Tripwire auf einem frisch aufgesetzten System ein: Nur dann können Sie wirklich sicher sein, dass alle Dateien noch im Originalzustand vorliegen. Schlüssel, Policy-File und Konfigurationsdatei darf ausschließlich root lesen und schreiben, was folgendes Kommando sicherstellt:

# chmod 600 site.key ${HOSTNAME}-local.key tw.*

Auch auf die Verzeichnisse /etc/tripwire und /var/lib/tripwire/ darf nur root Zugriff erhalten (chmod 700 ...).

Wenn möglich, sollten Sie außerdem die Tripwire-Datenbank besonders schützen, sodass ein Angreifer keine Chance hat, sie zu ändern. Bei einem Desktop-Rechner bietet sich dazu ein externes Speichermedium an. Ein Server kann die Datenbank vor jedem Test via SSH und Public-Key-Verfahren von einem anderen Rechner herunterladen oder von einem nur lesbaren Medium beziehen.

Fazit

Tripwire macht seinem Namen alle Ehre. Das einfache, aber wirkungsvolle HIDS lässt sich schnell einrichten und versieht seinen Dienst still und diskret. Es wehrt zwar keine Angriffe ab, hilft aber dabei, Unstimmigkeiten zeitnah zu erkennen. Während Admins sonst nur eine geringe Chance haben, von Angreifern hinterlassene oder veränderte Dateien aufzuspüren, bekommen sie dies von Tripwire per E-Mail serviert, was den Aufwand für Suche und Entfernung spürbar verringert.

Die Regeln lassen sich auch nachträglich gut anpassen, etwa wenn sich Inodes und Dateigrößen als schlechte Properties für Logdateien erweisen, die ja von Zeit zu Zeit von Logrotate durchgedreht werden. Die Berichtsdateien fallen meist angenehm klein aus, sodass die Gefahr einer unbemerkt zulaufenden Festplatte kaum existiert. Nach gewollten Änderungen etwa durch ein Update oder geänderte Konfigurationsdateien können Sie die Datenbank unaufwändig aktualisieren. 

Glossar

Atime

Access Time. Gibt an, wann eine Datei das letzte Mal zum Lesen geöffnet wurde.

Mtime

Modification Time. Gibt an, wann der Inhalt einer Datei zuletzt verändert wurde.

Tip a friend    Druckansicht beenden Bookmark and Share
Kommentare