IT-Forensik und Incident Response

Transkript

1 IT-Forensik und Incident Response Hochschule Luzern (HSLU) Departement Technik & Architektur Betreuer: Prof. Dr. Bernhard Hämmerli Autoren: Bruno Leupi, Silvan Rösli Version: 1.0 Datum: 11. Februar 2015

2 Abstract Das folgende Termpaper befasst sich mit dem Thema IT-Forensik und Incident-Response. Es beinhaltet das Vorgehen bei einem Angriff durch Hacker und zeigt hauptsächlich die Spurensuche auf. Es wird zudem beantwortet wie ein möglicher Incident-Response-Plan aussehen könnte. Dazu wurden drei verschieden Laborversuche und einiges an Internetrecherche durchgeführt. Es zeigte sich, dass sich jede Firma auf einen Angriff vorbereiten kann und trotz Verschleierung des Angriffs, vielfach doch Spuren gefunden werden können. Jedoch sollte man den Fokus klar auf präventive Massnahmen legen.

3 Inhaltsverzeichnis 1 Einleitung 1 2 Zielsetzung 2 3 Ausgangslage 2 4 Labordurchführung Versuch 1: Spurensuche auf Linux-System Einleitung Aufbau Erwartete Resultate Durchführung Eingetroffene Resultate Versuch 2: Spurensuche auf Windows-System Einleitung Aufbau Erwartete Resultate Durchführung Eingetroffene Resultate Versuch 3: Intrusion Detection mit Zyxel IDP Einleitung Aufbau Erwartete Resultate Durchführung Eingetroffene Resultate Incident Response Plan Einleitung Vorbereitung Entdeckung Analyse Eindämmung Kontrolle gewinnen Nachbearbeitung Lessons-Learned 16 7 Schlusswort 17 Literatur 18 1

4 1 Einleitung Internet der Nerv der Zeit. Das Internet ist allgegenwärtig, ständig tauchen neue Schreckensmeldungen auf. Sony: Kreditkartendaten gestohlen oder Nintendo: Server gehackt. Solche Meldungen sind an der Tagesordnung. Die Kriminalstatistik zeigt eine erschreckende Entwicklung auf (Allen, 2011). Das Ziel der Computersicherheit ist es, dieser Entwicklung entgegenzuwirken. Dazu gehört es, richtig zu reagieren, falls ein solcher Angriff ausgeführt wird. Im Fachjargon wird dies Incident Response genannt. Aber auch das Entdecken (Intrusion Detection, IT-Forensik) sowie die Prävention (Intrusion Prevention) dürfen nicht vernachlässigt werden. Diese Arbeit befasst sich hauptsächlich mit IT-Forensik auf Computerebene (siehe Kapitel 4), sowie mit dem Erstellen eines Incident-Response Planes (IRP) (siehe Kapitel 5). 2 Zielsetzung Eine spannende Sache, einen Hackerangriff zu simulieren. Daraus die richtigen Schlüsse zu ziehen und das System vor Angriffen zu schützen, will gelernt sein. Es erscheint wichtiger denn je, sein System abzusichern. Was ist heutzutage nicht von einem Netzwerk abhängig? Die totale Vernetzung macht uns verletzlich. Dieses Themenpapier zeigt auf, mit welchen einfachen Mitteln ein Grossteil der Verletzlichkeit eines Netzwerksystems verhindert werden kann. Denn mit ein wenig Recherche im Internet und den richtigen Tools, kann auch ein Laie zum Hacker werden. Die Möglichkeiten in ein System einzudringen und Sicherheitslücken auszunutzen sind vielfältig. Die Palette an Tools ebenso, diese reicht von Adware, Spyware, Viren und Würmern bis hin zu Trojanern. Jede dieser Malware hat nur das eine Ziel: Schaden anzurichten. Um für etwaige Angriffe gerüstet zu sein, wird ein IRP benötigt. Ein mögliches Vorgehen wird erarbeitet und vorgestellt. Klar gibt es nicht den einen richtigen Plan, es ist nur eine von vielen Varianten. Um bereits bei ersten Anzeichen von Ungereimtheiten zu reagieren, gibt es das Intrusion Detection System (IDS). Ein solches wird ebenfalls in einem abgeschlossenem Netzwerk ausprobiert und auf Tauglichkeit geprüft. 2

