Ihre Spuren verfolgen Den Feind erkennen II Dieser Artikel ist der zweite von drei Teilen. Der erste Teil behandelte die Tools und Methoden der "Script Kiddies", besonders wie sie nach Schwachstellen suchen und diese dann angreifen. Der dritte Teil beschreibt, was "Script Kiddies" tun, wenn sie erst mal root sind und hier besonders, wie sie ihre Spuren verwischen und was sie tun. Dieser Teil beschäftigt sich mit dem Verfolgen ihrer Spuren. Genau wie beim Militär möchte man die Bösen verfolgen und wissen was sie tun. Wir werden erklären, was man mit Hilfe der System Logs herausfinden kann und was nicht. Vielleicht kannst du herausfinden, ob du gescannt worden bist, nach was du gescannt worden bist, mit welchen Tools und ob sie erfolgreich waren. Die Beispiele hier konzentrieren sich auf Linux, können aber auf fast jede Version von Unix angewandt werden. Sei dir aber bewußt, daß es keinen garatierten Weg gibt, jeden Schritt deines Feindes zu verfolgen. Trotzdem ist dieser Artikel ein guter Anfang. Deine Logs sichern ================== Dieser Artikel beschäftigt sich nicht mit der Erkennung von Einbruchsversuchen, es gibt eine Anzahl exzellenter Quellen, die dies tun. Wenn du dich dafür interessierst, empfehle ich Programme wie den Network Flight Recorder (http://www.nfr.net) oder snort (http://www.clark.net/~roesch/security.html). Dieser Artikel ist über Informationsbeschaffung. Im speziellen: wie finde ich mit Hilfe meiner Systemlogs heraus, was der Feind tut? Du wirst überrascht sein, wieviel Informationen man in seinen Logfiles findet. Bevor wir aber über die Auswertung reden, müssen wir erst über die Sicherung der Logs reden. Deine Logfiles sind wertlos, wenn du dich nicht auf ihre Richtigkeit verlassen kannst. Das erste was die meisten Bösen tun, ist die Logfiles auf einem kompromittiertem System zu verändern. Es gibt eine ganze Reihe von Tools (z.B. cloak), die deine Anwesenheit aus den Logs herauslöschen oder gleich das ganze Logging verändern (wie veränderte syslogd-Binaries). Der erste Schritt zum Auswerten der Logs muß also deren Sicherung sein. Das bedeutet, das Du einen Remote-Logserver verwenden mußt. Egal wie sicher Dein System ist, Du kannst Logs auf einem kompromittiertem System nicht vertrauen. Der Böse kann einfach ein rm -rf /* machen und deine Festplatte komplett löschen. Dadurch wird das Wiederherstellen deiner Logs etwas schwierig. Um sich dagegen zu schützen, sollten alle Systeme doppelt loggen: einmal lokal und einmal auf einem Remote-Logserver. Ich würde empfehlen, eine eigene Maschine als Logserver abzustellen, d.h. dieser Rechner tut nichts anderes, als die Logs von anderen Systemen zu sammeln. Wenn Geld eine Rolle spielt, läßt sich mit Linux einfach ein solcher Server aufsetzen. Dieser Server sollte bestmöglich gesichert werden, mit so wenig laufenden Diensten wie möglich und Zugriff nur von der Konsole aus. Außerdem sollte sichergestellt sein, daß der UDP-Port 514 geblockt oder von einer Firewall an der Internetverbindung gesichert ist. Das schützt den Server vor falschen oder nicht autorisierten Logginginformationen aus dem Internet. Wenn man ganz gerissen sein will, kompiliert man einfach neu, so das sie eine andere Konfigurationsdatei einliest, z.B. /var/tmp/.conf. Auf diese Weise weiß der Böse nicht, wo die wahre Konfigurationsdatei liegt. Die Änderung ist durch einfaches editieren des Eintrags /etc/syslog.conf im Sourcecode zu machen. Außerdme tragen wir in unsere neue Konfigurationsdatei ein, sowohl lokal als auch auf dem Remote-Logserver zu loggen. Trotz alledem sollte man eine Standardkonfigurationsdatei /etc/syslogd.conf behalten, auf der das Logging ausschließlich lokal zu sein scheint. Diese Datei ist zwar jetzt nutzlos, wird den Bösen aber von dem Remote-Logging ablenken. Eine andere Methode deine Systeme zu schützen, ist das verwenden einer sicheren Logmethode. Eine Möglichkeit wäre es, die syslogd-Binary gegen etwas auszutauschen, was einen eingebauten Integritätscheck und eine größere Auswahl an Optionen hat, z.B. syslog-ng, zu finden auf http://www.balabit.hu/products/syslog-ng.html. Die meisten Logs die wir nutzen werden, liegen auf einem Remote-Logserver. Wie vorher erwähnt, können wir auf die Integrität dieser Dateien vertrauen, da sie auf einem Remote und gut gesichertem System liegen. Darüberhinaus ist wesentlich leichter, bestimmte Muster in den Logs zu erkennen, da alle Systeme auf einen zentralen Rechner schreiben. Man kann mit einem Blick sehen, was auf allen Systemen geschieht. Die einzige Gelegenheit, bei der man die lokalen Logfiles ansehen muß, ist um zu vergleichen, ob sie mit den Serverlogs identisch sind. So läßt sich einfach herausfinden, ob sie verändert worden sind oder nicht. Muster erkennen =============== Ob man Opfer eines Portscans geworden ist, läßt sich normalerweise an den Logs feststellen. Die meisten Script Kiddies scannen Netzwerke nach einer einzelnen Schwäche. Wenn man aus den Logs erkennen kann, das die meisten eigenen Systeme eine Verbindung auf dem immer gleichen Port zu einem immer gleichen Remotesystem aufgebaut haben, ist das sehr wahrscheinlich eine Scanattacke. Der Feind hat die Möglickeit, eine einzelne Schwachstelle auszunutzen und danach sucht er dein Netzwerk ab. Wenn er sie findet, wird er sie ausnutzen. Auf den meisten Linuxsystemen sind standardmäßig TCP-Wrapper installiert. Die meisten der Verbindungen werden wir also in /var/log/secure finden. Bei den anderen Linux- Varianten können wir alle inetd Verbindungen loggen indem inetd mit dem "-t" Parameter gestartet wird. Ein typischer Schwachpunkt-Scan würde so ähnlich aussehen wie das Beispiel weiter unten. Hier sucht jemand nach der wu-ftpd Schwäche: /var/log/secure Apr 10 13:43:48 mozart in.ftpd[6613]: connect from 192.168.11.200 Apr 10 13:43:51 bach in.ftpd[6613]: connect from 192.168.11.200 Apr 10 13:43:54 hadyen in.ftpd[6613]: connect from 192.168.11.200 Apr 10 13:43:57 vivaldi in.ftpd[6613]: connect from 192.168.11.200 Apr 10 13:43:58 brahms in.ftpd[6613]: connect from 192.168.11.200 Man sieht, wie die Adresse 192.168.11.200 das Netzwerk absucht. Beachte, wie der Angreifer die IPs nacheinander absucht (das ist nicht immer der Fall). Hier liegt der Vorteil eines Logservers: man kann einfacher Muster im Netzwerk erkennen, da alle Logs hier zusammenlaufen. Die wiederholten Verbindungen zu Port 21 (ftp) zeigen an, das wahrscheinlich nach dem wu-ftpd Schwachpunkt gesucht wurde. Wir haben also gerade herausgefunden, wonach der Böse gesucht hat. Scans tendieren oft dazu in Wellen zu kommen. Jemand veröffentlicht Code, um eine imap-Schwäche auszunutzen und plötzlich kommt ein Schwall von imap-Scans in die Logs. Nächsten Monat ist es dann vielleicht ftp. Eine hervorragende Quelle für aktuelle Schwachpunkte ist http://www.cert.org/advisories. Manche Tools können auch gleichzeitig nach mehreren Schwächen suchen, man sieht also manchmal eine einzelne Quelle Verbindung zu mehreren Ports aufnehmen. Was sind die Tools? =================== Manchmal kann sogar die Tools erkennen, die benutzt werden, um das Netzwerk zu scannen. Einige der einfacheren Tools scannen nach nur einem Schwachpunkt, wie z.B. ftp-scan.c. Wenn nur ein einzelner Port oder Schwachpunkt im Netzwerk gescannt wird, wird wahrscheinlich ein solches "Einzeltool" benutzt. Es existieren aber Tools, die nach einer ganzen Reihe von Schwachpunkten suchen. Die beiden populärsten Tools sind sscan (http://www.ben2.ucla.edu/~jsbach) von jsbach und nmap (http://www.insecure.org/nmap) von Fyodor. Ich habe diese beiden Tools ausgesucht, da sie die beiden "Kategorien" von Scanningtools repräsentieren. Ich empfehle sehr, da du diese Tools gegen dein Netzwerk einsetzt, du könntest über die Ergebnisse überrascht sein :) * sscan repräsentiert das Allzweck-Script Kiddie-Scanningtool und ist wahrscheinlich eines der besten. Es testet ein Netzwerk schnell auf eine Reihe von Schwachstellen (inklusive cgi-bin). Es ist einfach anzupassen und erlaubt so Testverfahren für neue Schwächen hinzuzufügen. Man muß dem Tool nur ein Netzwerk und eine Subnetzmaske geben und es erledigt den Rest. Der Anwender muß jedoch root sein um es zu nutzen. Die Ausgabe ist extrem einfach zu deuten (darum ist es so beliebt). Es gibt eine knappe Zusammenfassung vieler verwundbarer Dienste. Alles, was man zu tun hat, ist sscan gegen ein Netzwerk einzusetzen, die Ausgabe nach dem Wort "VULN" zu durchsuchen und den "Angriff des Tages" zu starten. Es folgt ein Beispiel, in dem sscan gegen das System mozart (172.17.6.30) eingesetzt wird: otto #./sscan -o 172.17.6.30 --------------------------<[ * report for host mozart * <[ tcp port: 80 (http) ]> <[ tcp port: 23 (telnet) ]> <[ tcp port: 143 (imap) ]> <[ tcp port: 110 (pop-3) ]> <[ tcp port: 111 (sunrpc) ]> <[ tcp port: 79 (finger) ]> <[ tcp port: 53 (domain) ]> <[ tcp port: 25 (smtp) ]> <[ tcp port: 21 (ftp) ]> --