Egal, wie sehr man sich bemüht, Server abzusichern und vor Script Kiddies und Hackern zu schützen, früher oder später passiert es jedem Administrator, dass in die Maschinen unter seiner Obhut eingebrochen wird. Dann gilt es, den Schaden zu analysieren und gegebenenfalls Beweise zu sichern, bevor das System wieder hergestellt wird. Doch dies geht nur, wenn man gut vorbereitet ist, da man sonst die durch die Einbrecher verursachten Schäden möglicherweise noch vergrössert.
Um auf etwaige Vorfälle in kurzer Zeit effektiv reagieren zu können, müssen im Vorfeld einige Fragen geklärt werden, damit im Falle eines Worst Case die Problemlösung nicht durch organisatorische Unwägbarkeiten verzögert wird:
• Wer ist für welches System verantwortlich, wer ist Ansprechpartner?
• Wer hat welche Zugänge zum System, und wie kann man diese Personen erreichen, falls man selber nicht über die nötigen Zugänge verfügt?
• Wer ist der Sicherheitsverantwortliche der Firma/des Rechenzentrums?
• Existiert ein Notfallplan und wenn nicht, wer erstellt ihn?
• Wie sieht es mit der Rückendeckung von Seiten des Chefs aus, wenn unliebsame oder weitreichende Entscheidungen getroffen werden müssen (etwa kurzfristige Abschaltung von Diensten aus Sicherheitsgründen, alle Benutzer müssen kurzfristig ihr Passwort ändern)?
• Was für Daten und Beweise müssen für eine allfällige Strafverfolgung gesichert werden?
• Wie sieht es mit der Befugnis aus, in persönliche oder personenbezogene Daten Einblick halten zu dürfen?
Prävention ist das A und O bei Netzwerk- und Systemadministration. Dies umfasst nicht nur das (am besten tägliche) Aktualisieren aller Computer, sondern auch das Abschalten aller benötigten Dienste, um potentielle Probleme und die Angriffsfläche zu verringern, sowie auch das Aufteilen öffentlicher und interner Dienste auf verschiedene Maschinen. Last but not least gilt es auch, den Anwendern nur sehr selektiv Zugang zu den entsprechenden Ressourcen zu gewähren – schliesslich muss nicht jeder Benutzer auf jedes System Zugriff haben. Weiter sollten Logs zentral auf einem speziell gesicherten Server gesammelt werden, damit Angreifer ihre Spuren nicht mehr verwischen können. Zudem sollten Scripte zur automatischen Loganalyse verwendet werden, die bekannte (reguläre) Ereignisse ausfiltern und nur unbekannte Logs zur manuellen Auswertung weitergeben.
Im Gegensatz zum Einbruch zu Hause, wo man an den durchwühlten Schränken erkennt, dass ein Langfinger einem einen Besuch abgestattet hat, ist dies bei Computern nicht immer so einfach, denn in der Regel hinterlassen nur Script Kiddies ein Chaos. Je besser die Fähigkeiten der jeweiligen Angreifer sind, umso schwieriger ist ein Angriff mit blossem Auge zu erkennen. Hilfreich sind dabei Tools, die regelmässig die Checksummen von sämtlichen Dateien (oder zumindest den wichtigsten) auf einem Computer durchführen. Werkzeuge wie TripWire oder AIDE ermitteln anhand von kryptographischen Checksummen wie MD5 oder SHA1, ob eine Datei verändert wurde nicht. Stimmt diese Summe mit der im System gespeicherten nicht überein, schlagen die Programme Alarm.
Ein Einbruch läuft meistens nach demselben Schema ab. Dieses zu kennen, ist hilfreich, da man so Anhaltspunkte bekommt, wo man seine Suche nach Ursachen und Beweisen beginnen kann:
1. Footprinting: Der Angreifer sucht sich ein Ziel aus, indem er beispielsweise mit Scannern IP-Bereiche abgrast.
2. Enumeration: Port- und Protokoll-Scans forschen nach vorhandener Software und potentiell verwundbaren Diensten.
3. Suche nach von Exploits auf Basis des erworbenen Wissens zur späteren Anwendung.
4. Einrichtung einer Hintertür, über die man auch noch ins System gelangt, wenn das ursprüngliche Loch, über eingedrungen wurde, geschlossen wird.
5. Je nach Fähigkeiten des Angreifers Verwischung der Spuren.
Wenn es ein Hacker einmal geschafft hat, in ein System einzudringen, muss man sich als Administrator vor allem an eine Grundregel halten: Don't panic! Panikreaktionen helfen nicht weiter und verleiten zu Fehlentscheidungen. Deshalb sollte man den vorbereiteten Notfallplan zur Hand nehmen, der das weitere Vorgehen bestimmt. Zudem sollte ab sofort ein 4-Augen-Prinzip gelten: Wenn möglich sollte ein zweiter Administrator hinzugezogen werden, der später als Zeuge aussagen und/oder mit seiner Erfahrung Hilfestellung geben kann, wenn es darum geht, das System zu sezieren. Zudem sollten die betroffenen Systeme nicht ausgeschaltet werden, da sich unter Umständen brauchbare Informationen im Hauptspeicher des Systems befinden können. Statt dessen sollte das System isoliert und vom Netz genommen werden.
Um ein Abbild von Speicher und Platten des Systems erzeugen zu können, muss genügend Plattenplatz zur Verfügung gestellt werden. Dann wird versucht, herauszufinden, ob das System tatsächlich kompromittiert ist, um welche Art von Angriff es sich handelt und wie weitreichend der Vorfall ist, damit im Anschluss mittelbar oder unmittelbar betroffene Personen informiert werden können.
Bevor man nun zur Komplett-Analyse des Vorgangs übergeht, sollte bedacht werden, ob sich der Aufwand jeweils lohnt. Denn vor allem kleinere Zwischenfälle werden kaum in einer Strafverfolgung enden, für welche die kompletten Informationen benötigt werden. Entschliesst man sich dennoch zur Komplett-Analyse, erzeugt man als nächstes einen Dump des Speichers und der Platten und legt die Dateien auf ein externes System. Interessant ist auch eine Auflistung der laufenden Prozesse. Mit Hilfe von verschiedenen Tools kann nun an die Analyse der gesicherten Platten beziehungsweise Speicher gegangen werden.
Gesucht sind primär alle Änderungen im System, um nachvollziehen zu können, was der Angreifer wann gemacht und welche Dateien er geändert/kompromittiert hat. Dies geschieht am besten mit Hilfe geeigneter Tools, die beispielsweise auf fertigen Boot-CDs bereitliegen und sofort eingesetzt werden können. Eine Sammlung von solchen Tools ist «The Sleuth Toolkit», welches unter anderem auf dem betagten, aber immer noch hilfreichen TCT (The Coroner's Toolkit) basiert. Neben Tools, um Modifikations- und Zugriffszeiten auf Dateien (also eine Historie) auszulesen und gelöschte Dateien in beschränktem Umfang wiederherzustellen, bietet es auch ein grafisches Front-end («Autopsy»), mit dem man die ausgewerteten Dateien in einer lesbaren Form darstellen kann.
Hat man erstmal Spuren des Hackers gefunden, müssen diese noch ausgewertet werden. Hat der Hacker Backdoors installiert, wenn ja – wie funktionieren diese? Hat der Hacker bestehende Programme ersetzt und wenn ja, wo liegt der Unterschied zu den Originalen? Was hat der Hacker gesucht? Hat er es gefunden? Wurde der Server in ein Bot-Netz integriert? Das allerwichtigste ist jedoch immer herauszufinden, wie der Hacker in das System eingedrungen ist, damit das Loch so schnell wie möglich gestopft werden kann.
Allerdings kann dies durchaus zu einer äusserst anspruchsvollen Aufgabe werden, insbesondere, wenn man nicht nur Opfer von Script Kiddies geworden ist, die gerne auf fertige Toolkits zurückgreifen, die sich beispielsweise mit dem Toolset chkrootkit erkennen lassen. Erfahrene und gute Hacker verstecken nicht nur ihre Modifikationen im Kernel und anderen unauffälligen Prozessen, sondern bemühen sich auch sonst, möglichst nicht aufzufallen, um das Risiko, entdeckt zu werden, zu minimieren.
Ein oftmals unterschätzter Faktor für die Analyse kompromittierter Systeme und für die Sicherung von Beweisen ist das Wissen um die richtige Uhrzeit. Denn nur, wenn alle Systemuhren synchron laufen und die korrekte Zeit anzeigen, ist die Auswertung, Korrelation und Nachverfolgung von Vorfällen möglich. Zu diesem Zweck empfiehlt es sich, einen zentralen Zeitserver im Netzwerk zu positionieren, mit dem sämtliche anderen Server im Netzwerk ihre Systemzeit regelmässig abgleichen können.
Gregor Longariva (longariva@ softbaer.de) ist Solaris-Administrator am Rechenzentrum der Universität Erlangen-Nürnberg und Spezialist für die Unix-Betriebssysteme Linux, OpenBSD und Solaris.