5 3 Ausgangslage Als Grundlage für diese Arbeit dient ein fiktives Szenario: Als Administrator eines KMU wird vermutet, dass ein Hacker auf ein System mit Customer Relationship Management (CRM) Daten eingedrungen ist. Nun gilt es einerseits Spuren zu diesem Angriff zu suchen und andererseits einen Plan zu erstellen, wie ein solcher Fall behandelt werden soll. Welche gerichtsverwertbaren Beweise lassen sich sammeln und welche Unterstützung seitens der Behörden gibt es. In einem ersten Versuch, wird mithilfe der Linux-Distribution Back Track 5 1 versucht in einem Metasploitable Linux eine Sicherheitslücke so auszunutzen, dass ein Root Access erreicht wird. Das heisst, es wird die gesamte Systemkontrolle übernommen. Während und auch nach dem Zugriff auf das System wird nach hinterlassenen Spuren gesucht. Es wird versucht, möglichst viel über den Angreifer und die getätigten Aktivitäten herauszufinden. Ähnlich wie im ersten Versuch, wird in einem weiteren Versuch ein Angriff auf ein Windowssystem simuliert. Auch hier wird versucht möglichst viele Spuren des Eindringlings zu eruieren. Bestenfalls wird der Eindringling in flagranti erwischt. In diesem Fall kann sofort reagiert werden, um weitere Schäden zu verhindern. Intrusion Prevention heisst das Thema des dritten Versuchs. Dazu wird eine IDP-10 von Zyxel verwendet. Das IDS überwacht den Netzwerktraffic in Echtzeit. So kann bei Alarm innerhalb kürzester Zeit reagiert werden und im schlimmsten Fall sogar das Netzwerk nach aussen hin getrennt werden. 1 Back Track 5 speziell für Penetrationstests aufgesetztes Linux. Es verfügt über eine grosse Anzahl von Tools um Sicherheitslücken zu finden und auszunutzen. 3

6 4 Labordurchführung 4.1 Versuch 1: Spurensuche auf Linux-System Einleitung Im Versuch 1 wird ein Einbruch auf ein Linux-System durchgeführt. Anschliessend wird mit Hilfe von Bordmitteln versucht diesen Einbruch zu entdecken. Es wird ebenfalls versucht, so genau wie möglich, zu ermitteln welche Daten entwendet wurden. Als Leitstruktur wird eine Anleitung des Deutschen Forschungsnetz vom Computer Emergency Response Team (DFN CERT, o. J.-b) verwendet Aufbau Das zu attakierende System (Alice) ist in diesem Versuch ein Metasploitable Linux 1. Der Hacker (Mallory) bricht mit einem Back Track 5 in das System ein und versucht Daten zu lesen. Dabei soll er das Netzwerk scannen, um sein Ziel zu finden. Das Netzwerk ist in diesem Fall ein privates Klasse C Netzwerk. Einfachheitshalber wird im Versuch auf einen DHCP-Server verzichtet. Alice erhält die IP-Adresse /24, Mallory / Erwartete Resultate Man kann erwarten, dass man Mallory während des Einbruchs als aktiven Benutzer sieht. Folglich sollte der Benutzerzugriff auch anschliessend geloggt sein. Die aktuellen Tätigkeiten von Mallory sollten während des Versuchs ebenfalls in der Prozesstabelle ersichtlich sein. Schlussendlich sollte man alle ausgeführten Befehle im Log nachschauen können, um Rückschlüsse auf die gelesenen Daten zu erhalten. Es ist allerdings nicht ausgeschlossen, dass Mallory die Spuren verwischt und sich die Suche nach Hinweisen schwieriger gestaltet Durchführung Der Ablauf von Mallory wird Anhand eines Tutorials von Dieterle (2012) durchgeführt. 1 VMWare Appliance verfügbar unter 4

