Die Integritätsüberwachung beantwortet eine Frage, die weder ein Virenschutz noch eine Firewall beantwortet: Was hat sich auf diesem Server seit vergangener Woche geändert? Ein signaturbasierter Scanner sucht bekannte Schadmuster; AIDE weiß nichts über Schädlichkeit, es weiß, dass diese Datei gestern anders war. Um eine an eine bestehende Datei angehängte Hintertür zu finden, ist das der einzige Ansatz, der funktioniert.

AIDE ist mit zwei Befehlen installiert. Es so einzurichten, dass seine Berichte gelesen werden, ist der schwierigere Teil — und daran scheitert es meistens: Der erste Bericht kommt mit zehntausend Zeilen, den zweiten öffnet niemand, und einen Monat später wird der Auftrag gelöscht.

Installation und die erste Datenbank

sudo apt install aide aide-common
sudo aideinit

Die Initialisierung dauert von wenigen Minuten bis zu einer halben Stunde: Für jede Datei werden Prüfsummen berechnet. Das Ergebnis wird neben der Arbeitsdatenbank mit der Endung .new abgelegt und muss in Betrieb genommen werden:

sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Danach wird eine Prüfung so ausgeführt:

sudo aide --check

Was auszuschließen ist, damit der Bericht lesbar bleibt

Die Einstellungen liegen in /etc/aide/aide.conf und im Verzeichnis /etc/aide/aide.conf.d/. Die mitgelieferte Debian-Konfiguration prüft zu viel, und das Erste, was zu tun ist, ist das zu entfernen, was sich ohnehin ständig von selbst ändert:

  • /var/log — ändert sich jede Sekunde;
  • /var/lib vollständig — Datenbanken, Paketstatus, Dienstzustände;
  • /var/cache, /tmp, /proc, /sys, /run;
  • die Upload- und Cache-Verzeichnisse der Website — deren Inhalt ändern die Besucher.

Mit den strengsten Einstellungen zu prüfen lohnt sich eine schmale Liste:

  • /bin, /sbin, /usr/bin, /usr/sbin — die ausführbaren Dateien des Systems;
  • /lib, /usr/lib — Bibliotheken;
  • /etc — die Konfiguration;
  • /root/.ssh und die .ssh-Verzeichnisse Ihrer Benutzer;
  • der Code der Website, aber ohne die Upload- und Cache-Verzeichnisse.

Der Maßstab: Ein gewöhnlicher Tagesbericht sollte auf einen Bildschirm passen. Ist er länger, reichen die Ausschlüsse nicht, und er wird nicht mehr gelesen.

Wo die Datenbank liegen sollte

Ein wesentlicher Punkt, der oft übersehen wird. Hat jemand Fremdes Root-Rechte, kostet es ihn nichts, eine Datei auszutauschen und die AIDE-Datenbank sofort zu aktualisieren — und die Prüfung meldet danach, alles sei in Ordnung. Eine Datenbank, die auf derselben Maschine und beschreibbar liegt, schützt nur vor Zufällen.

Ein vernünftiges Minimum für einen einzelnen Server:

  • die Datenbank nach jeder Aktualisierung auf eine andere Maschine kopieren und die Prüfung mit dieser Kopie ausführen;
  • oder wenigstens die Prüfsumme der Datenbank getrennt aufbewahren und vor der Prüfung abgleichen:
sha256sum /var/lib/aide/aide.db

Schon eine so einfache Maßnahme macht aus einem stillen Austausch ein auffälliges Ereignis.

Das Aktualisieren der Datenbank ist eine bewusste Handlung

Nach legitimen Änderungen — einem Systemupdate, einer neuen Version der Website — wird die Datenbank neu aufgebaut:

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

Der Zeitpunkt ist entscheidend. Richtig: den Bericht ansehen, sich vergewissern, dass jede Änderung erklärbar ist, und erst dann aktualisieren. Falsch und sehr verbreitet: aide --update nach Zeitplan laufen lassen, damit die Berichte sauber sind. Im zweiten Fall läuft das System, die Berichte kommen, und Änderungen werden genau in dem Moment als Normalzustand festgeschrieben, in dem sie geschehen — der Sinn ist damit vollständig verloren.

Zeitplan und Last

Das Paket aide-common richtet selbst einen täglichen Auftrag ein. Die Prüfung belastet Platte und Prozessor für einige Minuten, weshalb sie zu einer ruhigen Stunde und mit gesenkter Priorität laufen sollte:

0 4 * * * ionice -c3 nice -n19 /usr/bin/aide --check

Wie der Bericht zu lesen ist

Drei Abschnitte: hinzugefügte, entfernte und geänderte Dateien. Zu jeder Änderung wird gezeigt, was genau abweicht: Inhalt, Rechte, Eigentümer, Zeit.

Worauf zuerst zu reagieren ist:

  • eine Änderung an einer Datei in /bin, /sbin, /usr/bin außerhalb eines Update-Fensters;
  • neue Dateien in Systemverzeichnissen;
  • Änderungen an authorized_keys, /etc/passwd, /etc/sudoers, /etc/crontab und /etc/cron.d;
  • eine aufgetauchte Datei /etc/ld.so.preload — sie entsteht niemals von selbst.

Hundert geänderte Dateien unmittelbar nach apt upgrade sind normal, und der Zeitstempel des Berichts bestätigt es. Drei geänderte Dateien in /usr/bin an einem Mittwoch ohne Updates sind ein Grund innezuhalten und nachzusehen.

AIDE und debsums

Die Werkzeuge lösen benachbarte Aufgaben, aber ihre Referenz unterscheidet sich. AIDE vergleicht mit einem eigenen Schnappschuss — sieht also Änderungen an beliebigen Dateien, den Code der Website eingeschlossen. debsums vergleicht mit den Prüfsummen aus den Distributionspaketen — sieht also ausgetauschte Systemdateien ganz ohne vorherige Einrichtung, weiß aber nichts über das, was Sie außerhalb der Pakete installiert haben. Beide zu betreiben ist sinnvoll; in der Praxis kommt debsums meist zuerst, weil es weder Konfiguration noch Datenbank braucht.

Eine Schwäche haben sie ebenfalls gemeinsam: Der Bericht kommt per Mail, und Mail geht unter. Wichtig ist deshalb nicht, dass die Prüfung lief, sondern dass es einen Ort gibt, an dem ihr letztes Ergebnis sichtbar ist. Wie das aussieht, zeigt die Demo-Seite unten.