Dateiintegritätsüberwachung mit AIDE — Änderungen am Home Server erkennen

Ein Home Server kann vollkommen gesund wirken, obwohl sich unbemerkt eine wichtige Datei verändert hat. Eine manipulierte SSH-Konfiguration, ein unerwartetes Binary oder eine überschriebene Webdatei führt nicht zwangsläufig zum Ausfall eines Dienstes. Das gewöhnliche Uptime Monitoring zeigt deshalb weiterhin Grün. File Integrity Monitoring liefert ein anderes Signal: nicht „Läuft der Rechner?“, sondern „Befindet sich der Rechner noch in dem Zustand, den ich vorgesehen habe?“

In dieser Anleitung richten wir AIDE (Advanced Intrusion Detection Environment) unter Debian oder Ubuntu ein, erstellen eine vertrauenswürdige Baseline, automatisieren Prüfungen mit einem systemd timer und klären den Umgang mit gemeldeten Änderungen. Dabei soll nicht jedes veränderte Byte zum Notfall werden. Wesentliche Änderungen sollen sichtbar bleiben, bevor sie im Grundrauschen der täglichen Administration verschwinden.

Was File Integrity Monitoring tatsächlich erkennt

AIDE durchsucht ausgewählte Pfade und speichert Merkmale wie Dateityp, Berechtigungen, Eigentümer, Größe, Änderungszeit und kryptografische Hashes. Bei einem späteren Lauf vergleicht es das aktuelle Filesystem mit dieser Datenbank. Der Bericht führt hinzugefügte, entfernte und veränderte Dateien auf.

Die Baseline ähnelt einem Foto einer Werkstatt zum Feierabend. Das Foto erklärt weder, wer einen Schraubendreher bewegt hat, noch warum es passiert ist. Am nächsten Morgen macht es die Veränderung jedoch sichtbar. Genauso versteht AIDE nicht, ob ein package upgrade legitim war oder ein Angreifer einen command ersetzt hat. AIDE liefert Belege; erst der Kontext macht daraus eine Entscheidung.

Diese Abgrenzung ist wichtig. AIDE ist weder Antivirus noch real-time blocking, Backup oder ein vollständiges intrusion detection system. Ein Angreifer mit root-Zugriff könnte versuchen, AIDE und seine lokale Datenbank zu manipulieren. File Integrity Monitoring ist daher nur eine Schicht in einem umfassenderen Schutz, der weiterhin Patching, least privilege, aussagekräftige Logs und wiederherstellbare Backups benötigt.

AIDE installieren und die Konfiguration verstehen

Unter Debian und Ubuntu installieren wir die paketierte Version und sehen uns anschließend das Konfigurationsverzeichnis an:

sudo apt update
sudo apt install aide
sudo ls -la /etc/aide/aide.conf.d/

Debian setzt die wirksame Konfiguration aus Snippets unter /etc/aide/aide.conf.d/ zusammen. Die vorhandenen Regeln des Packages sind ein guter Ausgangspunkt, weil sie bereits viele Systempfade berücksichtigen. Eine Regel verknüpft einen Pfad mit einer Gruppe von Attributen. Regeln mit umfangreichen Hashes eignen sich für Executables und Konfigurationen, während schnell veränderliche Runtime-Verzeichnisse meist ausgeschlossen werden sollten.

Vor eigenen Ergänzungen sollten wir die wertvollen Bestandteile dieses Servers bestimmen. Bei einem kleinen Webhost können das /etc, der application code unter /var/www, System-Binaries, systemd units und einige deployment scripts sein. Wer ohne Konzept alles überwacht, erzeugt häufig einen so lauten Bericht, dass ihn schließlich niemand mehr liest.

Gezielte Regeln für einen Home Server ergänzen

Ein lokales Snippet hält die eigene Policy getrennt von Dateien, die durch Packages verwaltet werden:

sudo nano /etc/aide/aide.conf.d/99_aide_local