7 Mit einem Script wird eine Logdatei erstellt (siehe Abbildung 1). Der gesamte Versuchsablauf wird auf dem Metasploitable Linux in diese Datei geschrieben. So lässt sich das ganze Experiment aufzeichnen und auch später noch Schritt für Schritt durchgehen. Der erste Eintrag in diese Datei beinhaltet den Benutzernamen und das Datum. Abbildung 1: Aufzeichnung starten mit script <filename> Der erste Befehl who sollte die aktiven Benutzer anzeigen. Auf dem Metasploitable Linux wird aber kein einziger aktiver Benutzer aufgeführt. Wird der Befehl allerdings von Mallory auf dem Back Track-System ausgeführt, wird Admin als aktiver Benutzer angezeigt. Admin ist der Benutzer des Metasploitable Linux. last -10 ist der Befehl um die letzten zehn Benutzer aufzuführen. Auch hier werden wir nicht fündig und sehen den fremden Systemzugriff nicht. Mit dem Befehl cat /etc/passwd werden die User-IDs aufgelistet (siehe Abbildung 2). Eine 0 sollte nur der root-eintrag enthalten. Hier sind ebenfalls keine verdächtigen Einträge festzustellen. Der nächste Befehl, ps -a, listet die aktuellen Prozesse auf. Ein auffälliger Eintrag wäre beispielsweise, wenn ein Prozess aussergewöhnlich viel Rechenzeit verbrauchen würde. Ausserdem deutet eine sehr hohe Prozess-ID obwohl der Prozess seit Systemstart laufen sollte auf eine Ungereimtheit hin. Allerdings fällt hier kein Prozess negativ auf. Zum ersten Mal fündig werden wir beim Auflisten der Netzwerkverbindungen. Angezeigt werden diese, wie Abbildung 3 zeigt, mit dem Befehl netstat -tupan. Hier gibt es zwei Einträge mit der IP-Adresse , die hohe Ports benutzen. Der Default-Port für TCP wäre 443. Hier werden aber die beiden Ports und verwendet. Bei dieser Entdeckung müsste in der Praxis sofort reagiert werden. Um den Stand so einzufrieren, sollte (falls möglich) direkt die Stromversorgung des Rechners gekappt werden. Mit der 5

8 Abbildung 2: Ausgabe von cat /etc/passwd und ps bzw. ps -a IP-Adresse und somit auch MAC-Adress hat man nun weitere Anhaltspunkte, um den Eindringling zu finden. Führt man den Befehl lsof -i aus, werden alle geöffneten Internet-Sockets aufgelistet. Einmal mehr kann nichts Aussergewöhnliches gefunden werden. Das gleiche Bild, wenn die Shell-History, die File System Disk Space Usage und das Dateiverzeichnis in temp angesehen werden. Keine Einträge, die auffallen würden. File /core zeigt die Coredumps an, also alle abgestürzten Prozesse. Ein Angriff ist selten beim ersten Mal erfolgreich, so könnten hier verdächtige Prozesse ersichtlich sein. Als nächstes werden bestehende Konfigurationsdateien inspiziert. Hier können unauffällige Hintertüren geöffnet worden sein. Dies ist allerdings nicht der Fall Eingetroffene Resultate Bei diesem Versuch wurden sehr wenige Anhaltspunkte entdeckt. Einzig mit dem Befehl netstat -tupan konnte erfolgreich die IP des Eindringlings festgestellt werden. Mit der IP kann jedoch nicht zielgenau ermittelt werden, von welchem Computer aus, der Angriff durchgeführt wurde. Auch die MAC-Adresse die mit der IP gemappt werden kann, kann gefälscht sein und bietet ebenfalls keine grosse Hilfe. Nur ein Teilerfolg. 6

9 Abbildung 3: Ausgabe von netstat -tupan 4.2 Versuch 2: Spurensuche auf Windows-System Einleitung Versuch 2 läuft ähnlich wie Versuch 1 (siehe 4.1) ab. Da Windowssysteme nur über begrenzte Bordmittel verfügen, werden in diesem Versuch vielfach zusätzliche Programme von Sysinternals 1 benutzt. Wie auch im Versuch 1 dient hier eine Anleitung vom DFN CERT (o. J.-c) als Leitfaden Aufbau Der Aufbau von Versuch 2 ist nahezu identisch wie bei Versuch 1. Anstelle des Metasploitable Linux wird hier ein Windows XP SP2 verwendet. Es ist weder ein Virenschutz installiert, noch die Firewall aktiviert. Mallory soll in diesem Versuch die Datei C: Dokumente und Einstellungen Administrator crm.bin herunterladen. Auch hier wird einfachheitshalber auf ein komplettes Netzwerk verzichtet und dieselben IP-Adressen vergeben

