Tatort: Linux-Rechner

RPM hilft

So bietet der "Red Hat Packet Manager" rpm (der unter anderem auch bei Suse, Mandrake und Fedora zum Einsatz kommt) die Option -V (für englisch "verify"), mit der sich der Zustand installierter Pakete überprüfen lässt. Das RPM-System vergleicht dann den aktuellen Zustand der Dateien mit ihrem Zustand zum Zeitpunkt der Installation. Da viele Dateien (z. B. die für ein System kritischen Konfigurationsdateien) nach der Installation angepasst und modifiziert werden, lässt sich die Methode nur eingeschränkt verwenden. Sie taugt aber zum Beispiel, um sich zu vergewissern, dass wichtige Systemprogramme nicht durch gleichnamige Tools mit Hintertüren ersetzt wurden.

In guter alter Unix-Manier gibt der Befehl rpm -V Paketname nichts aus, wenn alles in Ordnung ist. Hingegen erkennt der Administrator im folgenden Beispiel …

$ rpm -V coreutils
S.5….T   /bin/ls

…, dass der Befehl /bin/ls aus dem coreutils-Paket bezüglich Größe, Inhalt und Datum (S steht für "Size", 5 für MD5-Prüfsumme und T für "Time") manipuliert wurde. rpm -V bemerkt zudem Änderungen am Eigentümer der Datei (U – "User), an der Eigentümergruppe (G), an symbolischen Links (L), an Gerätedateien (D – "Device") und am Dateityp sowie den Dateirechten [6] (M – "Mode").

Alle per Paketmanager installierten Pakete auf einmal überprüft der Befehl rpm -Va. Selbst auf frisch aufgespielten Systemen sorgt er für Unmengen an Meldungen. Entweder ignoriert man die mit einem c (für "configuration file") oder einem d (für "documentation") gekennzeichneten Dateien oder schränkt die Analyse von vornherein auf die Dateien in den für ausführbare Programme und Bibliotheken reservierten Verzeichnissen bin/ und lib/ ein:

rpm -Va | grep 'bin/'
rpm -Va | grep 'lib/'

Rootkit-Erkennung

Während Tripwire und Aide den "guten" Zustand des Betriebssystems in einer Datenbank speichern und regelmäßig mit dem aktuellen Zustand vergleichen, schlägt Chkrootkit [7] den umgekehrten Weg ein. Es kennt die vom Angreifer installierten Werkzeuge, Rootkit genannt, und deren typische Pfade und fahndet auf dem Linux-System spezifisch danach. Zusätzlich sucht und findet Chkrootkit allgemeine Hinweise auf Rootkits, wie zum Beispiel versteckte Prozesse, ungewöhnliche offene Ports und sniffende Netzwerkkarten. Daher erkennt Chkrootkit auch einige Rootkits, die erst nach seinem letzten Update (Dezember 2003) "auf den Markt kamen".

Bei Rootkits (vgl. Kasten 1) handelt es sich meist um eine Sammlung von Tools, die es dem Angreifer vereinfachen, seine Gegenwart zu verbergen und zusätzliche Software zu installieren. Um ihnen mit Chrootkit auf die Spur zu kommen, lädt der Administrator eines Rechners das aktuelle Chkrootkit-Quelltextarchiv von [7] und übersetzt dieses:

tar xzf chkrootkit-0.43.tar.gz
cd chkrootkit-0.43
make

Eine anschließende Installation ist nicht vorgesehen, stattdessen ruft root das Programm aus dem Arbeitsverzeichnis mit dem Befehl ./chkrootkit auf. Dabei analysiert das Tool die wichtigsten Befehle des Linux-Systems und schaut sich typische Installationsorte der bekannten Rootkits an: Bei den Meldungen not infected ("nicht infiziert"), nothing/not found ("nicht/s gefunden"), nothing deleted ("nichts gelöscht") und no suspect files ("keine verdächtigen Dateien") handelt es sich um die guten Nachrichten; Befunde in Großbuchstaben wie in Abbildung 1 entlarven einen kompromittierten Rechner.

Abbildung 1: Chkrootkit hat in "su", "ifconfig" und "inetd" infizierte Dateien gefunden.

Sinnvollerweise übersetzt der Administrator Chkrootkit nicht auf dem zu testenden Rechner selbst, sondern auf einem System, über dessen unversehrten Zustand er sich sicher ist. Da das nicht immer möglich ist, stellt der Autor unter [8] vorkompilierte RPM-Pakete zur Verfügung.

Da verschiedene Rootkits immer intelligentere Methoden verwenden, um sich auf dem System zu verstecken, sollte der chrootkit-Lauf im Single-User-Modus des Betriebssystems oder (noch besser) nach dem Booten einer Live-CD durchgeführt werden. Dafür eignet sich zum Beispiel Knoppix, das Chkrootkit in seiner aktuellsten Version mitbringt. Chkrootkit bemerkt sicherlich nicht alle existierenden Rootkits, hat aber eine hohe Erkennungsrate.

Inzwischen gibt es auch spezielle Boot-CDs, die für die forensische Systemanalyse entwickelt wurden. Knoppix-STD [9] ist die bekannteste Live-CD unter ihnen. Sie enthält weitere wertvolle Werkzeuge fürs weitergehende Durchleuchten eines Rechners, zum Beispiel Sleuthkit ([10--12]).

Startet der Administrator Chkrootkit von einer CD aus, muss er vorher sicherstellen, dass die Festplattendateisysteme gemountet wurden. Zu diesem Zweck sollte er zunächst ein Verzeichnis /tmp/mount (o. ä.) erzeugen und die Dateisysteme so auf Unterverzeichnisse davon mounten, dass es unterhalb von /tmp/mount aussieht wie im Wurzelverzeichnis des laufenden Systems.

Für das System aus Abbildung 2 würde der Administrator im gebooteten Live-System die Verzeichnisse /tmp/mount, /tmp/mount/boot, /tmp/mount/home, /tmp/mount/usr und /tmp/mount/var erzeugen und die Partitionen /dev/hda5, /dev/hda1, /dev/hda6, /dev/hda7 und /dev/hda8 entsprechend einbinden. Listing 1 zeigt die nötigen Befehle.

Abbildung 2: Linux-Systeme verteilen sich häufig über mehrere Partitionen.

mkdir -p /tmp/mount/boot
mkdir /tmp/mount/home
mkdir /tmp/mount/usr
mkdir /tmp/mount/var
mount /dev/hda5 /tmp/mount
mount /dev/hda1 /tmp/mount/boot
mount /dev/hda6 /tmp/mount/home
mount /dev/hda7 /tmp/mount/usr
mount /dev/hda8 /tmp/mount/var

Anschließend teilt er chkrootkit mit der Option -r den Ort des zu untersuchenden Verzeichnisbaums mit:

chkrootkit -r /tmp/mount

Durch Einsatz einer Live-CD löst er gleichzeitig ein weiteres Problem: Chkrootkit benötigt für die Analyse des Dateisystems weitere Kommandos, darunter awk, cut und find. Der Angreifer kann das Ergebnis der Chkrootkit-Analyse verfälschen, wenn er diese Befehle austauscht. Führt der Administrator die Analyse jedoch von einer Knoppix-CD aus durch, werden die unveränderten Knoppix-Befehle genutzt.

Abbildung 3: KIS lässt sich mit einer grafischen Oberfläche fernsteuern.