Suche mit Pferdefuß
Eine weitere Anlaufstelle bei der Jagd nach Rootkits ist der Hauptspeicher des möglicherweise infizierten Rechners: Analog zu Viren lassen sich auch Rootkits über charakteristische Signaturen aufspüren. Unter Linux liefert "strings /dev/kmem" die Grundlage für solche Scans. Genau wie bei Viren-Scannern gilt auch hier die Einschränkung, dass man auf diesem Weg nur bekannte Rootkits zuverlässig aufspüren kann. Um die Suche nach bekannten Rootkits zu erleichtern und zu automatisieren, hat das Projekt chkrootkit [6] ein Skript für Linux-Systeme erstellt, dass diese und weitere Scans zusammenfasst. In der Version 0.40 findet es immerhin 47 verschiedenen Rootkits, Würmer und bösartige, ladbare Kernel-Module. Dabei greift es auf diverse System-Utilities zurück, die man allerdings auch von einem anderen Medium laden lassen kann. Um auch Library-Rootkits außen vor zu halten, sollten diese externen Programme dann auch statisch gelinkt sein. Dazu muss man sie in der Regel allerdings neu übersetzen. Sicherheitsbewusste Administratoren führen chkrootkit regelmäßig und nach jedem Einspielen von Security-Patches aus. Hilfreich sind auch Tools wie der File System Integrity Checker Tripwire [7]. Existiert ein garantiert integrer Tripwire-Datensatz, kann man damit nachträgliche angelegte oder modifizierte Dateien aufspüren und genauer inspizieren. Auch Intrusion Detection Systeme wie Snort [8] können Rootkits entdecken. Mit passenden Signaturen registriert und meldet ein solches netzwerkbasiertes IDS schon den Download des Rootkits oder dessen Netzwerkaktivitäten. All diese Tests haben jedoch einen gewaltigen Pferdefuß: Sie können zwar einen positiven Befund liefern -- also ein Rootkit entdecken -- aber keine Sicherheit geben, dass das System tatsächlich sauber ist. Dafür muss man in den sauren Apfel beißen und das System von einem garantiert sauberen Medium booten. Beim Verdacht, dass ein Rootkit unter Windows als Gerätetreiber, also im Betriebssystemkern aktiv ist und nicht von Virenscannern gefunden werden kann, hilft oft schon, das System im abgesicherten Modus zu starten und erneut die Festplatte scannen lassen. Besser ist es jedoch, wenn man gleich von einer Rettungs-CD bootet. Ohne den schützenden Mantel des aktiven Rootkits können Viren-Scanner und Tools wie Tripwire verdächtige Dateien zuverlässig aufspüren. Letzteres liefert selbst bei noch unbekannten Root-Kits einen zuverlässisen Befund -- man muss dazu allerdings allen Veränderungen seit dem letzten Tripwire-Lauf nachgehen. Aufräumarbeiten Hat man ein Rootkit auf dem eigenen Server entdeckt, steht einiges an Arbeit an. Denn es genügt keineswegs, die von Tripwire oder einem Viren-Scanner inkriminierten Rootkit-Dateien zu löschen. Als erstes gilt es, zu ermitteln, wie der Einbrecher in das System gelangt ist, damit man den Rechner gegen erneute Angriffe absichern kann. Außerdem benötigt man den Zeitpunkt des Einbruchs, um festzustellen, welches der Backups noch sauber ist. Bei beidem hilft es, wenn man die Log-Meldungen des Servers an ein externes, gesichertes System weitergeleitet hat. Aus den Log-Dateien lassen sich in vielen Fällen der Zeitpunkt des Einbruchs und der dafür verwendete Dienst ermitteln. Anhand der Namen der ausgetauschten und neu installierten Dateien findet man über Suchmaschinen in der Regel recht schnell den Namen des verwendeten Rootkits heraus. Für die meisten Standard-Kits stellen die Hersteller von AV-Software Anleitungen zum sicheren Entfernen bereit. Wer diesen folgt und darauf verzichtet, ein garantiert sauberes Komplett-Backup einzuspielen, sollte dabei jedoch beachten, dass der Einbrecher unter dem Schutz des Rootkits weitere Veränderungen am System vorgenommen haben kann. So kommt es durchaus vor, dass ausgebuffte Cracker für solche "Notfälle" eine zweite, unabhängige Hintertür einbauen. Im Falle einer Entdeckung gelangen sie dann zum Beispiel über ein dezent modifiziertes CGI-Skript sofort wieder ins System. Denn wenn in diesen Kreisen etwas mehr Ruhm und Ehre einbringt, als der Einbruch in einen Rechner, dann ist es das Zurückerobern eines gerade gesäuberten Systems und die damit verbundene Demütigung des verantwortlichen Administrators. (ju)