10 4.2.3 Erwartete Resultate Wie auch im vorangegangenen Versuch wird hier erwartet Mallory in flagranti zu erwischen. Auch anschliessend sollte der Benutzerzugriff sowie die ausgeführten Befehle noch ersichtlich sein. Zusätzlich sollte man Hinweise auf den Download der Datei (siehe 4.2.2) finden. Wie auch im Versuch 1 kann es auch hier sein, dass Mallory viele Spuren wieder verwischt Durchführung Der Ablauf von Mallory wird anhand eines Videotutorials von Lirio (2012) durchgeführt. Nachdem die Verbindung erfolgreich aufgebaut wurde, kann nun mit der Suche nach der Datei crm.bin gestartet werden. Dazu wird search -f crm.bin verwendet. Nach wenigen Sekunden wird die Datei lokalisiert. Der Adresspfad lautet: C: Dokumente und Einstellungen Administrator crm.bin und die Datei ist 100 Megabyte gross. Um die Datei herunterzuladen, wird download <path> verwendet. Bereits nach zwei Minuten ist die 100 Megabyte grosse Datei kopiert. Nun geht es auf auf dem Windows-System auf Spurensuche. Wiederum wird der gesamte Versuchsablauf in eine Logdatei geschrieben. Abbildung 4: psloggedon von Sysinternals Als erstes Datum und Zeit. date /t >> log.txt für das Datum und time /t >> log.txt 8

11 für die Uhrzeit. Für die Suche wird das Windows-Toolkit SysinternalsSuite verwendet, beginnend mit psloggedon (siehe Abbildung 4). Dies zeigt die zuletzt angemeldeten Benutzer an. In unserem Fall lässt sich jedoch kein fremder Benutzer feststellen. Ebenfalls anzeigen lassen sich Failed Remote Logins mit ntlast -f -r. Auch hier ist kein fremder Benutzer aufgeführt. Nun wird eine Detailanzeige des lokalen Logins aufgerufen: ntlast -v. Diese zeigt keine Auffälligkeiten. Hier ist zu beachten, dass diese Aufzeichnung manuell gestartet werden muss. Diese Einstellung lässt sich im Group Policy Editor bewerkstelligen. Die laufenden Prozesse lassen sich mit pslist überprüfen. Auffälligkeiten sind ungewöhnlich viel Rechenzeit, eine falsche Benutzerkennung oder läuft ein Prozess mit einer ungewöhnlichen Shared-Library. All dies ist hier nicht der Fall. Die ungewöhnliche elapsed time kommt daher, dass das Windows-System aus einem Snapshot wiederhergestellt wurde. Die offenen Netzwerkverbindungen werden mit tcpvcon -anc überprüft. Hier lässt sich der Einbruch von Mallory feststellen (siehe Abbildung 5). Die IP-Adresse Abbildung 5: TCP/UDP endpoint viewer ist eindeutig ein Eindringling. Spätestens jetzt muss sofort die Notbremse gezogen werden. Nachdem das System gesichert wurde, kann mit der Spurensuche weitergefahren werden. nbtstat -c zeigt die Bereichskennung an. Jetzt wird überprüft, ob eine Umleitung von einem Hostnamen zu einer IP-Adresse installiert wurde. C: WINDOWS system32 9

