Oft tauschen Angreifer die Originalprogramme gegen eigene aus, um ihr Treiben zu verschleiern. Hostbasierte Intrusion-Detection-Systeme entdecken solche Rootkits.

Der Datenverkehr steigt und steigt: Für jeden Webmaster erfreulich, so lange die Daten abgerufen werden, die er selbst bereitstellt. Nicht selten bedienen sich aber andere am kostbaren Plattenplatz und Transfervolumen, ohne dass der Besitzer etwas davon weiß. Sowohl Serverdienste als auch Webapplikationen bieten oft Lücken, über die Angreifer den Rechner still und heimlich der Kontrolle des Besitzers entziehen können.

Damit die eingerichtete Backdoor dauerhaft bestehen bleibt, spielt der Eindringling nach dem Angriff ein Rootkit ein, welches einen versteckten Server installiert und Zugriff über einen unüblichen Netzwerkport auf das System gestattet – selbst dann, wenn das ursprüngliche Einfallstor zwischenzeitlich geschlossen wurde.

Um die Existenz des Hintertürchens zu verschleiern, tauscht das Rootkit zusätzlich wichtige Systemprogramme wie beispielsweise ps und netstat gegen modifizierte Versionen aus, die beim Aufruf weder den Prozess noch die Netzwerkverbindung der Backdoor anzeigen. So genannte hostbasierte Intrusion-Detection-Systeme (HIDS) sorgen dafür, dass derartige Machenschaften auffliegen.

Das Programm AIDE (Advanced Intrusion Detection Environment, [1]) ist im Vergleich zu anderen Produkten wie Tripwire mit einer Größe von 800 KByte ein ein echtes Leichtgewicht, das auch den ambitionierten Einstiger nicht vor unüberwindliche Hürden bei der Installation und Konfiguration stellt, aber einen ausreichenden Funktionsumfang mitbringt.

AIDE

Der Weg, den wie die meisten Programme dieser Art auch AIDE geht, ist einfach und effektiv: Es erstellt von spezifizierten Dateien und Verzeichnissen so genannte Fingerprints. Dazu sammelt es in einer Datenbank deren Charakteristika wie Dateigröße, Zugriffsberechtigungen und dergleichen. Beim erneuten Aufruf des Programms vergleicht es den Ist-Zustand der Datei mit den in der Datenbank hinterlegten Merkmalen. Fehlende Übereinstimmung ist ein eindeutiges Indiz für eine Veränderung am Programm.

Installation

Auf der Heft-CD finden Sie für alle gängigen Distributionen passende Binärpakete im RPM- oder DEB-Format, die Sie je nach Typ über rpm -ivh aide-Version.rpm oder dpkg --install aide-Version.deb installieren. Sollte für Ihr System kein passendes Paket vorhanden sein, kompilieren Sie das Programm aus den ebenfalls auf der Heft-CD befindlichen Quellen mit dem üblichen Dreisatz ./configure && make && su -c make install.

Das beste Intrusion-Detection-System ist nur so gut wie die Konfiguration, die es steuert. Daher gilt es, das System über die Konfigurationsdatei /etc/aide.conf noch vor der Initialisierung der Soll-Datenbank möglichst präzise an die spezifischen Gegebenheiten anzupassen.

Die aide.conf bestimmt vor allem, welche Datei- und Ordnerattribute AIDE in seiner Datenbank als Soll-Zustand speichert. Diese Soll-Datenbank beschreibt einen sicheren Zustand des System, den Sie am besten direkt nach einer Installation des Betriebssystems erzeugen. Anschließend verwenden Sie sie beliebig oft als Referenz für die Suche nach Veränderungen.

Zu den möglichen Dateiattributen zählen Zugriffsrechte, Dateigröße, Anzahl der Links sowie berechtige Benutzer und Gruppen. Außerdem berechnet AIDE mit verschiedenen Algorithmen kryptographische Checksummen der zu überprüfenden Objekte und speichert diese ebenfalls in der Datenbank.

Konfiguration

Ein Beispiel für eine /etc/aide.conf finden Sie in Listing 1. Die Konfiguration beginnt mit einigen Parametern (Zeile 3 bis 6), die unter anderem festlegen, wo AIDE seine Datenbank ablegt. Die Zeilen 7 bis 9 definieren neue Gruppen von zu überprüfenden Attributen (siehe Tabelle “AIDE-Attribute”).

