Seite 4: Erkenne den Feind

Inhaltsverzeichnis

Erkenne den Feind

Wie man sich gegen Rootkits schützt, lässt sich in einem Satz zusammenfassen: Verhindern Sie, dass jemand unrechtmäßigen (Administrator-)Zugriff auf Ihre Server bekommt. In der ausführlichen Version kämen an dieser Stelle die üblichen Tipps wie: unnötige Dienste abschalten, die übrigen mit reduzierten Rechten laufen lassen, Sicherheits-Updates einspielen und so weiter.

Viele zusätzliche Schutzmaßnahmen lassen sich zwar mit Administratorrechten umgehen oder aushebeln, sie erhöhen jedoch den Aufwand für den Angreifer. Dazu gehört die Installation eines monolithischen Kernels, zu dem man keine Module nachladen kann. Des Weiteren verhindern Kernel Patches wie LIDS [4] unter Linux den schreibenden Zugriff auf den Hauptspeicher. Hier muss man allerdings den eigenen Aufwand gegen Nutzen abwägen, da bestimmte Programme, wie der X-Window-Server XFree86, diese Funktion benötigen.

Für Windows NT/2000 hat Pedestal Software mit dem Integrity Protection Driver (IPD) ein interessantes Konzept zum Schutz vor Rootkits vorgestellt. Der Open-Source-Gerätetreiber verhindert das Austauschen und Nachladen von Gerätetreibern. In der Registry kann man mit IPD keine Einträge mehr ändern oder hinzufügen [5].

Richtig knifflig wird es bei der Frage, wie man feststellt, ob der eigene Server mit einem Rootkit bestückt wurde -- zum Beispiel in der Zeit zwischen dem Bekanntwerden eines Sicherheitslochs und dem Einspielen des passenden Patches. Da auch Programmierer von Rootkits Fehler machen, kann man Rootkits manchmal selbst im Betrieb noch aufspüren. Bei Slanret wurde offensichtlich übersehen, dass das Rootkit auch im aktiven Zustand an dem Eintrag "ierk8243.sys" in den Windows-Systeminformationen unter Softwareumgebung/Treiber zu erkennen ist.

Eine weitere Möglichkeit, Rootkits im laufenden Betrieb zu erkennen, ist der Vergleich der internen Liste der nach außen geöffneten Ports mit einem externen Port-Scan. Die lokalen Server-Dienste zeigt unter Linux

netstat -plut

an. Unter Windows XP liefert

netstat -a -o

eine ähnliche Liste inklusive der Prozess-IDs. Diese lassen sich über den Task-Manager identifizieren, wenn man unter Ansicht/Spalten die PID aktiviert hat. Unter Windows 2000 gibt es die Option -o nicht, hier helfen Zusatz-Tools wie Active Ports weiter.

Zeigt ein Port-Scan zum Beispiel mit nmap den TCP-Port 65535 als offen an, dieser taucht aber in der Ausgabe von netstat nicht auf, ist die Wahrscheinlichkeit, dass man sich Ärger eingehandelt hat, schon recht hoch. Wenn netstat den zugehörigen Dienst anzeigt, dieser aber nicht zum System gehört, ist ebenfalls Misstrauen angesagt. Bei Windows gehört allerdings schon einiges an Erfahrung dazu, die "normalen" Dienste als solche zu identifizieren.

Den Beweis, dass alles mit rechten Dingen zugeht, kann ein Port-Scan jedoch nicht liefern. Dazu verstecken Backdoors ihre Aktivitäten oft zu raffiniert. Wir haben beispielsweise schon Exemplare gesichtet, die die Hintertür erst aktivierten, nachdem sie ein ICMP-Paket bestimmter Größe im Netzwerkverkehr entdeckt hatten. Andere Rootkits verzichten ganz auf Server-Dienste und bauen, nachdem sie ein Paket mit einer bestimmten Signatur gesichtet haben, eine Verbindung von drinnen nach draußen auf.

Für die Zukunft ist sogar mit so genannten "Sniffer based Backdoors" zu rechnen. Hier öffnet das Rootkit keinen Port, um mit einem Angreifer zu kommunizieren, sondern belauscht lediglich den Netzwerkverkehr im gesamten Segment. Entdeckt es ein spezielles Paket, das nicht an den kompromittierten Rechner selber adressiert sein muss, verschickt es ein passendes Antwortpaket. Diese Antwort enthält dann eine gefälschte Absenderadresse, so dass die Kommunikation nicht bis zu dem kompromittierten Rechner zurückverfolgt werden kann. Zumindest gilt dies solange, wie nicht auf Layer-2 die MAC-Adressen der beteiligten Netzwerkkarten überwacht werden.