12 drivers etc > type hosts listet diese auf. Der nächste Schritt führt zu den Windows Eventlog. Diese können mit dem dumpel Tool überprüft werden. Als nächstes sollte die lokale Firewall angesehen werden. In diesem Versuch wurde sie allerdings ausgeschaltet. Der Befehl dazu lautet regedit /s firewall.reg. Besondere Bedeutung hat die Überprüfung der sogenannten Autorun Keys. autorunsc führt das Toll von Sysinternals aus. Mit psinfo -d lassen sich eingehängte Platten überprüfen. Diese können als Verteilstation illegaler Raubkopien missbraucht werden. Dies führt zur weiteren Spurensuche im Dateisystem. Beispielsweise werden ähnlich klingende Dateien in versteckten Ordnern deponiert. Dies kann ein Rootkit oder auch ein Virus sein Eingetroffene Resultate Wie erwartet, konnte Mallory in flagranti erwischt werden. Mit der IP-Adresse hat man einen wichtigen Anhaltspunkt, um den Angriff rückverfolgen zu können. Nicht eruiert werden konnte, was der Eindringling angestellt hat. Wider Erwarten gab es keine Hinweise auf die kopierte Datei crm.bin. Allerdings können schon die minimalsten Sicherheitseinstellungen die meisten Angriffe vereiteln. Der Angriff hier wäre bei eingeschalteter Windows-Firewall nicht möglich gewesen. 4.3 Versuch 3: Intrusion Detection mit Zyxel IDP Einleitung Dieser Versuch befasst sich mit dem IDS ZyXEL IDP-10. In einem abgesicherten Netzwerk wird die IDP-10 eingebaut. Es werden verschiedene Angriffe auf das Netzwerk simuliert. Dazu wird protokolliert, ob und wie weit die IDP-10 in das Geschehen eingreifen kann Aufbau Für das gesicherte Netzwerk werden ein Host und die IDP-10 von ZyXEL verwendet. Der Host, Alice, bekommt bei diesem Versuch die IP-Adresse und ist am LAN- Port der IDP-10 angeschlossen. Auf dem WAN-Port ist Mallory mit der IP verbunden. 10

13 4.3.3 Erwartete Resultate Es kann erwartet werden, dass die IDP-10 die netzwerkbasierten Angriffe erkennen und blockieren kann. Zudem wird alles in einem Protokoll festgehalten. Das Protokoll lässt sich auswerten und als Beweismittel sichern Durchführung Die Einrichtung der IDP-10 stellt sich als Hürde heraus. Die erste Schwierigkeit ist, auf das Webinterface der IDP-10 zu gelangen. Nach einigen Neustarts und umkonfigurieren der Interfaces klappt der Zugriff über den LAN-Port. So weit ist der Versuchsaufbau gelungen. Danach wird in der Pre-defined Policy überprüft, wie die Einstellungen bezüglich der Ping-Anfragen sind. Die Action bezüglich ICMP PING *NIX ist Log + Drop Packet + Block Connection. So weit so gut, jedoch werden die Ping-Packete immer noch weitergeleitet. Also geht die Fehlersuche weiter. Die entscheidende Einstellung befindet sich unter General - State. Hier muss unter dem Reiter Device Operation State Setup vom Modus Monitor in den Inline-Modus gewechselt werden. Ansonsten werden die Datenströme zwar analysiert und auch protokolliert, aber nicht blockiert. Nach dem diese Einstellung geändert ist, werden alle Ping-Anfragen zuverlässig geblockt (Abbildung 6). Ein IDS untersucht im Gegensatz zur Firewall nicht nur die Signatur, sondern scannt den ganzen Inhalt eines jeden Paketes. Abbildung 6: Geblocktes ping 11

14 Mallory führt ein netdiscover durch. Gefunden werden Alice mit der IP und Zweitere ist die IP-Adresse des verwendeten Notebooks. Das System von Mallory wird auf einer virtuellen Maschine mit einer eigenen IP ( ) ausgeführt (siehe Abbildung 7). Anschliessend wird das Protokoll der IDP-10 überprüft. Dieses hat allerdings keine Aufzeichnungen über einen Portscan. Erklären lässt sich dies nur damit, dass dieser netdiscover keinen aktiven Scan, sondern nur einen passiven Scan durchführt. Also keine eigenen Pakete versendet, sondern nur Pakete empfängt. So ist es unmöglich, für die IDP-10 diesen Scan zu erkennen und zu verhindern. Abbildung 7: Netdiscover funktioniert trotzdem noch Eingetroffene Resultate Wie erwartet, kann die IDP-10 die Ping-Pakete blockieren. Zudem wird alles im Protokoll mit Datum und genauer Uhrzeit aufgezeichnet. Es benötigt jedoch genauer Begutachtung, welche Regeln protokolliert und geblockt werden sollen, welche nur protokolliert und welche einfach ignoriert werden sollen. Bei rund 1700 erkennbaren Signaturen keine einfache Aufgabe. Bei passiven Aktivitäten, also das reine Aushorchen des Netzwerkverkehrs, kann auch die IDP-10 nichts ausrichten. Da die durchgeführten Scans solche waren, konnte Mallory ungehindert das Netzwerk aushorchen. 12