Bei den Prüfregeln geben Sie das Objekt an, gefolgt von den Attributen, die AIDE überwachen soll (Zeile 18). Lassen Sie dabei größte Sorgfalt walten: Sind zu wenig Objekte oder unzureichende Attribute angegeben, fällt ein Einbruch unter Umständen gar nicht auf. Achten Sie auch darauf, dass AIDE keine Objekte überwacht, die auf dem eigenen System gar nicht existieren: Das Programm würde in diesem Fall überflüssigerweise Alarm schlagen und das Fehlen von Objekten direkt in der Datenbank vermerken.

Die Zeilen 12 bis 15 weisen AIDE an, die angegebenen Verzeichnisse nicht zu überprüfen. Das Ausrufezeichen (!) dient generell zur Ausschließen einzelner Dateien oder Verzeichnisse.

#/etc/aide.conf (Beispiel)
#
database=file:/var/lib/aide/aide.db
database_out=file:/var/lib/aide/aide.db.new
verbose=20
report_url=stdout
All=R+a+sha1+rmd160+tiger
Norm=s+n+b+md5+sha1+rmd160+tiger
R=p+i+n+u+g+s+m+c+md5
#
# Folgende Verzeichnisse nicht überwachen
!/dev
!/tmp
!/proc
!/usr/src
#
# Das komplette Root-Verzeichnis kontrollieren
/ R
#

AIDE bedienen

Das Kommando aide --init erzeugt in unserem Beispiel die Soll-Datenbank im Verzeichnis /var/lib/aide. Sie sollten die neue Datenbank zusammen mit der Konfigurationsdatei und dem Programm direkt nach dem Erstellen an einen sicheren Ortkopieren – beispielsweise auf eine CD oder einen schreibgeschützten USB-Stick –, um sie vor Manipulationen zu schützen. Der Aufruf aide --check (Abbildung 1) überprüft das System auf Veränderungen.

aide –check meldet AIDE geänderte Rechte der Datei /bin/ps.” width=”300″ height=”250″ /> Abbildung 1: Nach einer Systemüberprüfung mit aide --check meldet AIDE geänderte Rechte der Datei /bin/ps.

Dieses Kommando rufen Sie in regelmäßigen Abständen immer wieder auf, um den Ist-Zustand des Systems mit dem Soll-Zustand zu vergleichen. Ein täglicher Aufruf genügt in den meisten Fällen. Meldet der Check eine Änderung am Dateisystem, so gilt es, zu entscheiden, ob es sich um eine gewollte Änderung handelt (beispielsweise durch ein Software-Update), oder ob tatsächlich ein nicht autorisierter Zugriff stattgefunden hat.

Bei einer legitimen Änderung nehmen Sie den neuen Ist-Zustand mit dem Befehl aide --update in die Soll-Datenbank auf. Das ist wichtig, da AIDE sonst bei jedem Check aufs Neue die gewollte Veränderung am System anzeigt. Meldet das Programm einen nicht autorisierten Zugriff, überprüfen Sie zunächst, um welche Regelverletzung es sich handelt, und wodurch diese möglich wurde. Anschließend suchen und schließen Sie das Sicherheitsloch, über das der Angreifer Zugriff auf das System bekommen hat. Bei dieser Aufgabe gewährt AIDE jedoch keine Hilfestellung, da sich das Programm ausschließlich auf das Aufspüren von Veränderungen versteht.

Grundsätzlich sollten Sie jedes System mit den aktuellsten Paketen auf Stand halten, da veraltete Programmversionen oft bekannte Sicherheitslöcher enthalten, die ein Angreifer zum Einbruch in Ihr System nutzen kann. Nicht verwendete Software deaktivieren oder – noch besser – deinstallieren Sie: Das gilt ganz besonders für Netzwerkdienste. Eine Übersicht, welche Dienste das Betriebssystem beim Systemstart automatisch aktiviert, erhalten Sie unter Suse und Fedora mit dem Befehl chkconfig --list. Das Kommando chkconfig --del Dienst sorgt dafür, dass der Dienst zukünftig beim Booten nicht mehr startet.

