Tripwire ist ein Open‑Source Host‑Intrusion‑Detection‑System (HIDS) zur Überwachung und Alarmierung bei Dateiänderungen. Diese Anleitung beschreibt die Installation, Policy‑Anpassung, regelmäßige Prüfungen, Benachrichtigungen per E‑Mail und die Automatisierung per Cron auf Ubuntu 16.04.

Wichtig: Diese Anleitung behandelt lokale Tripwire‑Konfigurationen und grundlegende Härtungsschritte; für produktive Server sollten Sie zusätzliche Maßnahmen wie Dateisystemberechtigungen, Systemd‑Hardening und Monitoring‑Integration hinzufügen.

Ziele

• Tripwire installieren
• Tripwire‑Policy für Ubuntu anpassen
• Installation und Policy verifizieren
• Eigene Regeln (z. B. für /var/www) hinzufügen
• E‑Mail‑Benachrichtigung und Cron‑Automatisierung einrichten

Voraussetzungen

• Ubuntu 16.04 Server
• Root‑Rechte (sudo)

Schritt 1 — Tripwire installieren

Tripwire ist im offiziellen Ubuntu‑Repository verfügbar. Aktualisieren Sie die Paketliste und installieren Sie Tripwire:

sudo apt update
sudo apt install -y tripwire

Während der Installation werden Sie zum Postfix‑SMTP‑Setup gefragt. Wählen Sie “Internet‑Site” und bestätigen Sie mit “OK”, um fortzufahren.

Für den Namen des Mail‑Systems lassen Sie den Standardwert und bestätigen Sie mit “OK”.

Anschließend wird Tripwire‑Initialkonfiguration gestartet. Erstellen Sie den “site‑key” und den “local‑key”. Wenn Sie gefragt werden, wählen Sie jeweils “Yes” und geben anschließend die gewünschten Passphrasen ein (mindestens zweimal zur Bestätigung).

Sie werden gebeten, Passphrasen für site‑key und local‑key einzugeben und zu wiederholen. Merken Sie sich diese Passphrasen sicher — sie werden zur Verwaltung der verschlüsselten Policy und der lokalen Datenbank benötigt.

Wenn diese Schritte abgeschlossen sind, ist Tripwire installiert.

Schritt 2 — Tripwire‑Policy für Ubuntu anpassen

Alle Tripwire‑Konfigurationen befinden sich in /etc/tripwire.

Initialisieren Sie die lokale Tripwire‑Datenbank:

sudo tripwire --init

Sie müssen die local‑key‑Passphrase eingeben. Bei manchen Setups erhalten Sie die Fehlermeldung “No such directory” — Tripwire findet dann in der Policy verzeichnete Pfade, die auf dem System nicht existieren. Finden Sie diese Pfade mit:

sudo sh -c "tripwire --check | grep Filename > no-directory.txt"
cat no-directory.txt

Öffnen Sie nun die Policy‑Quelldatei und passen Sie die Regeln an:

cd /etc/tripwire
sudo vim twpol.txt

Hinweis: Verwenden Sie Ihren bevorzugten Editor (vim, nano, sed). Sichern Sie vor Änderungen stets die Originaldatei:

sudo cp /etc/tripwire/twpol.txt /etc/tripwire/twpol.txt.bak

Beispiele für sinnvolle Anpassungen (übersetzt und lokalisiert):

• Boot‑Skripte: Einige Distributionen nutzen andere Verzeichnisse; kommentieren Sie Einträge aus, die auf Ihrem System nicht existieren.

