In Tripwire finden Sie ein mächtiges Werkzeug, um Ihre Systeme vor ungewollten Änderungen zu schützen.

Trojaner, die Überweisungsdaten beim Online-Banking manipulieren oder Computernutzer ausspähen; Webcams, die ihre Umgebung filmen, oder Hintertürchen, die Unbefugten Zugriff zu fremden Rechnern gewähren – das Verbrechen ist schon lange in der digitalen Welt angekommen. Intrusion-Detection-Systeme, kurz IDS, erkennen Angriffe auf Rechner und Netzwerke, indem Sie den Datenverkehr überwachen und dabei Angriffsmuster und Anomalien erkennen. Hostbasierte IDS hingegen spüren womöglich unerwünschte Änderungen in zu schützenden Rechnern auf. Sie informieren dann die verantwortlichen Administratoren zeitnah und können so die mit einem Angriff einhergehenden Schäden eindämmen oder gar verhindern.

Für das freie Betriebssystem gibt es zahlreiche IDS, sowohl für ganze Netzwerke (Network-based Intrusion Detection System, NIDS) als auch für einzelne Hosts (Host-based Intrusion Detection System, HIDS). Zur ersten Kategorie gehören Programme wie Snort, Suricata oder Prelude, die im Idealfall Angriffe auf gesamte Netzwerke erkennen. In die zweite Kategorie fallen Anwendungen wie Portsentry, Logcheck, Samhain, OSSEC oder 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 University [2] in West Lafayette (USA, Indiana) aus der Taufe gehoben. 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. Das Projekt eignet sich laut Tripwire Inc. für eine kleine Anzahl von Servern, die keine zentralisierte Administration und Berichtsfunktionen benötigen.

Funktionsweise

Angreifer versuchen in der Regel, ein gekapertes System mit Trojanern, Backdoors und veränderten Dateien zu kontaminieren, um jederzeit zurückkehren zu können und den Rechner in ihre Machenschaften zu involvieren. Tripwire wirkt dem entgegen, indem es Informationen (Prüfsummen, Dateigröße, Mtime, Ctime, Inode etc.) wichtiger Verzeichnisse und Dateien verschlüsselt in einer Datenbank ablegt. Damit vergleicht es später die Eigenschaften der zu überwachenden Dateien und teilt Abweichungen dem verantwortlichen Administrator mit. Im Idealfall ist alles in Ordnung und der Bericht fällt kurz und knapp aus. Etwas längere Berichte entstehen, wenn Dateien gewollt oder ungewollt geändert wurden – dann muss der Admin handeln.

Das Prinzip bietet den Vorteil, dass Sie den Vergleich diskret periodisch oder bei Verdacht eines Einbruchs ausführen können. Da das IDS nicht permanent im Hintergrund läuft und so meist auch nicht als laufender Prozess auffällt, beansprucht es kaum Systemressourcen. Fehlalarme kommen relativ selten vor. In der Regel wissen Administratoren, wann Tripwire ihre Server überwacht, und können so schnell die Datenbanken aktualisieren beziehungsweise sehen, ob sie für eine gemeldete Änderung verantwortlich zeichnen.

Als Nachteil wäre zu nennen, dass das System nicht sofort warnt, wenn ein mutmaßlicher Angriff stattfindet, sondern erst dessen Folgen protokolliert. Sobald Tripwire eine Meldung mit einer unberechtigten Änderung an einen Administrator versendet, darf dieser getrost von einer gelungenen Attacke ausgehen.

Installation

In den Haupt-Repositories der gängigen Distributionen findet sich Tripwire in der Regel nicht. Ubuntu stellt im Universe-Zweig nur für Saucy Salamander (13.10) die aktuelle Version zu Installation bereit. OpenSuse hält Tripwire nur im Security-Repository [4] vor, die Sie nachträglich einbinden müssen.

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 [5], die Sie mit dem Dreischritt aus den Quellen übersetzen:

# ./configure && make && make install

Während der Installation legt Tripwire einen Site- und einen Local-Key an. Der Erstere dient dazu, um die Konfigurations- und Policy-Dateien zu signieren, der Letztere zur Absicherung der Tripwire-Datenbank. Haben Sie die Schlüsselgenerierung bei der Installation aus irgendeinem Grund ausgelassen, holen Sie sie mit den Befehlen aus Listing 1 nach.

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

Für die Passphrase gilt dasselbe wie für gute Passwörter: Mehr als acht Zeichen Länge, Groß- und Kleinschreibung sowie Sonderzeichen erhöhen die Sicherheit.

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 an dieser Stelle unterbinden (LOOSEDIRECTORYCHECKING).