15 5 Incident Response Plan 5.1 Einleitung Jede Firma, die beschliesst die IT selbst zu erledigen, sollte sich einen Incident-Response- Plan aufstellen. Dieser Plan zeigt auf, welche Schritte während oder nach einem Hackerangriff ausgeführt werden. Ziel eines solchen Planes ist es, den Schaden gering zu halten, Informationen über den Angreifer zu erhalten, sowie bestehende Lücken zu schliessen. Dabei reicht es nicht, sich irgendwo einen Plan herunterzuladen und diesen wenn nötigt zu zücken. Vielmehr sollte sich die Firma auf solche Vorfälle vorbereiten. 5.2 Vorbereitung Bevor überhaupt ein Vorfall passiert, sollte sich die Firma darauf vorbereiten. Dazu muss als erstes ein Computer-Security-Incident-Response-Team (CSIRT) gebildet werden. Wie dieses Team gebildet wird, bzw. wer alles dazugehören soll oder muss ist ein eigenes Thema. Darauf möchte in diesem Artikel nicht weiter eingegangen werden. Informationen dazu finden sich im Artikel zum Kreieren eines CSIRT s der Carnegie Mellon University (2006) bzw. im Handbuch für CSIRT s von West-Brown et al. (2003). Dieses Team sollte gemäss DFN CERT (o. J.-a) folgende Punkte vorbereiten: Kontaktliste mit Ansprechpartnern, sowie der Meldestelle für Cyberkriminalität in der Schweiz MELANI 1 Möglichst komplette Dokumentation der betreuten Systeme Pläne für verschiedene Szenarien Alle erwähnten Punkte sind idealerweise in Papierform vorhanden, aktuell gehalten sowie vom Team einstudiert. Jeder der Szenariopläne sollte als Checkliste gehalten werden, damit keine Punkte vergessen werden (DFN CERT, o. J.-a). 5.3 Entdeckung Vielfach stellt sich die Frage, ob überhaupt ein Vorfall vorliegt. In einigen Fällen, beispielsweise bei einem Defacement 2 oder bei einem Denial of Service (DoS) Angriff, ist 1 Webseite der Melde- und Analysestelle Informationssicherung verfügbar unter 2 Umgestaltung der Webseite 13

16 es offensichtlich (DFN CERT, o. J.-a). Bei Wirtschaftsspionagen versucht der Angreifer jedoch unerkannt zu bleiben. Solche Eindringlinge entdeckt man am besten mit angepassten Routineuntersuchungen bei denen man gezielt nach Anomalien sucht. Eine solche Routineuntersuchung diente in diesem Themenpapier als Vorlage für den Laborversuch Spurensuche auf Linux-System (siehe 4.1) sowie sowie den Versuch Spurensuche auf Windows-System (siehe 4.2). 5.4 Analyse Wird festgestellt, dass tatsächlich ein Vorfall vorliegt, [... ] sollte das weitere Vorgehen mit allen Beteiligten abgesprochen werden (DFN CERT, o. J.-a). Hier zahlt es sich nun aus, gut vorbereitet zu sein und eine Liste mit allen betroffenen Personen und Behörden bereit zu haben. Nun gilt es ersteinmal die näheren Umstände des Vorfalls aufzuklären (DFN CERT, o. J.-a). Falls möglich, sollte als Erstes ein forensisch korrektes Abbild erstellt werden (Fischer, 2012). Auf gut Deutsch heisst dies, Stecker raus und 1:1 Kopie der Harddisk(s) erstellen. Anschliessen kann mit der Kopie fortgefahren werden. Somit bleibt das Original unangetastet und ist vor Gericht verwendbar. Nun geht es darum folgende Fragen zu klären: Wann und wo ist der Vorfall passiert? Was genau ist passiert? Wer ist beteiligt und wer ist der Angreifer? Wie ging er vor? Welche Schwachstelle wurde ausgenutzt? Welcher Schaden ist bisher entstanden? Welcher weitere Schaden droht? (DFN CERT, o. J.-a) Damit diese Fragen geklärt werden können, ist ein gut geschultes CSIRT, sowie eine gute Zusammenarbeit mit den Behörden nötig. Parallel zur Informationssuche kann bereits der nächste Schritt vorbereitet werden (DFN CERT, o. J.-a). 5.5 Eindämmung In manchen Fällen ist es nicht möglich oder gar nicht erlaubt (Service Level Agreement (SLA)) das befallene System offline zu nehmen und/oder zu patchen. Vielleicht möchte man auch laufende Jobs nicht unterbrechen. Dennoch gilt es, weiteren Schaden [... ] zu verhindern (DFN CERT, o. J.-a). 14