Eine praktische erste Policy kann so aussehen:

/etc                         CONTENT_EX
/usr/local/bin               CONTENT_EX
/var/www                     CONTENT_EX
/etc/systemd/system          CONTENT_EX

!/var/www/.*/cache
!/var/www/.*/storage/logs
!/var/www/.*/public/uploads
!/var/lib/docker
!/var/log
!/run
!/tmp

CONTENT_EX überwacht Metadaten und Dateiinhalte mit starken Hashes. Die Ausschlüsse entfernen Pfade, in denen legitime Schreibvorgänge häufig oder Scans besonders aufwendig sind. Sie müssen zum tatsächlichen Layout der Anwendung passen: Uploads können eine gesonderte Überwachung auf unerwartete Executables verdienen, doch jedes Benutzerbild bei jedem Lauf zu hashen bringt möglicherweise wenig Nutzen.

Ein Ausschluss bedeutet nicht, dass ein Verzeichnis sicher ist. Er verwaltet vielmehr das Noise Budget. Wie ein Rauchmelder direkt neben einem Toaster kann eine schlecht platzierte Regel so viele harmlose Alarme erzeugen, dass der wichtige Alarm übersehen wird. Am besten beginnen wir mit kritischen, relativ stabilen Pfaden und erweitern die Policy nur, solange die Berichte verständlich bleiben.

Die erste Baseline sorgfältig erstellen

Die erste Datenbank ist die Referenz für alle späteren Vergleiche. Sie sollte deshalb nur entstehen, wenn sich der Server nachweislich in einem guten Zustand befindet. Zunächst installieren wir ausstehende security updates, prüfen aktive Dienste und suchen nach unerklärlichen Prozessen oder kürzlich erfolgten Anmeldungen. Eine Baseline auf einem bereits kompromittierten Host erklärt die Kompromittierung lediglich zum Normalzustand.

sudo aideinit
sudo aide --check

Je nach Package der Distribution erstellt aideinit eine neue Datenbank und installiert sie am vorgesehenen Ort. Die erste Prüfung sollte keine unerklärliche Differenz melden. Erscheinen sofort zahlreiche Änderungen, dürfen wir sie nicht blind akzeptieren. Möglicherweise liefen zwischen Initialisierung und Kontrolle ein geplanter Package-Job, ein Deployment oder Schreibvorgänge der Anwendung.

Eine zusätzliche geschützte Kopie der Baseline gehört auf ein anderes System. Ein Offline-Datenträger oder ein Backup Repository mit immutable snapshots ist besser als eine weitere beschreibbare Datei auf demselben Rechner. Auch ihre Checksumme sollte dokumentiert werden:

sudo sha256sum /var/lib/aide/aide.db.gz
sudo cp /var/lib/aide/aide.db.gz /mnt/offline-backup/aide.db.gz

Prüfungen automatisch mit systemd ausführen

Eine Sicherheitskontrolle, die vom Erinnerungsvermögen abhängt, findet irgendwann nicht mehr statt. Ein Service führt AIDE aus und lässt systemd die Ausgabe im Journal protokollieren:

# /etc/systemd/system/aide-check.service
[Unit]
Description=Daily AIDE file integrity check

[Service]
Type=oneshot
ExecStart=/usr/bin/aide --check

Danach erstellen wir einen Timer:

# /etc/systemd/system/aide-check.timer
[Unit]
Description=Run AIDE file integrity check daily

[Timer]
OnCalendar=*-*-* 03:20:00
RandomizedDelaySec=20m
Persistent=true

[Install]
WantedBy=timers.target

Nun aktivieren wir ihn und führen einen manuellen Test durch:

sudo systemctl daemon-reload
sudo systemctl enable --now aide-check.timer
sudo systemctl start aide-check.service
sudo systemctl status aide-check.service
sudo journalctl -u aide-check.service