Da Tripwire auf entfernten Servern oft via Cronjob startet, kann es sich als sinnvoll erweisen, Mails auch dann zu versenden, wenn alles in Ordnung ist (MAILNOVIOLATIONS=true). Bleibt dann eine Nachricht 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.

Stolperdrähte spannen

Sind die Keys vorhanden und die Konfigurationsdatei im Klartext angepasst, spannen Sie die Stolperdrähte in Form von Policies auf dem Server. In Tripwires Konfigurationsverzeichnis befindet sich mit hoher Wahrscheinlichkeit bereits eine kommentierte Datei twpol.txt mit Standard-Richtlinien, dem Polfile. Da jedes System anders ist, bietet sie naturgemäß nicht den Schutz, den der individuelle Server benötigt. Vielmehr dient sie als gute Ausgangsbasis für eigene Anpassungen.

Die Policy-Datei nutzt einige Schlüsselwörter, denen ein @@ vorsteht (siehe Tabelle “Direktiven”). Mit den Direktiven unterteilen Sie die Richtlinien in Bereiche mit spezifischen Bedingungen und individuellen Meldungen.

Regeln im Polfile beginnen mit dem zu überwachenden Objekt, bei dem es sich um eine Datei oder ein Verzeichnis handeln kann, gefolgt von ->, den zu überwachenden Eigenschaften (“Properties”) und optionalen, in Klammern gesetzten Regelattributen. Häufig benötigte Properties fassten die Entwickler bereits in einigen Variablen zusammen.

Daneben erlaubt es das Regelset, eigene Variablen zu definieren, die Sie in der Datei mit $(Variable) aufrufen. Eine Regel erstreckt sich meist auf eine per Semikolon abgeschlossene Zeile. Regeln lassen sich zudem zu Gruppen zusammenfassen, um sie später leichter zu verwalten.

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, Inode-Nummer, Dateigröße, User- und Group-ID sowie die Rechte. Ferner wählen Sie über die Properties das Hashverfahren aus. Einen Überblick über die wichtigsten Properties und die oben erwähnten vordefinierten Variablen gibt die Tabelle “Eigenschaften”.

Die Regelattribute erlauben es, 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. Weiterhin lässt sich die Tiefe der Rekursion angeben, mit der Tripwire die Inhalte eines Verzeichnisses berücksichtigt (siehe Tabelle “Regelattribute”).

Mittels der E-Mail-Adressen informiert die Software bei einem Angriff verschiedene Verantwortliche, beispielsweise Webmaster über geänderte PHP-Dateien und Administratoren bei Auffälligkeiten im Verzeichnis /etc oder /sbin. Dabei dürfen Sie mehrere Adressen durch ein Semikolon getrennt angeben. Das ausführende Kommando (onviolation) erlaubt es, beispielsweise Dienste sicherheitshalber anzuhalten.

Bei der Rekursion sind -1 und True identisch. In beiden Fällen berücksichtigt das Tool den gesamte Inhalt eines Verzeichnisses. Bei 0 oder False prüft Tripwire nur der Inode eines Verzeichnisses, wohingegen 1 bedeutet, dass das Tool auch die in einem Verzeichnis enthaltenen Dateien auf ihre Integrität prüft (nicht aber die Inhalte in Unterverzeichnissen).

Eine besondere Regel definieren Stop-Points der Form Objekt; – dabei handelt es sich um von der Prüfung ausgeschlossene Verzeichnisse oder Dateien. Mit Stop-Points legen Sie entsprechend innerhalb eines zu prüfenden Verzeichnisses Ausnahmen fest.

Jeder Server ist anders und bedarf anderer Schutzmaßnahmen, sodass Sie das Policy-File für jeden Rechner individuell anpassen müssen. Die Default-Policy-Datei sollte bereits einen Mindestschutz bieten, 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-Libs zeigt auch, wie Sie mehrere Objekte gruppieren. Zudem sind E-Mail-Adressen hinterlegt, sodass der Verantwortliche Mails bei Vorfällen erhält.

(
  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) ;

Nach dem Erstellen der Konfigurations- und Policy-Dateien gilt es, diese zu verschlüsseln, bevor Sie die Tripwire-Datenbank initialisieren. Die beiden Klartext-Dateien legen Sie auf der Kommandozeile mit den Befehlen aus Listing 3 an. Nach dem Verschlüsseln liegen Konfigurations- und Policy-Datei in einer nicht mehr ohne Weiteres lesbaren Form vor.

# 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

Im Anschluss an das erfolgreiche Anlegen der Tripwire-Datenbank sollten Sie die Klartext-Dateien entfernen. Falls Sie später noch einmal einen Blick darauf werfen möchten, dechiffrieren die Befehle twadmin --print-polfile repektive twadmin --print-cfg-file die Files wieder.

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

