Nach einem Einbruch auf einem Linux-Rechner kann der Administrator diesen wie ein Gerichtsmediziner untersuchen und analysieren. Der Artikel zeigt die ersten Schritte und die erforderlichen Werkzeuge dafür.

Auch wer seinen Rechner nach bestem Wissen und Gewissen absichert [1] ist nicht gefeit vor Einbrüchen und Einbruchsversuchen – es sei denn, man arbeitet ausschließlich offline. Der beste Rat lautet daher, nicht angsterstarrt wie das sprichwörtliche Kaninchen auf die Schlange zu starren, sondern sich offensiv für den Fall des Falles vorzubereiten. Dazu zählt unter anderem auch, sich mit den Methoden potentieller Angreifer vertraut zu machen.

Erste Schritte des Bösewichts

Wenn ein Einbrecher auf einem Rechner eingedrungen ist, hat er vordringlich drei Ziele: das Beseitigen der Sicherheitslücke, die Installation von Hintertüren und das Verwischen von Spuren. Im ersten Schritt wird er die Sicherheitslücke, die er selbst ausgenutzt hat, schließen, damit nicht ein weiterer Angreifer ihm den Rechner streitig macht. Böse Zungen behaupten, kompromittierte Rechner seien die am besten geschützten Rechner.

Im zweiten Schritt wird er Hintertüren und zusätzliche Software installieren. Hierbei handelt es sich zum Beispiel um weitere Angriffswerkzeuge oder Kennwortsniffer.

Anschließend folgt in der Regel der Versuch, Spuren zu verwischen und verräterische Anhaltspunkte in den Protokolldateien und im Dateisystem zu entfernen. Dem lässt sich vorbeugen, indem man die Protokolle zusätzlich auf einem zentralen Protokollserver sammelt und das Dateisystem überwacht.

Sicherheitskopien von Logdateien anderer Rechner erstellt von Haus aus bereits der klassische BSD-Syslogd, den die meisten Linux-Distributionen mitliefern, und zwar dann, wenn er auf dem zentralen Protokollserver mit dem Kommandozeilenparameter -r (für “remote”, “entfernt”) gestartet wird. Dieses “Flag” aktiviert die Fähigkeit, Protokollmeldungen über das Netzwerk entgegenzunehmen.

Bei den meisten Distributionen konfiguriert man die Startparameter der Systemdienste im /etc/sysconfig-Verzeichnis. Hier befindet sich meistens eine Datei syslog, in der der Anwender die Option hinzufügt. Bei Suse wird dabei aus der Zeile SYSLOGD_PARAMS=””

SYSLOGD_PARAMS="-r"

Nach einem Neustart des Syslogd (/etc/init.d/syslog restart) bietet der Daemon diese Funktion an. Bei anderen Distributionen wie Debian findet sich die zu ändernde Variable (hier: SYSLOGD) mit einem entsprechenden Hinweis direkt im Syslog-Startskript (bei Debian /etc/init.d/sysklogd):

# Options for start/restart the daemons
#   For remote UDP logging use SYSLOGD="-r"
SYSLOGD=""

Auf den Client-Rechnern, die ihre Protokolle an den zentralen Server schicken sollen, muss der Administrator die Syslog-Konfigurationsdatei /etc/syslog.conf anpassen. Zunächst entscheidet er, welche Meldungen er auf den Protokollserver schicken möchte. Wenn es sich um alle handelt, so genügt es, die folgende Zeile in der Datei einzufügen:

*.*     @centrallog

Den Platzhalter centrallog ersetzt man durch den Namen oder die IP-Adresse des Logservers. Nach dem Neustart des Syslogd auf dem Client schickt dieser nun alle Protokollmeldungen auch an den Server, und zwar mit dem UDP–Protokoll an Port 514.

Hat man nun bei Durchsicht der Logdateien [1] auf dem Client-Rechner das Gefühl, etwas könne nicht stimmen, kann man die dortigen Einträge mit denen in den entsprechenden Protokolldateien auf dem Logserver vergleichen – gibt es Unterschiede, liegt eine Manipulation vor. Alle Meldungen, die in der Datei /var/log/messages auf dem Logserver vom Rechner enterprise.linux-magazin.de (und nicht vom Logserver-Rechner selbst) stammen, findet man mit dem Befehl grep:

