IT-Academy Logo
Sign Up Login Help
Home - Netzwerke - Sicherheit - Was ist ein Honeynet?



Was ist ein Honeynet?

Eine nicht ganz kurze Einführung in die Thematik der Honeynets.


Autor: Jochen Berner (jberner)
Datum: 23-07-2003, 23:20:34
Referenzen: http://www.honeynet.org/papers/index.html
Schwierigkeit: Fortgeschrittene
Ansichten: 8075x
Rating: 7 (3x bewertet)

Hinweis:

Für den hier dargestellte Inhalt ist nicht der Betreiber der Plattform, sondern der jeweilige Autor verantwortlich.
Falls Sie Missbrauch vermuten, bitten wir Sie, uns unter missbrauch@it-academy.cc zu kontaktieren.

[Druckansicht] [Als E-Mail senden] [Kommentar verfassen]



Was ist ein Honeynet?

Ein Honeynet ist eigentlich nur eine spezielle Form eines Honigtopfes. Genauer gesagt ist es ein hoch interaktiver Honigtopf, der speziell entwickelt wurde um Informationen über den Gegner sammeln zu können. Die meisten Honigtöpfe dienten zur Irreführung oder zur Erkennung von Angriffen. Sie bestehen normalerweise aus einzelnen Systemen, die andere Systeme oder bekannte Dienste und Schwachstellen emulieren oder aber sehr beschränkte Umgebungen zur Verfügung stellen. Mehr über Honigtöpfe erfährt man unter www.tracking-hackers.com.

Ein Honeynet unterscheidet sich von traditionellen Honigtöpfen, es ist vielmehr das, was wir einen Forschungshonigtopf nennen würden. Das macht es nicht zu einer besseren Lösung als traditionelle Honigtöpfe, es hat lediglich einen anderen Zweck. Statt Angreifer aufzuspüren oder in die Irre zu führen hat es den Zweck, Informationen über mögliche Bedrohungen zu sammeln. Die beiden größten Designunter-schiede zu einem Honigtopf sind:
  • Es ist nicht ein einzelnes System, sondern ein Netzwerk von mehreren Systemen und Anwendungen die von Angreifern untersucht und attackiert werden können. Honeynets können verschiedenste Systeme wie Solaris, Windows NT, Cisco Router Alteon Switches usw. gleichzeitig im Betrieb haben. Das schafft eine Netzwerkumgebung die ein Produktivnetz wesentlich realistischer simuliert. Durch verschiedene Systeme mit verschiedenen Anwendungen, wie z.B. ein Linux DNS Server, ein Windows IIS und einem Solaris Datenbankserver, kann man außerdem mehr über die unterschiedliche Werkzeuge und Vorgehensweisen erfahren. Vielleicht haben Angreifer spezielle Systeme, Anwendungen oder Schwachstellen im Visier. Indem man eine Vielzahl davon anbietet, kann man präzisere Profile über einzelne Angriffstrends und -erkennungsmerkmale erstellen.
  • Alle Systeme des Honeynets sind Standardproduktivsysteme. Es sind reale Systeme mit Anwendungen wie man sie auch im Internet findet. Nichts wird emuliert und nichts wird getan um diese Systeme angreifbarer zu machen. Die Risiken und Schwachstellen die man in einem Honeynet findet sind dieselben, die auch heute in vielen Firmen existieren. Man nimmt einfach ein System aus der Produktivumgebung und stellt es in das Honeynet.
Diese beiden Designunterschiede machen ein Honeynet primär zu einem Forschungswerkzeug. Man kann es auf die traditionelle Art verwenden um unzulässige Aktivitäten aufzuspüren, allerdings erfordert ein Honeynet wesentlich mehr Arbeit und Administration und bedeutet außerdem ein größeres Risiko. Es ist einfach zu viel Aufwand, ein Honeynet aufzubauen und zu betreiben um damit nur Angriffe aufzuspüren.

Wert eines Honeynets

Informationssicherheit ist traditionellerweise rein defensiv. Firewalls, Intrusion Detection Systeme, Verschlüsselung: alle diese Mechanismen werden genutzt, um die eigenen Ressourcen defensiv zu schützen. Die Strategie ist es, die eigene Organisation zu gut wie möglich zu verteidigen, Fehler in dieser Verteidigung auszumachen um dann auf diese Fehler zu reagieren. Das Problem bei diesem Ansatz ist seine Passivität, der Gegner ist der aktive Teil. Honeynets versuchen das zu ändern. Der primäre Zweck eines Honeynets ist es, Informationen über bestehende Bedrohungen zu sammeln. Neue Werkzeuge können gefunden, Angriffsmuster bestimmt und die Motive der Angreifer studiert werden. Die so gewonnenen Informationen kann man dann verwenden, um sich selbst zu schützen.