17 Grundsätzlich steht hinter Eindämmungsmassnahmen die Abwägung zwischen dem eigenen Schaden durch die Massnahmen (z.b. durch Abschaltung von Diensten) und dem [... ] Schaden anderer durch Untätigkeit (DFN CERT, o. J.-a). Die Eindämmungsmassnahmen können in zwei Gruppen unterteilt werden, lokale Massnahmen und Netzwerkmassnahmen. (DFN CERT, o. J.-a) Lokale Massnahmen befassen sich lediglich mit dem Säubern des betroffenen Systems und können wie folgt aussehen: Entfernen gehosteter Daten (Malware, Warez) Sperren kompromittierter Accounts Abschalten angegriffener / gefährdeter Dienste Oberflächliches Säubern des Systems mit Virenscannern, Anti-Spyware und Ähnlichem Entfernen erkannter Hintertüren im System. (DFN CERT, o. J.-a) Netzwerkmassnahmen hingegen schotten das befallene System vom rest des Netzwerkes ab, oder beschränken dessen Zugriff darauf. Dies umfasst: Beschränken des betroffenen Systems auf ein Quarantänenetz Sperren bestimmter Dienste oder Protokolle Einsetzen eines Rate Limit für bestimmte IP-Adressen oder Protokolle (lokal oder beim ISP) Sperren ausgewählter eigener IP-Adressen beim ISF oder Upstream- ISF (DFN CERT, o. J.-a) 5.6 Kontrolle gewinnen Will man die Kontrolle wiedergewinnen, kann das in einigen fällen Neuinstallation bedeuten. Dies insbesondere beim Befall durch Viren und Würmer, die beim Einbruch ins System gelangten. Alle vorhin erwähnten Schritte (siehe 5.5) waren bisher nur Symptombekämpfung und haben nich die Ursache des Problems beseitigt. (DFN CERT, o. J.-a) Die Neuinstallation sollte am besten offline, zumindest ohne Verbindung zum Internet durchgeführt werden. Das Risiko, dass das System schon während der Installation erneut angegriffen wird, ist zu gross. Auch sollte keine Upgrade-Installation durchgeführt werden, da evtl. Dateien des Angreifers 15

18 erhalten bleiben. Die Partitionen sollten formatiert und anschliessend von Grund auf neu installiert werden. Man sollte sich versichert haben, dass ein funktionsfähiges Backup des Systems existiert [... ] und nicht vom Angreifer zerstört wurde. (DFN CERT, o. J.-a) Anschliessend an die Neuinstallation sollte ein Hardening durchgeführt werden. Dazu zählt unter anderem das Einspielen von Sicherheitspatches, eventuelles Umkonfigurieren von Diensten sowie das Schliessen entdeckter Lücken falls nicht bereits mit einem Patch behoben. Zudem sollten alle Passwörter geändert werden. Ebenfalls sollte man die Zertifikate neu erstellen sowie ihre Vorgänger sperren lassen. Andernfalls kann es sein, dass der Angreifer immer noch Zugriff via Virtual Private Network (VPN) hat. (DFN CERT, o. J.-a) 5.7 Nachbearbeitung Rückblickend sollte man eine Nachbearbeitung machen und das Geschehene mit den betroffenen Personen besprechen. Dazu gehört es, aufzuzeigen welche Massnahmen nicht funktioniert haben bzw. welche verbessert werden können. Was musste auf Grund des Angriffs geändert werden? Welche Pläne, Dokumentationen müssen erneuert werden? (DFN CERT, o. J.-a) Anschliessend an diese Nachbearbeitung sollte man aktualisierte Notfallpläne und Dokumentationen haben. Denn: Nach dem Vorfall ist vor dem Vorfall! (DFN CERT, o. J.-a) 6 Lessons-Learned Die Laborversuche zeigen dass ein Hacken von Windows-Systemen sowie Linux-Systemen, mehr oder weniger einfach und schnell zu bewerkstelligen ist. Im Internet findet man relativ schnell Anleitungen, die das Vorgehen aufzeigen. Zwei dieser Anleitungen wurden auch in diesem Themenpapier benutzt. Es zeigte sich jedoch auch, dass wenn man nur minimale Präventionsmassnahmen (z.b. Firewall) einsetzt, diese Anleitungen kaum mehr etwas taugen. Nichtsdestotrotz sollte sich eine Firma bewusst sein, dass es Personen gibt, die etwas mehr drauf haben als unser Zweierteam. Die Forensik gestaltete sich besonders interessant. Befehle, die man in der Regel einfach so eingibt, um einfachere Sachen nachzuschauen, wurden auseinandergenommen und 16