logserver # grep "enterprise.linux-magazin.de" /var/log/messages
May 21 18:37:40 enterprise.linux-magazin.de syslogd 1.4.1#11: restart.

… hier zum Beispiel den Beweis, dass der Syslogd neu gestartet wurde.

Änderungen unerwünscht

Um Manipulationen eines Einbrechers an normalerweise unveränderlichen Konfigurations- und Programmdateien auf die Spur zu kommen, überwacht man das Dateisystem am sinnvollsten mit als “System Integrity Verifier” (SIV) bezeichneten Werkzeugen wie Tripwire [2,3] und Aide [4,5]. Beide legen Informationen zu Dateien, die auf Veränderungen hin beobachtet werden sollen, in einer zentralen Datenbank ab. Durch regelmäßige Überprüfungen erkennen sie Modifikationen und alarmieren den Administrator. Dieser muss nun entscheiden, ob es sich um eine von ihm gewollte Änderung handelt oder ob ein Dritter am Werk war.

Da beide Anwendungen nach jedem Update und jeder Neuinstallation eines Pakets Änderungen melden, entsteht ein recht hoher Administrationsaufwand, der meist nur für die Überwachung von Servern im Internet betrieben wird. Für Desktop-Rechner kann zu einem gewissen Teil das Paketverwaltungssystem der Distribution einspringen.

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.

Reaktion

Wenn ein Einbruch tatsächlich stattgefunden hat und der Rechner möglicherweise kompromittiert wurde, sollte der Administrator vom Schlimmsten ausgehen. Das bedeutet, dass eine Neuinstallation einer möglicherweise nur teilweisen Reparatur immer vorzuziehen ist. Möchte man den Einbruch später analysieren, empfiehlt es sich, die Festplatten auszubauen und neue zu verwenden oder den Inhalt der Festplatten mit dd zu sichern [19].

Nach der Neuinstallation des Systems (und abschließendem Update [1]) dürfen nur nicht ausführbare Dateien aus dem Backup wieder aufgespielt werden, denn es steht zu erwarten, dass der Angreifer bereits vor dem Erstellen der Sicherungskopie Änderungen angebracht hat. Diese dürfen unter keinen Umständen auf dem neuen, sauberen System landen! Auch Konfigurationsdateien sollte der Administrator mit der nötigen Skepsis betrachten und bei fehlendem Überblick aus den Originaldateien neu anpassen.

Sobald der Rechner wiederhergestellt wurde, überprüft der Admin die Sicherheitseinstellungen und verbessert sie, um erneuten Einbrüchen auf dem Rechner vorzubeugen. Der beste Schutz ist ein aktuelles und ständig aktualisiertes Betriebssystem. Um dieses auf dem neuesten Stand zu halten, bietet sich die Einrichtung eines Cronjobs [20] an, der jede Stunde nach neuen Updates für das System sucht und diese automatisch einspielt.

Listing 2 zeigt ein Beispiel für Red Hat, während [1] demonstriert, welche Befehle für Debian und Fedora nötig sind. Suse erlaubt die Konfiguration seiner Auto-Update-Funktion via Yast [21].

Viele Anwender scheuen die automatische Aktualisierung aus Angst, dass hierbei etwas schief geht. Diese Gefahr fällt in der Praxis eher gering aus: In den letzten drei Jahren kam es beim Autor aus diesem Grund erst zweimal zu einem Ausfall eines Dienstes. Dennoch sollte man abwägen, ob man die Updates lieber per Hand einspielt und per Cronjob nur prüft, ob auf den neuesten Stand gebrachte Pakete zur Verfügung stehen. Falls das betroffene Programm wider Erwarten nach dem Update nicht mehr funktioniert, bleibt zumindest das beruhigende Gefühl, dass die Sicherheitslücke damit auch nicht mehr existiert.

#! /bin/sh
up2date -u &> /tmp/up2date.log
# Falls kein automatisches Update durchgeführt, sondern nur die
# Liste der Updates angezeigt werden soll, kann der folgende Befehl genutzt
# werden:
# up2date -l &> /tmp/up2date.log
if ! grep -q "All packages are currently up to date" /tmp/up2date.log
then
    cat /tmp/up2date.log
fi