Honeynets sind nichts weiter als ein Werkzeug und als solches kann man sie auch für andere Zwecke einsetzen. Zum Beispiel können Organisationen Honeynets benutzen, um ihre Fähigkeit, auf Angriffe und Einbrüche zu reagieren, zu testen und zu verbessern. Der Vorteil, den man durch die Analyse der kompromittierten Systeme hat ist der, das man die meisten Antworten schon hat. Damit kann man ein kompromittiertes System als "Herausforderung" betrachten, an dem man seine Fähigkeit, mit verschiedenen forensischen Methoden herauszufinden was geschehen ist, testen kann. Danach kann man diese Resultate mit den Daten von innerhalb des Honeynets vergleichen. Beispiele dafür sind die zahlreichen "Challenges" die das Honeynet-Project sponsert (http://www.honeynet.org/misc/chall.html). Honeynets sind lediglich ein Werkzeug, sind aber von Nutzen, egal wie man sich entschließt sie einzusetzen. Von ihrem Zweck und Design aber sind sie gemacht um Bedrohungen zu erforschen.

Funktionsweise

Honeynets sind eigentlich eine simple Sache. Man erschafft ein Netzwerk, das einem Aquarium ähnelt: man kann alles sehen, was darin vorgeht. Ebenso wie Fische kann man Hacker beobachten wie sie sich in der virtuellen Umgebung verhalten. Und genau wie bei einem Aquarium kann man alles hineintun, was man möchte. Dieses kontrollierte Netzwerk wird zu einem Honeynet. Die aufgezeichneten Daten sagen einem etwas über Methoden, Taktiken und Motive der der Hackercommunity. Das größte Problem dem sich Sicherheitsexperten gegenübersehen, wenn sie Hackeraktivitäten aufspüren und aufzeichnen sollen ist die Informationsüberflutung. Die größte Herausforderung für die meisten Organisationen ist die Unterscheidung zwischen "normalem" Netzwerkverkehr und böswilligen Aktivitäten in den riesigen Informationsmengen. Werkzeuge und Techniken wie Intrusion Detection Systeme, Hostbasierte forensische Methoden oder Systemprotokollanalyse versuchen dieses Problem durch Einsatz von Datenbanken mit bekannten Angriffsmustern und/oder Algorithmen zur Unterscheidung zwischen "gutem" und "bösem" Netzwerkverkehr zu entschärfen. Informationsüberflutung, unbekannte Vorgänge, falsche Positive und falsche Negative können die Analyse und Bewertung der Aktivitäten erheblich erschweren.

Wie alle Honigtöpfe löst ein Honeynet das Problem der Datenflut durch Einfachheit. Ein Honeynet ist geschaffen um kompromittiert zu werden, nicht um realen Netzwerkverkehr weiterzuleiten. Jeder Verkehr in das oder aus dem Netz ist per Definition verdächtig. Jede von außen hergestellte Verbindung zum Honeynet ist sehr wahrscheinlich ein Test, eine Attacke oder eine sonstige Form von böswilliger Aktivität. Jede von innerhalb des Honeynets nach außen hergestellte Verbindung beweist, dass das Honeynet kompromittiert worden ist. Ein Hacker hat eine Verbindung von seinem neu gehackten Computer aus hergestellt und geht jetzt hinaus in das Internet. Das Konzept, das das Netz keinen Produktivverkehr aufweist, vereinfacht das Datensammeln und -analysieren erheblich.

Anforderungen

Für den erfolgreichen Aufbau eines Honeynets gibt es zwei kritische Voraussetzungen: Datenkontrolle und Datenaufzeichnung. Versagt eine dieser beiden Voraussetzungen versagt das ganze Honeynet. Honeynets können auf sehr viele verschiedene Weisen gebaut und eingesetzt werden und kaum einmal sind zwei identisch. Aber sie alle müssen die Voraussetzungen Datenkontrolle und Datenaufzeichnung erfüllen. Datenkontrolle bedeutet, dass man die Aktivitäten in seinem Honeynet einkapselt. Im Umgang mit Hackern liegt immer ein Risiko, und dieses Risiko mudd reduziert werden. Es gilt sicherzustellen, dass ein Honeypot der einmal kompromittiert worden ist, nicht dazu missbraucht werden kann Schaden auf anderen Nicht-Honeynet Systemen anzurichten.

Die Herausforderung ist also, den Datenfluss zu kontrollieren, ohne das der Hacker misstrauisch wird. Sobald ein System erstmal kompromittiert ist, braucht der Hacker meistens eine Internetverbindung um z.B. Toolkits herunterzuladen, IRC Sitzungen aufzumachen oder E-Mails zu verschicken. Es muss ihm also ermöglicht werden diese Aktionen durchzuführen, da dies genau die Schritte sind die wir lernen und analysieren wollen. Außerdem werden Hacker schnell sehr misstrauisch wenn sie keine Verbindungen nach außen herstellen können. Genau diesen Fehler haben wir bei unserem ersten Honeynet gemacht: wir haben keine Verbindungen nach außen erlaubt. Es hat den Hacker nur eine Viertelstunde gekostet zu erkennen das etwas nicht stimmt, das Systemlaufwerk zu formatieren und das Netzwerk zu verlassen. Der Trick ist es also, dem Hacker die Flexibilität zu geben zu tun was er möchte, ohne ihm zu erlauben das kompromittierte System zum Angriff auf andere, z.B. durch DoS Attacken, Portscans o.ä., zu nutzen.

Generell gilt: je mehr man dem Hacker an Aktivität erlaubt, desto mehr kann man lernen, aber desto größer sind auch die Risiken. Datenaufzeichnung bedeutet, das man alles was der Hacker macht, zur späteren Analyse aufzeichnet. Die aufgezeichneten Daten sagen einem etwas über Methoden, Taktiken und Motive der der Hackercommunity. Die Herausforderung hier ist, so viele Daten wie möglich mitzuschneiden, ohne es den Hacker merken zu lassen, das jede seiner Aktivitäten beobachtet wird. Dieses wird erreicht indem man so wenig Veränderungen wie möglich (wenn möglich gar keine) an seinem Honigtopf vornimmt.

Die mitgeschnittenen Daten können auch nicht lokal auf dem Honigtopf gespeichert werden. Lokal gespeicherte Daten können von dem Hacker möglicherweise gefunden werden und ihn darauf hinweisen, dass das System ein Honeynet ist. Die gespeicherten Daten können auch verloren gehen oder zerstört werden. Es müssen also nicht nur unbemerkt Daten gesammelt werden, sie müssen auch auf einem entfernten Rechner gespeichert werden. Der Schlüssel hierzu ist das Datensammeln in Schichten. Man kann sich nicht auf Informationen aus einer einzigen Schicht verlassen sondern sammelt Daten aus verschiedenen Quellen. Wenn man diese dann kombiniert, erhält man einen Überblick über das große Gesamtbild.

Es gibt noch eine dritte Voraussetzung: Datensammlung. Diese gilt aber nur für Organisationen, die mehrere Honeynets in verteilten Umgebungen betreiben. Die meisten Organisationen haben nur ein Honeynet so dass sie lediglich die ersten beiden Voraussetzungen erfüllen müssen. Organisationen, die mehrere logisch oder physikalisch verteilte Honeynets betreiben, wie z.B. die Honeynet Research Alliance (http://www.honeynet.org/alliance/index.html) müssen ihre gesammelten Daten an zentraler Stelle zusammentragen, so dass die Daten miteinander kombiniert werden können, was ihren Wert exponentiell steigert. Unter http://www.honeynet.org/papers/honeynet/distributed.jpg kann man sich ansehen, wie die Honeynet Research Alliance dieses Problem gelöst hat. Die Voraussetzung des Datensammelns bietet die sichere Möglichkeit die mitgeschnittenen Daten aus verschiedenen Honeynets zu sichern.

Das Honeynet Project hat ein Dokument erstellt, das diese drei Voraussetzungen im Detail erklärt. Das Ziel dieses Dokumentes ist es, Organisationen die Möglichkeit zu geben, ein Honeynet zu bauen, das auf ihre Umgebung und Ziele zugeschnitten ist. Dieses Dokument soll auch sicherstellen, das Honeynets effektiv und sicher installiert werden damit verschiedene Honeynets zusammenarbeiten können. Jede Organisation, die mit dem Gedanken spielt ein Honeynet aufzubauen sollte sich einmal dieses Dokument anschauen und, wenn möglich, die Vorschläge befolgen. Das Dokument gibt es hier: http://project.honeynet.org/alliance/requirements.html.

Wir werden uns im Folgenden ansehen, wie das Honeynet Projekt diese Voraussetzungen umgesetzt hat. Dies geschieht im zwei Abschnitten: GenI und GenII. GenI (steht für "erste Generation") war die erste Umsetzung die das Honeynet Projekt von 1999 - 2001 nutzte. Obwohl noch ziemlich grob und einfach, war es doch effektiv und hat die große Mehrheit aller im Internet vorkommenden Angriffe wie Würmer, Skriptkiddies, automatische Untersuchungen etc. aufgezeichnet. Im Jahr 2002 begann das Honeynet Projekt neue Werkzeuge und Techniken zu entwickeln, die GenII (steht für "zweite Generation") genannt wurden. Diese Techniken sind deutlich effektiver geworden, obwohl sie sich noch immer an die alten Vorgaben halten. Die Techniken der GenII geben Organisationen die Möglichkeit, die Aktivitäten von moderneren Angreifern mitzuverfolgen.

Erste Generation (GenI)

GenI Technologien setzen Datenkontrolle und Datenaufzeichnung mit simplen aber wirksamen Mitteln um. Die meisten der "Kenne deinen Feind" Papiere (http://www.honeynet.org/papers/index.html) wurden mit Hilfe dieser Technologien geschrieben. Wenn man noch nie ein Honeynet installiert hat oder sich nicht ganz sicher ist, was man tut sind die GenI Technologien ein guter Anfang. Sie sind vielleicht nicht ganz so effektiv wie GenII aber dank ihrer Einfachheit und dem ausgiebigen jahrelangen Test ist die Wahrscheinlichkeit, das etwas schiefläuft geringer. Wir werden erst sehen wie man die Angreifer kontrolliert und danach, wie man ihr Tun aufzeichnet.

Unter http://www.honeynet.org/papers/honeynet/lab.jpg gibt es einen Netzplan eines GenI Honeynet. Es handelt sich um eben das Honeynet, das benutzt wurde, um Forschung für die "Kenne Deinen Feind" Serie zu betreiben. In dem Diagramm sieht man eine Layer 3 Firewall, die das Honeynet in drei Netzwerke aufteilt: in das Honeynet, das Internet und das Administrations-Netzwerk. Jedes Paket das in das Honeynet hinein oder daraus hinaus will muss durch die Firewall und den Router. Die Firewall ist das wichtigste Werkzeug zur Kontrolle von ein- oder ausgehenden Verbindungen. Der Router wird genutzt, um diese Filterung zu unterstützen. Die Firewall ist so konfiguriert, das sie jede eingehende Verbindung zulässt, ausgehende aber kontrolliert.

Die Firewall verfolgt, wie viele Verbindungen von einem Honigtopf (die gelben Systeme in dem Diagramm) in das Internet aufgebaut werden. Sobald ein Honigtopf eine bestimmte Anzahl ausgehender Verbindungen erreicht hat, blockt die Firewall jeden weiteren Versuch. Dies gibt dem Angreifer die Möglichkeit, auszuführen was immer er braucht und uns automatische Sicherheit gegen Missbrauch.

Es gibt keine richtige oder falsche Anzahl von zu erlaubenden Verbindungen, es hängt nur davon ab, welche Funktionalität man haben möchte. Möchte man automatisierte Attacken wie auto-rooters (http://www.honeynet.org/scans/scan13/index.html) oder Würmer beobachten, braucht man wahrscheinlich gar keine ausgehenden Verbindungen. Diese automatisierten Attacken kompromittieren einfach einen der Honigtöpfe und die Firewall blockt danach alle ausgehenden Verbindungen und verhindert so die Weiterverbreitung. So kann man die für die Attacke verwendeten Werkzeuge analysieren, ohne andere Systeme zu gefährden. Möchte man jedoch menschliche Aktivitäten entdecken oder herausfinden, was nach der Kompromittierung eines Systems geschieht, so wird man doch einige Verbindungen erlauben müssen. Auch hier gilt: je mehr man zulässt, umso mehr kann man lernen, allerdings steigt auch das Risiko.

Nach unseren Forschungen reichen fünf bis zehn Verbindungen pro Stunde aus, um einen Angreifer zufrieden zu halten und andere gleichzeitig vor Angriffen zu schützen. Dies schützt das Honeynet davor, als Plattform für Scans oder Angriffe auf andere Systeme missbraucht zu werden. Einige Organisationen brauchen diese Funktionalität vielleicht nicht.

Wenn man sich jemanden leisten kann, der das Honeynet 24/7 überwacht, kann man auch beliebig viele Verbindungen erlauben. Wird ein DoS-Angriff festgestellt, kann die Person die das Honeynet überwacht ihn einfach abschalten. Wir empfehlen allerdings eine automatische Methode dieses zu tun, da die meisten Organisationen sich keine 24/7 Überwachung leisten können.

Aus zwei Gründen ist ein zusätzlicher Router zwischen Firewall und Honeynet postiert. Zum einen verbirgt der Router die Firewall. Wird ein Honigtopf kompromittiert, findet der Angreifer nur einen produktiven Router zwischen sich und außen liegenden Netzwerken. Das schafft eine realistischere Umgebung und schützt die Firewall vor Entdeckung. Zum anderen dient der Router als zweite Zugangskontrolle. Er kann die Firewall unterstützen und sicherstellen, das kompromittierte Honigtöpfe nicht zum Angriff auf andere außerhalb des Honeynet verwendet werden.

Es gibt zur Zeit einige unterschiedliche Werkzeuge, die es einem möglich machen, ausgehende Verbindungen zu zählen. Wir haben ursprünglich eine FireWall-1 von CheckPoint und ein Shellskript zum Zählen der Verbindungen verwendet. Wird das Limit erreicht (in unserem Fall 5 Verbindungen) konfiguriert das Skript die Firewall so um, das keine Verbindungen von dem Honigtopf aus aufgebaut werden können. Wenn dies passiert kann das Skript darüber hinaus noch einen Alarm verschicken und mitteilen das ein kompromittierter Honigtopf gesperrt wurde (http://www.honeynet.org/papers/honeynet/alert.txt). Genauere Angaben wie die Funktionalität umgesetzt wurde und der Quelltext des Skriptes finden sich hier.

Eine andere Alternative ist die Verwendung von IPTables und seiner "limit" Funktion. IP-Tables, eine OpenSource Firewall, die kostenlos mit Linux mitgeliefert wird, kann man nutzen, um ausgehende Verbindungen zu zählen und bei Erreichen eines gesetzten Limits alle weiteren zu blocken. Das Skript rc.firewall implementiert diese Funktion automatisch. Lediglich die Variablen im Skript müssen an das jeweilige Honeynet angepasst werden. Dadurch wird IPTables so konfiguriert, das es die Anforderung der Datenkontrolle erfüllt. Eine dritte Variante ist OpenBSDs "pf" oder "packet filter". Es existiert ein Patch, der es pf ermöglicht, Verbindungen zu zählen und bei Erreichen des gesetzten Limits weitere zu blockieren. Diese drei Beispiele stellen verschiedene Möglichkeiten dar, Datenkontrolle zu verwirklichen. Es ist nicht wirklich wichtig, wie man es im Endeffekt macht, solange man die Anforderungen zur Datenkontrolle erfüllt.

Der Router dient als eine zweite Schicht zur Zugangskontrolle. Kein Honeynet sollte sich allein auf eine Quelle zur Datenaufzeichnung verlassen. Wir haben dies hauptsächlich verwendet, um uns gegen vorgetäuschte, DoS oder ICMP-basierte Angriffe zu schützen. Der Router erlaubt nur Paketen mit der Quelladresse des Honeynets zu passieren. In unserem Beispiel heißt das, dass nur Pakete mit einer Quelladresse von 172.16.1.0/24 das Honeynet verlassen können. Diese Maßnahme schützt gegen die meisten Angriffe die auf gefälschten Adressen beruhen, wie SYN flooding oder SMURF Attacken. Wir haben außerdem ICMP-Verkehr nach außen geblockt. Dies war nötig, da einige Firewalls Schwierigkeiten mit verbindungsorientierter ICMP Verfolgung ("Stateful ICMP tracking") hatten. Andere Organisationen brauchen ICMP nicht so zu limitieren. Das Einschränken von ICMP schützt gegen Attacken wie SMURF, den "Ping Of Death" (ja, er kommt immer noch vor) und das Kartieren von Netzwerken.

So kann eine grundlegende Zugriffskontrollliste für GenI Filterung aussehen:

router#show ip access-list 100
Extended IP access list 100
  deny icmp any any (5446314 matches)
  permit ip 172.16.1.0 0.0.0.255 any (66372 matches)
  deny ip any any log (59990 matches) 
Die Kombination einer Firewall und eines Routers ist eine effektive Methode ausgehenden Verkehr zu kontrollieren, da sie dem Angreifer die Flexibilität gibt, das auszuführen, was er braucht während man gleichzeitig die Möglichkeit zu Angriffen gegen andere Systeme einschränkt.

Sobald man die Datenkontrolle hergestellt hat ist der nächste Schritt die Datenaufzeichnung. Die erste Schicht der Aufzeichnung ist die Firewall. Im ersten Schritt wurde gezeigt, wie man die Firewall zur Datenkontrolle verwenden kann. Dieselbe Firewall kann benutzt werden, um Daten aufzuzeichnen. Die Firewall zeichnet alle Verbindungen aus dem oder zum Honeynet auf. Diese Informationen sind kritisch, da alle Verbindungen verdächtig sind. Wir haben unsere Firewall so aufgesetzt, das nicht nur jede Aktivität aufgezeichnet wird, sondern das wir jedes Mal alarmiert werden, wenn versucht wird, eine Verbindung aufzubauen. Wenn z.B. jemand versucht, eine telnet-Verbindung zu einem System innerhalb des Honeynets aufzubauen, wird die Firewall dieses protokollieren und uns auf dieses Ereignis aufmerksam machen. Das ist extrem nützlich, wenn man Scanning-Muster überwachen will. Eine andere Verwendung ist das Erkennen von Hintertüren oder proprietären Ports. Die meisten Exploits erzeugen eine Shell oder eine Hintertür auf dem System. Diese Hintertüren sind sehr einfach zu finden, wenn man von der Firewall auf einen Verbindungsversuch auf einem zufälligen High-Port aufmerksam gemacht wird. Die Firewall alarmiert uns auch, wenn ein System innerhalb des Honeynets versucht, eine Verbindung nach außen aufzubauen.

Auch hier wird protokolliert und alarmiert. Allerdings hat dieser Alarm eine höhere Priorität, da es bedeutet, dass das entsprechende System kompromittiert worden ist. Ein solcher Alarm würde per E-Mail und Pager verschickt werden.

Eine andere kritische Schicht ist das IDS, das zwei Funktionen erfüllt. Die erste, und bei weitem wichtigste, ist die Aufzeichnung aller Netzwerkaktivität. Seine vorrangige Aufgabe ist das Aufzeichnen und Protokollieren von jedem Paket das auf der Leitung auftaucht. Wie in http://www.honeynet.org/papers/honeynet/lab.jpg zu sehen, liegt das IDS auf einem Switch, der eine physikalische Verbindung zu allen anderen Systemen im Honeynet hat. Das IDS liegt auf einem "port monitoring" Port, so dass es Netzwerkaktivität aufzeichnen kann. Diese Aufzeichnung werden dann genutzt, um das Tun des Angreifers zu analysieren. Die zweite Funktion ist die Alarmierung bei allen verdächtigen Aktivitäten. Die meisten IDS-Sensoren haben eine Datenbank mit Signaturen und sobald ein Paket zu einer Signatur passt, wird ein Alarm erzeugt. Diese Fähigkeit ist für ein Honeynet nicht ganz so wichtig, da jede Aktivität von Natur aus als verdächtig gilt. IDS-Sensoren geben einem detaillierte Informationen über eine spezielle Verbindung.

Das Honeynet-Projekt hatte mit dem OpenSource IDS snort phänomenalen Erfolg. Wir haben snort so konfiguriert, das jede Netzwerkaktivität in ein binäres Logfile geschrieben wird. Diese binären Logs sind kritisch, da hier jedes Paket mitgeschrieben wird. Darüber hinaus protokolliert snort jede ASCII Kommunikation (wie z.B. Tastendrücke wahrend einer ftp-Sitzung) in Sitzungs-Breakout-Dateien. Beide Protokolle, binäre und ASCII, werden täglich in ihr eigenes Verzeichnis gesichert. Das erleichtert die tägliche Durchsicht und Analyse erheblich. Um diese tägliche Protokollierung einzurichten, haben wir ein Startup-Skript erstellt, das per cron jeden Tag ausgeführt wird und snort mit einem neuen Verzeichnis für die Protokolldateien neu startet. Drittens werden alle Alarme von snort an einen syslog-Server weitergeleitet. Als letztes nutzen wir eine Backend-Datenbank, die die Alarme der verteilten Honeynets sammelt.

Eine dritte Schicht sind die Systeme selbst. Wir möchten jede System- und Benutzeraktivität aufzeichnen, die auf einem System auftritt. Die erste Methode ist es, alle Systemprotokolle nicht nur lokal zu speichern, sondern auch auf einem entfernten System. Für Unixsysteme und die meisten Netzwerkkomponenten ist dies einfach zu erreichen: ein Eintrag für einen entfernten Syslog-Server in der entsprechenden Konfigurationsdatei.

Für windowsbasierte Systeme gibt es Programme von Drittanbietern, die diese Aufgabe übernehmen können. Systemprotokolle können auch auf auf eine NFS- oder SMB-Freigabe auf dem entfernten syslog-Server geschrieben werden. NT zwingt einen, Software von Drittanbietern zu verwenden um Systeminformationen in syslog schreiben zu können, aber es kann auf ein Netzlaufwerk schreiben. Auf diese Weise werden wichtige Systeminformationen wie Prozessaktivität, Verbindungen und versuchte Exploits an einen sicheren Ort auf einem entfernten System geschrieben. Wir versuchen gar nicht erst, die Verwendung eines entfernten syslog-Servers zu verbergen. Stellt der Angreifer dieses fest, ist das Schlimmste, was er tun kann das Abschalten von syslog (was bei den meisten Angreifern sowieso Standard ist).

Dies bedeutet zwar, das keine fortlaufenden Protokolle mehr existieren, aber wir haben Informationen darüber, wie er eingedrungen ist und von wo. Fortgeschrittenere Angreifer werden versuchen, den entfernten syslog-Server zu kompromittieren um damit ihre Spuren zu verwischen. Das ist genau das, was wir wollen. Der syslog-Server ist normalerweise ist wesentlich besser geschütztes System. Das bedeutet für den Angreifer: um die Kontrolle zu bekommen, muss er fortschrittlichere Techniken verwenden, die wir aufzeichnen um daraus zu lernen. Wenn der syslog-Server kompromittiert wird, haben wir doch nichts verloren. Der Angreifer darf in der Tat Kontrolle übernehmen und die Protokolle löschen. Denn nicht vergessen: wir haben noch den IDS-Sensor im Netz, der passiv alle Protokollierungsaktivitäten im Netz aufgezeichnet und mitgeschrieben hat. In Wirklichkeit ist das IDS ein zweites Protokollsystem, da es passiv jeden Netzwerkverkehr aufzeichnet.

Eine zweite Methode, um Daten mitzuschneiden, wäre die Modifikation des Systems, damit es Tastendrücke und Screenshots aufzeichnet und an einen entfernten Rechner weiterleitet. Dies geht z.B. mit einer angepassten Version der bash. Beispielsweise kann man diese Shell, entwickelt von Antonomasia, verwenden, um die ursprüngliche /bin/bash zu ersetzen. Diese "Trojaner-Shell" schickt Tastendrücke des Users an den syslogd, der sie dann an einen entfernten Syslog-Server weiterleitet.

Eine effektive Methode, die aber leicht durch das Abhören des Netzwerkverkehrs entdeckt werden kann. Außerdem kann man sie leicht umgehen, indem man einfach syslogd beendet oder erst gar nicht die bash verwendet. Anton Chuvakin hat diese Methode durch das Patchen von /bin/bash dahingehend verbessert, dass syslogd nicht mehr gebraucht wird. Diese Fähigkeiten beschränken sich aber nicht nur auf UNIX. Floydman hat eine Lösung (ComLog)für Windows entwickelt, die Befehle die über die cmd.exe eingegeben werden aufzeichnet. Da dieses Programm eine der am meisten verwendeten Methoden ist um einen Rechner fernzusteuern hat man hier eine hervorragende Möglichkeit die Aktivitäten eines Angreifers auf einem Windowsrechner festzuhalten.

Zweite Generation (GenII)

Die Mechanismen zur Datenkontrolle und Datenaufzeichnung die wir oben beschrieben haben, sind effektiv, können aber noch verbessert werden. Das Ziel von GenII-Honeynets war, eine Lösung zu finden die einfacher installierbar, aber trotzdem schwerer zu entdecken war. GenII-Datenkontrolle gibt dem Angreifer mehr Möglichkeiten mit dem kompromittierten System zu arbeiten und uns mehr Kontrolle über das, was er tut, wobei diese Kontrolle schwerer zu entdecken ist. Unsere Hoffnung war es, mehr Informationen über den Angreifer sammeln zu können indem wir ihm mehr Rechte, speziell was ausgehende Verbindungen angeht, zubilligen. Erreicht wurde dies durch die Schaffung einer intelligenteren und flexibleren Antwort auf die Aktivitäten des Angreifers. Nachfolgend umreißen wir die Konzepte der GenII-Technologie. Eine Schritt-für-Schritt Anleitung für die Installation einer solchen Honeynets findet sich in dem Whitepaper Know Your Enemy: GenII Honeynets (Übersetzung folgt, wenn wieder etwas Zeit ist, Anm. d. Übers.).

GenII-Honeynets kombinieren alle Anforderungen in einem einzigen Gerät. Das bedeutet, Datenkontrolle, Datenaufzeichnung und -sammlung finden auf einer Maschine statt. Dieses Vorgehen macht es wesentlich einfacher ein Honeynet aufzubauen und zu verwalten. Kernstück ist ein Layer2-Gateway das als Bridge fungiert. Hieraus ergeben sich zwei Vorteile:
  • Die Tatsache, das es auf Layer2 arbeitet, macht es wesentlich schwerer auffindbar, da es keinen eigenen IP-Stack hat. Es findet weder Routing statt noch wird der TTL-Zähler herabgesetzt. Das Gerät arbeitet wesentlich verborgener, Angreifer sollten nie bemerken, das der von ihnen erzeugte Netzwerkverkehr kontrolliert und analysiert wird.
  • Durch die Funktion als Gateway wird sichergestellt, dass sämtlicher Verkehr, ein- und ausgehend, durch das Gerät hindurch muss. Das bedeutet, das wir auf einem einzigen Gerät jeglichen Verkehr kontrollieren und aufzeichnen können. Dieses Bild zeigt, wie ein solcher Aufbau aussehen könnte.
Der erste Fortschritt in Sachen Datenkontrolle liegt in der Fähigkeit unauthorisierte Aktivität zu erkennen. Anstatt einfach nur die Zahl der aufgebauten ausgehenden Verbindungen zählen zu können, können wir jetzt verfolgen um welche Aktivitäten es sich handelt. Unauthorisierte Aktivität lässt sich jetzt anhand der Aktionen und deren Zweck identifizieren. Der Versuch, dreißig ausgehende ftp-Verbindungen aufzubauen ist in Ordnung. Eine einzige versuchte Verbindung um einen ftp-Exploit gegen ein Nicht-Honeynet System zu starten, ist nicht erlaubt und muss kontrolliert werden. Wir versuchen, mehr "Intelligenz" durch die Analyse der Aktivität des Angreifers zu schaffen und nicht einfach nur ausgehende Verbindungen zu zählen.

Der zweite Fortschritt liegt in der Art wie wir mit unauthorisierter Aktivität umgehen. Anstatt einfach ausgehende Verbindungen zu verbieten, versuchen wir, die Aktivität zu verändern oder auszubremsen. Der Angreifer wird zwar außerhalb des Honeynets aktiv, bleibt aber wirkungslos. Wir hoffen, das diese Maßnahmen für den Angreifer wesentlich schwieriger zu entdecken sind. Erreicht wird dieser Effekt durch die Manipulation von Paketen am Layer2-Gateway. Sobald ein Angreifer ein System im Honeynet übernommen hat, könnte er z.B. versuchen gegen ein anderes System außerhalb des Honeynets einen ftp-Exploit zu starten. Die GenI-Datenkontrolle ist hier sehr beschränkt: nach der fünften ausgehenden Verbindung wird sämtlicher Verkehr, inklusive der Exploits, gesperrt. Mit der GenII-Technologie jedoch würde der Versuch eines Exploits erkannt und so manipuliert, dass er wirkungslos bleibt.

Das Gateway würde z.B. im Programmcode des Exploits einige Bytes ändern, ihn dadurch unwirksam machen wenn er das Honeynet verlässt. Der Angreifer könnte nun beobachten wie der Angriff startet und Pakete zurückkommen, wüsste aber nicht, warum der Exploit nicht funktioniert hat. Wir gewinnen also mehr Kontrolle über das, was der Hacker macht ohne das er es weiß. Wir könnten auch Antworten fälschen, also ganze Verbindungen blockieren, dem Angreifer aber RST-Pakete schicken und somit abgelehnte Verbindungen vortäuschen. GenII-Technologien bieten dramatische Verbesserungen im Bereich der Datenaufzeichnung. Mit der GenI wurden die Daten von Sniffern und Firewalls auf dem Network-Level gesammelt. Die weite Verbreitung von Verschlüsselung, wie z.B. mit SSH, beschneidet diese Fähigkeit jedoch. Es wurden zwar einige Versuche unternommen, die Daten direkt von dem Honigtopf zu gewinnen (z.B. mit "Trojaner-Versionen" der /bin/bash) aber alle diese Lösungen waren auf die eine oder andere Weise eingeschränkt.

GenII steigert die Möglichkeiten, indem es Daten direkt aus dem Kernelspace liest. Dies stellt sicher, dass unabhängig von der Kommunikationsmethode, wie z.B. SSH, SSL oder IPsec die Information aufgezeichnet wird. Ein anderes Forschungsgebiet des Honeynet Projekts sind virtuelle Honeynets. Virtuelle Honeynets bündeln alle Elemente eines Honeynets auf einer Maschine. Es werden nicht nur die Voraussetzungen Datenkontrolle, Datenaufzeichnung und -sammlung, sondern auch die tatsächlichen Honigtöpfe auf einem System vereint. Ein virtuelles Honeynet kann entweder GenI- oder GenII-Technologien unterstützen. Die Honigtöpfe sind die echten Betriebssysteme, nichts wird emuliert. Der Vorteil dabei sind die Kosten und die Effizienz. Es ist deutlich billiger, alle Elemente eines Honeynets auf einer Maschine laufen zu lassen und wesentlicher einfacher aufzusetzen und zu verwalten. Mehr über virtuelle Honeynets kann man hier erfahren: Know Your Enemy: Defining Virtual Honeynets.

Werkzeugsammlung

Bis hierhin sind eine Menge Konzepte und Softwarelösungen erwähnt worden. Um den Aufbau zu erleichtern, haben wir die vorgestellten Werkzeuge auf einer Seite gesammelt. Sinn dieser Seite ist es, als zentrale Anlaufstelle für alle Bedürfnisse rund um Honeynets zu dienen. Auf dieser Seite finden sich auch Links zu anderen, hier nicht vorgestellten, Werkzeugen zur Datenkontrolle und Datenaufzeichnung. Wenn Sie planen, Ihr eigenes Honeynet aufzusetzen empfehlen wir ihnen dringend, auf dieser Seite vorbeizuschauen.

Verwaltung, Pflege & Risiko

Honeynets sind keine pflegeleichte Sache. Sie sind eine komplexe Art von Honigtopf und erfordern ständige Pflege, Administration und Überwachung. Für die maximale Effektivität ist es nötig, Vorfälle so schnell wie möglich zu erkennen und darauf zu reagieren. Kann man den Angreifer schon während der Tat beobachten, hat man die besten Möglichkeiten Daten zu sammeln und zu analysieren. Um unbekanntes zu entdecken ist es unerlässlich, verdächtige Aktivitäten ständig zu kontrollieren. Dies erfordert viel Zeit und Analysemöglichkeiten. Ein Angreifer kann auf einem kompromittierten Honigtopf in 30 Minuten genug Schaden anrichten, um für 30-40 Stunden Analyse Material zu liefern. Um das Honeynet ständig in Betrieb zu halten, ist ständige Wartung nötig. Wenn irgendetwas schief geht (und das tut es immer) kann das zu Versagen im Honeynet führen. Alarmprozesse stoppen, Festplatten sind voll, IDS-Signaturen veralten, Konfigurationsdateien können fehlerhaft sein, Systemprotokolle müssen durchgesehen werden, Firewalls müssen aktualisiert und gepatcht werden.

Dies sind nur einige der Arbeiten, die für ein erfolgreiches Honeynet nötig sind. Die Arbeit hat gerade erst begonnen, wenn das Honeynet aufgesetzt ist. Mit dem Aufbau und der Inbetriebnahme eines Honeynets geht man auch Risiken ein. Blackhats greifen unsere Systeme an und kompromittieren sie. Wenn man ein Netzwerk aufsetzt, das kompromittiert werden soll, setzt man sich und andere Gefahren aus. Man übernimmt die Verantwortung dafür, das das Honeynet, sobald es kompromittiert ist, nicht genutzt werden kann, um andere anzugreifen oder zu schädigen. Mit einer Umgebung wie dieser besteht aber immer die Möglichkeit, das etwas schief geht. Wir haben eine Menge Maßnahmen ergriffen, um dieses Risiko zu mindern. Es ist allerdings immer möglich, das Angreifer eine Methode oder Werkzeug entwickeln, um diese Mechanismen zu umgehen. Dauernde Tests und Aktualisierungen der Umgebung sind nötig, um sicher zu gehen das die Kontrollmechanismen greifen. Man sollte niemals die kreative Energie des Blackhat-Community unterschätzen. Die Verwendung von Firewalls, Routern und anderen Techniken hilft das bei Minimierung des Risikos, das das Honeynet genutzt wird um andere zu schädigen. Ein Restrisiko bleibt jedoch bestehen.

Zuletzt: Honeynets werden ihre Sicherheitsprobleme nicht lösen. Wir empfehlen wärmstens, das sich Organisationen zuerst auf die "best practices" konzentrieren, d.h. starke Verschlüsselung, die Verwendung verschlüsselnder Protokolle, die Durchsicht der Systemprotokolle und sicher installierte Systeme. Durch die Konzentration auf angemessene Richtlinien und Prozesse können die Risiken stark gemindert werden. Honeynets reduzieren nicht das Risiko, es ist eher wahrscheinlich, das sie es erhöhen. Wenn ihre Organisation an den Fähigkeiten eins Honeynets zur Erkennung oder Täuschung interessiert ist, empfehlen wir die Lektüre des Honeypot Whitepapers und die Tools, die am Beginn dieses Artikels besprochen wurden. Honeynets sind primär für die Forschung, für das Sammeln von Informationen über den Feind, entwickelt worden. Sie werden weder ihre unsicheren Server schützen noch schlecht aufgesetzte Prozesse oder Notfallprozeduren verbessern.

Rechtliche Hintergründe

Es würde den Rahmen dieses Artikels sprengen, sich mit den rechtlichen Fragen von Honeynets auseinanderzusetzen. Fragen Sie ihren Rechtsbeistand, bevor Sie eines aufsetzen. Das Honeynet Projekt arbeitet mit dem amerikanischen Department of Justice zusammen, um dieses Fragen zu klären und zu dokumentieren. Sobald die Dokumentation fertig ist, wird ein Artikel aus der Serie "Kenne deinen Feind" veröffentlicht. Das Buch Honeypots: Tracking Hackers enthält ein ganzes Kapitel über die rechtlichen Hintergründe von Honigtöpfen, wobei die meisten Punkte auch auf Honeynets zutreffen (Da es sich hier um ein amerikanisches Buch handelt, dürfte die rechtliche Lage in Deutschland abweichen. Also kann es nicht schaden, sich zusätzliche rechtliche Beratung von einem deutschen Juristen zu holen. Anm. d. Übersetzers).

Schlussfolgerung

Honeynets sind eine Art von Honigtopf, entworfen um Informationen speziell über Werkzeuge, Taktiken und Motive der Blackhat Community zu sammeln. Diese Informationen werden dann genutzt um Organisationen gegen verschiedene Bedrohungen zu schützen. Es gibt gegenwärtig zwei Ansätze, um Honeynets aufzusetzen: GenI und GenII. Beide Ansätze erfüllen die Definitionen, Voraussetzungen und Standards. Honeynets erfordern einen riesigen administrativen Aufwand. Der Administrator eines Honeynets trägt die Verantwortung dafür, das kein anderes System von seinem kompromittierten Honeynet aus angegriffen wird. Ohne angemessene Administration können die Risiken größer werden als der Nutzen. Dieses Werkzeug ist kein Sicherheits-Patentrezept und ist auch nicht für jede Organisation geeignet. Das Honeynet-Project empfiehlt dringend, das sich Organisationen zuerst auf die eigene Sicherung, z.B. durch das Einspielen von Patchen und das Abschalten von Diensten, konzentrieren. Ist das geschehen, könnten Organisationen in der Lage sein, Honeynets als mächtiges Werkzeug einzusetzen, um aktiv mehr über den Feind und sich zu lernen. Es wird allerdings dringend empfohlen, einen Rechtsbeistand zu Rate zu ziehen, bevor man ein Honeynet aufsetzt. Personen oder Firmen, die mehr über die Honeynet-Technologie erfahren möchten, können mit diesem Buch, geschrieben vom Team des Honeynet Project, beginnen.

Anm. d. Übers.

Ich bin kein professioneller Übersetzer, deswegen ist es sehr wahrscheinlich, das man vieles besser hätte formulieren können. Trotzdem hoffe ich, dass sich nirgendwo grobe Sinnentstellungen oder gar Fehler eingeschlichen haben. Wenn doch, oder auch bei sonstiger Kritik oder gar Lob, kurze E-Mail reicht und dann wird korrigiert.

Der Artikel wurde von mir mit größter Sorgfalt übersetzt. Trotzdem sind inhaltliche Fehler nicht ganz auszuschließen. Ich weise deshalb darauf hin, dass ich weder eine Garantie bzw. Gewährleistung noch die Verantwortung oder Haftung für Folgen jeglicher Art, die aus der Nutzung der hier geschilderten Angaben entstehen könnten, übernehme. Alle durchgeführten Veränderungen werden auf eigene Gefahr, sowie freiwillig und unabhängig von dem Inhalt dieser Web-Seite vorgenommen. Der Originalartikel ist hier zu finden:
http://www.honeynet.org/papers/honeynet/index.html.


[back to top]



Userdaten
User nicht eingeloggt

Gesamtranking
Werbung
Datenbankstand
Autoren:04502
Artikel:00815
Glossar:04116
News:13565
Userbeiträge:16551
Queueeinträge:06233
News Umfrage
Ihre Anforderungen an ein Online-Zeiterfassungs-Produkt?
Mobile Nutzung möglich (Ipone, Android)
Externe API Schnittstelle/Plugins dritter
Zeiterfassung meiner Mitarbeiter
Exportieren in CSV/XLS
Siehe Kommentar



[Results] | [Archiv] Votes: 1131
Comments: 0