Persistent=true holt eine verpasste Prüfung nach, sobald ein zuvor ausgeschalteter Server wieder läuft. RandomizedDelaySec verhindert, dass sämtliche Maintenance Tasks zur exakt gleichen Minute starten. Für einen Home Server ist eine tägliche Kontrolle häufig ein sinnvoller Ausgleich. Exponierte Systeme oder Umgebungen mit vielen Änderungen können einen anderen Rhythmus benötigen.

Einen Bericht ohne Panik lesen

AIDE fasst hinzugefügte, entfernte und veränderte Einträge zusammen und zeigt anschließend die abweichenden Attribute. Eine Konfiguration, die sich nach der eigenen Bearbeitung verändert hat, ist zu erwarten. Ein neues Executable in /usr/local/bin, ein veränderter SSH key oder ein außerhalb des deployment window modifizierter Web Entry Point muss dagegen sofort untersucht werden.

Bei jedem Fund helfen drei Fragen: Gab es eine genehmigte Änderung? Passt der Timestamp zu dieser Arbeit? Erklären Package-Daten, Deployment History oder Logs exakt diese Datei? Unter Debian liefert die Package-Verifikation zusätzlichen Kontext:

sudo dpkg -V
sudo journalctl --since "24 hours ago"
sudo stat /path/to/suspicious-file
sudo sha256sum /path/to/suspicious-file

Die Baseline darf nicht nur aktualisiert werden, damit eine Warnung verschwindet. Das wäre so, als würde man eine Warnleuchte im Auto entfernen, ohne unter die Motorhaube zu schauen. Zuerst muss die Differenz erklärt werden. Ist eine Kompromittierung plausibel, sollten Logs gesichert, der Host von nicht vertrauenswürdigen Netzen isoliert, gefährdete Credentials von einem sauberen Gerät aus gewechselt und bei Bedarf bekannte, vertrauenswürdige Quellen zur Wiederherstellung verwendet werden.

Die Baseline nach legitimen Änderungen aktualisieren

Operating Systems und Anwendungen verändern sich berechtigterweise. Nach einem Upgrade oder Deployment vergleichen wir den AIDE-Bericht mit den ausgeführten Arbeiten. Erst danach wird die neue Datenbank übernommen:

sudo aide --update
sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
sudo aide --check

Die Pfade können sich zwischen Distributionen leicht unterscheiden. Vor dem Verschieben müssen deshalb die Datenbankpfade in der wirksamen AIDE-Konfiguration geprüft werden. Baseline Updates gehören auf die Maintenance Checklist und nicht als automatischer command hinter jedes Package Upgrade. Automatische Akzeptanz entfernt genau den Review-Schritt, der File Integrity Monitoring wertvoll macht.

Auch die Policy muss sich weiterentwickeln. Einen generated cache schließen wir erst aus, wenn seine Aufgabe klar ist; ein neues Konfigurationsverzeichnis nehmen wir auf, sobald es wichtig wird. Die beste Policy ist nicht die längste. Es ist die kleinste Policy, die zuverlässig jene Assets schützt, die sich nur schwer neu aufbauen oder erklären lassen.

Ein kleiner Sensor mit einer nützlichen Frage

AIDE verhindert nicht jeden Angriff und kann nicht beweisen, dass ein Server sauber ist. Seine Stärke liegt in einer disziplinierten täglichen Frage: Was hat sich verändert? Mit einer sorgfältig erstellten Baseline, gezielten Regeln, externen Kopien und einem Timer, dessen Ergebnisse tatsächlich geprüft werden, wird diese Frage zu einer praktischen Sicherheitskontrolle statt zu einem weiteren installierten Package.

Beginne mit den Pfaden, die du verstehst, löse eine harmlose Teständerung aus und übe das Lesen des Ergebnisses, bevor du dich auf das System verlässt. Wenn du File Integrity Monitoring bereits auf einem Home Server verwendest, teile gern mit, welche Verzeichnisse nützliche Signale liefern und welche Ausschlüsse deine Berichte lesbar halten.