(
  rulename = "Boot Scripts",
  severity = $(SIG_HI)
)
{
        /etc/init.d             -> $(SEC_BIN) ;
        #/etc/rc.boot           -> $(SEC_BIN) ;
        /etc/rcS.d              -> $(SEC_BIN) ;

• System‑Boot‑Änderungen: Temporäre Verzeichnisse wie /var/run können flüchtige Inhalte enthalten; kommentieren Sie jene aus, die auf Ihrem System Probleme bereiten.

(
  rulename = "System boot changes",
  severity = $(SIG_HI)
)
{
        #/var/lock               -> $(SEC_CONFIG) ;
        #/var/run                -> $(SEC_CONFIG) ; # daemon PIDs
        /var/log                -> $(SEC_CONFIG) ;

• Root‑Konfigurationsdateien: Heben Sie kritische Dateien hervor und kommentieren Sie unwichtige Beispiele.

(
  rulename = "Root config files",
  severity = 100
)
{
        /root                           -> $(SEC_CRIT) ; # Catch all additions to /root
        #/root/mail                     -> $(SEC_CONFIG) ;
        /root/.bashrc                   -> $(SEC_CONFIG) ;
        /root/.bash_history             -> $(SEC_CONFIG) ;

• Geräte‑ und Kernelinformationen: Viele /proc‑Einträge sind laufzeitabhängig; aus Performance‑ und Rauschgründen können Sie einige Einträge auskommentieren.

(
  rulename = "Devices & Kernel information",
  severity = $(SIG_HI),
)
{
        /dev            -> $(Device) ;
        /dev/pts        -> $(Device);
        /dev/shm        -> $(Device);
        #/proc          -> $(Device) ;
        /proc/devices           -> $(Device) ;
        /proc/net               -> $(Device) ;
        /proc/cpuinfo           -> $(Device) ;

Wichtig: Kommentieren Sie nur Einträge aus, die eindeutig nicht auf Ihrem System existieren oder die zu vielen falsch‑positiven Meldungen führen. Testen Sie nach jeder Änderung.

Nachdem Sie twpol.txt angepasst haben, erstellen Sie die verschlüsselte Policy neu:

sudo twadmin -m P /etc/tripwire/twpol.txt

Geben Sie die site‑key‑Passphrase ein. Anschließend initialisieren Sie die Datenbank erneut:

sudo tripwire --init

Geben Sie die local‑key‑Passphrase ein. Bei Erfolg sehen Sie keine Fehler.

Tripwire‑Policy ist damit für das Ubuntu‑System konfiguriert.

Schritt 3 — Integritätsprüfung ausführen

Führen Sie einen manuellen Integritätscheck aus:

sudo tripwire --check

Wenn alles passt, sollten Sie Ausgaben wie “No Violation” und “No Error” sehen.

Test: Legen Sie eine Datei im Home‑Verzeichnis an und prüfen Sie erneut:

cd ~/
touch hakase-labs.txt
sudo tripwire --check

Tripwire sollte eine neue Datei erkennen sowie die Änderung des Verzeichnisses melden.

Schritt 4 — Eigene Regel hinzufügen

Um benutzerdefinierte Pfade zu überwachen (z. B. eine Web‑Anwendung in /var/www), fügen Sie eine Regel in twpol.txt hinzu.

cd /etc/tripwire
sudo vim twpol.txt

Fügen Sie am Ende der Datei eine neue Regel ein:

# Ruleset for Wordpress
(
  rulename = "Wordpress Ruleset",
  severity= $(SIG_HI)
)
{
        /var/www        -> $(SEC_CRIT);
}

Speichern, dann die verschlüsselte Policy neu erzeugen:

sudo twadmin -m P /etc/tripwire/twpol.txt

Geben Sie die site‑key‑Passphrase ein und reinitialisieren Sie die Datenbank:

sudo tripwire --init

Geben Sie die local‑key‑Passphrase ein.

Testen Sie die Überwachung, indem Sie eine Datei unter /var/www anlegen und eine bestehende Datei ändern:

cd /var/www/
touch hakase-labs.txt
echo "
 Hakase-labs Tutorial
" > html/index.nginx-debian.html
sudo tripwire --check

Tripwire meldet die Verletzung mit hoher Schwere.

Schritt 5 — E‑Mail‑Benachrichtigung und Cron einrichten

Tripwire kann Berichte per E‑Mail versenden. Verwenden Sie zum Testen:

tripwire --test --email [email protected]

Überprüfen Sie, ob Sie die Test‑E‑Mail vom Server erhalten.

Um eine Regel mit E‑Mail‑Ziel zu versehen, editieren Sie twpol.txt und fügen Sie in der jeweilige Regel das Feld emailto hinzu:

# Rules for Web-app
(
  rulename = "Wordpress Rule",
  severity = $(SIG_HI),
  emailto = [email protected]
)

Speichern, die Policy neu erzeugen und die Datenbank reinitialisieren:

sudo twadmin -m P /etc/tripwire/twpol.txt
sudo tripwire --init

Testen Sie Reportversand per E‑Mail mit:

sudo tripwire --check --email-report

Sie sollten einen Bericht in Ihrem Postfach finden.

Automatisieren Sie tägliche Prüfungen per Root‑Crontab:

sudo crontab -e -u root

Fügen Sie folgende Zeile ein, um täglich um Mitternacht zu prüfen und einen E‑Mail‑Report zu senden:

0 0 * * * tripwire --check --email-report

Starten Sie cron neu, damit Änderungen übernommen werden:

sudo systemctl restart cron

Nun prüft das System täglich und sendet bei Regelverletzungen eine E‑Mail.

Ergänzende Empfehlungen und weiterführende Inhalte

Wann Tripwire allein nicht ausreicht

• Tripwire erkennt Änderungen an Dateien, reagiert aber nicht aktiv (z. B. kein Blockieren). Für aktive Schutzmaßnahmen kombinieren Sie Tripwire mit IDS/IPS, zentraler Log‑Aggregation und automatisierten Reaktionsskripten.
• Tripwire kann falsch‑positive Meldungen erzeugen (z. B. bei legitimen Deployments). Ergänzen Sie daher Deploy‑Hooks, Whitelists und Change‑Management‑Prozesse.

Alternative Ansätze

• OSSEC / Wazuh: Bietet Host‑IDS plus zentrale Verwaltung, File‑Integrity‑Monitoring (FIM) und bessere SIEM‑Integration.
• Auditd: Kernel‑basiertes Audit‑Subsystem, gut für detaillierte Überwachungen von Syscalls und Zugriffsrechten.
• Tripwire + SIEM: Kombinieren Sie Tripwire‑Alarme mit einem SIEM (z. B. Elastic, Splunk) für Korrelation und langfristige Analyse.

Mini‑Methodologie für produktiven Einsatz

1. Baseline erstellen: Policy lokal anpassen, unwichtige Pfade auskommentieren.
2. Erstinitialisierung: tripwire –init und –check durchführen.
3. Testphase: Change‑Management‑Workflow einspielen, false positives dokumentieren.
4. Automatisierung: Cron oder systemd‑Timer, E‑Mail‑Reports konfigurieren.
5. Integration: Logs in SIEM leiten, Alarme in Incident‑Management einbinden.

Rollenbasierte Checklisten

• Administrator
  • Backup der twpol.txt erstellen
  • site‑key und local‑key sicher verwahren
  • regelmäßige Tests nach System‑Updates durchführen
• DevOps/Release Engineer
  • Deploy‑Skripte so anpassen, dass Tripwire‑Policy‑Änderungen kommuniziert werden
  • für geplante Änderungen Whitelists oder temporäre Policy‑Updates bereitstellen
• Security Operator
  • E‑Mail‑Alarme überprüfen und nach Priorität eskalieren
  • Tripwire‑Berichte in SIEM einpflegen und Regeln für Alarmierung definieren

SOP / Playbook für Regeländerung

1. Änderung in twpol.txt in separatem Branch/Repository dokumentieren
2. Backup: sudo cp /etc/tripwire/twpol.txt /etc/tripwire/twpol.txt.bak
3. Policy anpassen und lokal testen (twadmin -m P)
4. Policy anwenden und DB neu initialisieren (tripwire –init)
5. Testlauf: tripwire –check und Überprüfung auf erwartete Ergebnisse
6. Nach erfolgreichem Test Änderung in Produktion deployen

Incident‑Runbook (Kurzform)

1. Alarm prüfen und Ausgabe aus /var/lib/tripwire oder E‑Mail‑Report einsehen
2. Betroffene Datei(en) isolieren (Zugriffsrechte entziehen, Backup erstellen)
3. Timestamp/Checksum vergleichen mit Backup/Repository
4. Forensik: Metadaten sichern (ls -l, stat, file, md5sum/sha256sum)
5. Wiederherstellung: saubere Kopie aus Backup oder SCM zurückspielen
6. Post‑Mortem: Ursache analysieren, Policy/Prozesse anpassen

Sicherheits‑Härtungsempfehlungen

• Schützen Sie site‑key/local‑key‑Passphrasen: nur auf einem sicheren Admin‑Rechner speichern.
• Zugriffsschutz: Nur root oder ein dediziertes Administratorkonto darf twadmin und tripwire ausführen.
• Dateisystemberechtigungen: Beschränken Sie Schreibrechte für überwachte Pfade.
• Regelmäßige Updates: Halten Sie Tripwire, Postfix und das OS aktuell.

Cron vs. systemd‑Timer

• Cron ist einfach und weit verbreitet; systemd‑Timer bietet allerdings bessere Logging‑Integration (journald), Abhängigkeitssteuerung und ein einheitliches Management. Beispiel systemd‑Timer (optional):

# /etc/systemd/system/tripwire-check.service
[Unit]
Description=Tripwire daily integrity check

[Service]
Type=oneshot
ExecStart=/usr/bin/tripwire --check --email-report

# /etc/systemd/system/tripwire-check.timer
[Unit]
Description=Run Tripwire daily

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Aktivieren mit:

sudo systemctl enable --now tripwire-check.timer

1‑Zeiler Glossar

• HIDS: Host‑based Intrusion Detection System — überwacht Datei‑ und Systemintegrität auf einzelnen Hosts.
• Policy: Textdatei (twpol.txt) mit Regeln, welche Pfade und Attribute Tripwire überwacht.
• twadmin: Verwaltungstool zum Erzeugen/Signieren verschlüsselter Policy‑Dateien.
• tripwire –init: Initialisiert oder reinitialisiert die lokale Tripwire‑Datenbank.

Zusammenfassung

Tripwire bietet ein solides, leichtgewichtiges FIM‑Werkzeug, das sich gut für Host‑level Integritätsprüfungen eignet. Mit angepasster Policy, getesteten Regeln, E‑Mail‑Benachrichtigungen und Automatisierung per Cron (oder systemd‑Timer) lässt sich eine zuverlässige Überwachung pipeline‑unabhängiger Dateiintegrität erreichen.

Wichtig: Kombinieren Sie Tripwire mit weiteren Sicherheitsmaßnahmen (Zugriffssteuerung, SIEM, Backups) und definieren Sie klare Prozesse für Deploys und Incident‑Handling.

Referenzen

• https://github.com/Tripwire/tripwire-open-source
• https://www-uxsup.csx.cam.ac.uk/