Brandbekämpfung

Über einen wesentlichen Punkt muss man sich im Klaren sein: Ein HIDS schlägt immer erst dann zu, wenn es eigentlich schon “zu spät” ist. Es funktioniert im Grunde wie eine stille Alarmanlage und meldet zwar den Einbruch, kann ihn aber nicht verhindern. Das HIDS liefert lediglich Informationen darüber, das auf dem System irgend etwas nicht stimmt – die Ursache für diese Unregelmäßigkeit müssen Sie selbst ermitteln. Bei den Vorbereitungen zur Installation von AIDE sollten Sie sich auch darüber Gedanken machen, auf welchen Systemen eine Installation überhaupt Sinn macht. AIDE sollte auf allen Rechnern laufen, deren Dienste öffentlich zugänglich sind, also beispielsweise auf Web-, FTP- und Mailservern.

Ein hostbasiertes Intrusion-Detection-System stellt zudem nur einen Teil einer schlüssigen Sicherheitslösung dar. Zu dieser zählen auch so genannte netzwerkbasierte IDS (NIDS), die das Netzwerk auf verdächtige IP-Pakete überwachen. Der wohl bekannteste Vertreter dieser Gruppe heißt Snort [2]: Er erkennt Unstimmigkeiten im Netzwerkverkehr anhand von Signaturen und schlägt auf vielfältige Weise Alarm, wenn verdächtige Pakete seinen Weg queren. In einigen Fällen ist er sogar in der Lage, die zugehörigen Netzwerkverbindungen zu beenden, um so einem eventuell bevorstehen Angriff vorzubeugen. Bei der Suche nach bereits installierten Rootkits [3] hilft das Programm Chkrootkit [4] (Abbildung 2).

ps auf eine modifizierte Version. Ein weiterer Test zeigt, dass sich die Netzwerkkarte eth0 im Promiscous-Mode befindet.” width=”300″ height=”111″ /> Abbildung 2: Chkrootkit testet das Programm ps auf eine modifizierte Version. Ein weiterer Test zeigt, dass sich die Netzwerkkarte eth0 im Promiscous-Mode befindet.

Wer ein Intrusion Detection System betreibt, hat eine Menge an Daten zu überwachen und auszuwerten. Um dabei nicht relevante Informationen von den wichtigen zu unterscheiden, dienen Werkzeuge wie Prelude [5]. Es versteht sich als hybrides Intrusion-Detection-System, vereint also die Vorteile von einem HIDS und NIDS in einer Anwendung. Dazu nutzt es andere IDS als Sensoren, die Ihre Informationen an Prelude (Abbildung 3) weiterleiten.

Abbildung 3: Das Prewikka-Frontend von Prelude zeigt einzelne Meldungen übersichtlich dargestellt an.

Prelude selbst besitzt eine komfortable Managementkonsole (Prewikka), die alle Alarmmeldungen übersichtlich darstellt. Der Vorteil liegt auf der Hand: Sie müssen sich nicht durch eine Vielzahl von unterschiedlichen Logdateien kämpfen, sondern sehen in der Managementkonsole auf einem Blick, wie es um Ihr System steht.

Ende der Fahnenstange?

Noch für jeden Schutzmechanismus ersannen findige Cracker früher oder später probate Mittel, um diesen zu umgehen. Hostbasierte Intrusion-Detection-Systeme machen da keine Ausnahme. Die einfachste Möglichkeit, solche Systeme auszutricksen, stellt der Tausch des HIDS-Binaries gegen ein Imitat dar, das modifizierte Dateien nicht mehr meldet. Zur Vorbeugung sollten Sie deshalb immer auch das Programm selbst auf einem nicht beschreibbaren Datenträger sichern.

Wesentlich gefährlicher, weil für den Anwender viel schwieriger zu entdecken, sind Kernel-Rootkits, die Systemaufrufe abfangen und modifizieren. Sie setzten jedes noch so gute Abwehrsystem außer Kraft, das Sie auf dem laufenden System starten. Hier schafft nur der Check am ruhenden System Klarheit, indem Sie entweder die Festplatte ausbauen und mit einem anderen Rechner prüfen, oder ein Livesystem starten, von dem aus Sie die Überprüfung vornehmen.