19 die Bedeutung von jeder Ausgabe analysiert. Dies nicht nur beim Linux-System, sondern auch unter Windows. Obwohl hier zusätzliche Werkzeuge organisiert werden mussten, trafen ähnliche Resultate ein. Eher ernüchternd war die Tatsache, dass man, trotz aktivem Hacker, kaum Hinweise gefunden hat. Einzig und allein Befehle, die Netzwerkverbindungen aufzeigen, waren erfolgreich. Deshalb empiehlt es sich, starke präventive Massnahmen einzusetzen. Es sollten auch alle Systeme aktuell gehalten werden, da viele Patches auch Sicherheitslücken beheben. Und was natürlich auch nie schadet, ist die Ausbildung der Fachleute aktuell zu halten. 7 Schlusswort Spannende Themen, die IT-Forensik und Incident Response. Mit der Wichtigkei, welche das Internet und die Vernetzung inne haben, wird die Sicherheit wichtiger denn je. Wir konnten aufzeigen, dass schon minimalste Sicherheitsvorkehrungen, wie eine Windows- Firewall, ein Grundmass an Sicherheit bieten kann. Zudem zeigen die Erfahrungen mit einem Incident-Response-Plan, dass auch hier gilt Vorsicht ist besser als Nachsicht. Die Laborversuche waren teilweise stressig, haben aber auch einen Riesenspass gemacht. Das Themengebiet ist jedoch sehr gross. Es ist kaum möglich in so kurzer Zeit in alle Ecken zu schauen. Hinzu kam, dass es bei unserem Termpaper nicht reichte, uns nur auf unser Gebiet zu beschränken. Es musste auch auf die Seite des Gegners geschaut werden, um erfolgreiche Hacks durchzuführen. Alles in allem, haben wir viel dazugelernt, können aber auch Folgendem zustimmen: Je mehr ich weiss, desto mehr erkenne ich, dass ich nichts weiss. (Albert Einstein) 17

20 Literatur Allen, M. (2011). Growing cybercrime menace hits unwary firms. swissinfo.ch. Zugriff am auf cybercrime menace hits unwary firms.html?cid= Carnegie Mellon University. (2006). Creating a Computer Security Incident Response Team: A Process for Getting Started. Zugriff am auf DFN CERT. (o. J.-a). Grundlegende Schritte zur Vorfallsbearbeitung. Zugriff am auf -response-informationen/grundlegende-schritt-zur-vorfallsbearbeitung.html DFN CERT. (o. J.-b). Hinweise auf Kompromitierung (UNIX / Linux). Zugriff am auf -response-informationen/nachsehen-linux.html DFN CERT. (o. J.-c). Hinweise auf Kompromittierung (Windows). Zugriff am auf -response-informationen/nachsehen-windows.html Dieterle, D. (2012). Metasploitable Gaining Root on a Vulnerable Linux System. Zugriff am auf metasploitable-gaining-root-on-linux-system/ Fischer, R. (2012). Netzwerk Forensik. IT - Security Forum #5. Lirio, P. (2012). Hack Windows XP SP2 (with Backtrack 5). Zugriff am auf West-Brown, M. J., Stikvoort, D., Kossakowski, K.-P., Killcrece, G., Ruefle, R. & Zajicek, M. (2003). Handbook for Computer Security Incident Response Teams (CSIRTs) (2. Aufl.). Pittsburgh: Carnegie Mellon Software Engineering Institutes. 18