Prüfen und berichten

Bevor Sie Tripwire in einen Cronjob verpacken, sollten Sie prüfen, ob die Software anstandslos E-Mails versendet. Dazu dient folgender Befehl:

# tripwire --test --email Adresse@Domain.de

Anschließend führen Sie mit tripwire --check die erste richtige Integritätsprüfung durch (Abbildung 1). Tripwire gibt die Berichte in Kurzform auf der Konsole aus und schreibt sie parallel dazu etwas ausführlicher in die Datei /var/lib/tripwire/report/$HOSTNAME-timestamp.twr (Abbildung 2).

Abbildung 1: Tripwire gibt beim Integritätscheck eine kurze Zusammenfassung auf der Standardausgabe aus. Die zugehörigen Berichte zeigen meist deutlich mehr Details.

Abbildung 2: Pro Cronjob und manuellem Integritätscheck ein Bericht: Wenn Sie diese nicht löschen, erzählen sie eine lange Geschichte von gewollten oder ungewollten Dateimanipulationen.

Sollen die Reports auch gleich per E-Mail versandt werden, geben Sie zusätzlich den Schalter --email-report an. Die Berichte gehen dann an die Empfänger, die Sie im Policy-File in den jeweiligen Regeln hinterlegt haben.

Hin und wieder kommt es vor, dass Admins die ein oder andere Kleinigkeit am System ändern. Da Tripwire nicht weiß, dass es sich um erlaubte Modifikationen handelt, strotzen dann die Berichte von Regelverletzungen nur so. Um das zu vermeiden, passen Sie die Tripwire-Datenbank auf Basis des Berichts an. Mittels des Kommandos:

# tripwire --update -twrfile /var/lib/tripwire/report/$HOSTNAME-timestamp.twr

öffnen Sie einen Editor, der alle Regelverstöße auflistet (Abbildung 3). Alternativ übernimmt die Software mit tripwire --check --interactive Änderungen auch sofort.

Abbildung 3: Nachvollziehbare und legitime Änderungen übernehmen Sie problemlos in die Datenbank.

Tun Sie nun durch Nichtstun Ihr Einverständnis kund, passt Tripwire die Datenbank entsprechend an, und die Meldungen zu Integritätsverletzungen treten bei zukünftigen Prüfungen nicht mehr auf. Ist eine Regelverletzung nicht genehmigt und soll bei jeder Prüfung wieder vorgelegt werden, entfernen Sie lediglich das Kreuzchen in der zur Regelverletzung gehörigen Checkbox.

Um einen Blick in die Tripwire-Datenbank zu werfen, nutzen Sie den Befehl twprint --print-dbfile. Ähnlich funktioniert es für eine binäre Berichtsdatei (Abbildung 4) mit folgendem Kommando:

# twprint --print-report --twrfile /var/lib/tripwire/report/$HOSTNAME-timestamp.twr

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

Laufen alle manuellen Checks zufriedenstellend, übernimmt ein Cronjob das Delegieren der Integritätsprüfung. Dazu öffnen Sie mit crontab -e als Root die Cron-Tabelle und erweitern sie um die Zeile:

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

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

Sicherheitstipps

Tripwire richten Sie am besten auf einem frisch aufgesetzten System ein, da nur in dem Fall sichergestellt ist, dass alle Dateien noch im Originalzustand vorliegen. Schlüssel, Policy-File und Konfigurationsdatei darf nur der Nutzer 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 zugreifen (chmod 700 ...).

Wenn möglich, sollten Sie die Tripwire-Datenbank besonders schützen, sodass ein Angreifer keine Chance hat, sie zu ändern. Bei einem Desktop-Rechner bietet sich 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 Werkzeug ist schnell eingerichtet und versieht seinen Dienst still und diskret. Das HIDS wehrt zwar keine Angriffe ab, kann aber dazu beitragen, Unstimmigkeiten zeitnah zu erkennen. Normalerweise haben Admins nur eine geringe Chance, von Angreifern eingeschmuggelte, kontaminierte Dateien aufzuspüren. Tripwire serviert solche Kandidaten per E-Mail, was den Aufwand für Suche und Entfernung spürbar verringert.

Regeln lassen sich auch nachträglich noch gut anpassen. Die Berichtsdateien fallen meist angenehm klein aus, sodass die Gefahr einer langsam und unbemerkt zulaufenden Festplatte kaum existiert. Erfolgten gewollte Änderungen, etwa durch ein Update oder geänderte Konfigurationsdateien, aktualisieren Sie die Datenbank ohne großen Aufwand.