IT-Academy Logo
Sign Up Login Help
Home - Netzwerke - Sicherheit - Honeynets der 2. Generation



Honeynets der 2. Generation

Dieser Artikel ist die Fortsetzung der Einführung in das Thema, die vor einiger Zeit hier veröffentlicht worden ist.


Autor: Jochen Berner (jberner)
Datum: 22-09-2003, 16:24:39
Referenzen: http://www.honeynet.org/papers/gen2
Schwierigkeit: Fortgeschrittene
Ansichten: 4256x
Rating: 9 (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]



GenII Honeynets

Einfacher aufzusetzen, schwerer zu entdecken, sicherer zu betreiben
Letzte Änderung: 27.06.2003

Das GenII Honeynet ist der nächste Schritt in der Entwicklung der Honeynet-Technologie. Durch Anwendung neuer Techniken, entwickelt von den Mitgliedern des Honeynet Projects und der Security Community, verbessert ein GenII Honeynet Flexibilität, Verwaltbarkeit und Sicherheit eines Honeynet Installation. Dieser Artikel stellt die Technologie vor und kann als Schritt-für-Schritt Anleitung zum Bau eines GenII Honeynets dienen, das denen ähnelt, das die Mitglieder des Projektes verwenden. Es wird angenommen, das Sie bereits die Konzepte die in Know Your Enemy: Honeynets http://www.honeynet.org/papers/honeynets/ (oder der deutschen Übersetzung) vorgestellt werden gelesen und verstanden haben.

Dieser Artikel ist ein vollständiger Überblick über alle Komponenten eines GenII Honeynets. Der erste Abschnitt stellt das Konzept einer Honeywall vor, die Stelle, an der sich die Verwaltungsmöglichkeiten für das Netzwerk bündeln. Im Abschnitt "Datenkontrolle" sprechen wir über den Einschränkung der Aktionen, die ein Hacker in unserem Netz unternehmen kann. Die dritte Sektion "Datenaufzeichnung" stellt Methoden vor, um im geheimen die Aktivitäten eines Angreifers auf Host- und Netzwerkebene zu protokollieren. Der "Automatische Alarmierung" Teil erklärt, wie im Falle eines erfolgreichen Angriffs sofort die Administratoren benachrichtigt werden können. Das abschließende Kapitel "Testen" stellt eine Reihe von Methoden vor, mit denen man die korrekte Funktionsweise der vorangegangenen Schritte überprüfen kann. Die Installation, die wir hier beschreiben basiert auf einer Honeywall die auf Standard x86 Komponenten und einem Linux 2.4 Kernel läuft. Die Tools und Techniken die in diesem Artikel vorgestellt werden, sind die, die aktuell von den Mitgliedern des Projektes genutzt werden. Es ist nicht notwendig, das Sie diese anwenden, nutzen Sie diejenigen, mit denen Sie am vertrautesten sind.

Die Architektur

Ein Honeynet ist kein Produkt, man installiert es nicht einfach von einer CD und lässt es ab dann laufen (obwohl wir daran arbeiten J). Ein Honeynet ist eine Architektur, ein vollständig kontrolliertes Netzwerk, mit dem man Angreifer "in freier Wildbahn" festhalten und ihr Vorgehen analysieren kann. Wie Sie diese Architektur aufsetzen, ist Ihnen überlassen. Um Ihnen bei der Installation zu helfen, haben wir ein Dokument entwickelt (Honeynet Definitionen, Anforderungen und Standards http://www.honeynet.org/alliance/requirements.html, in Englisch), das Ihnen die Anforderungen ihres Honeynets umreißt. Es handelt sich nicht um ein technisches HOWTO, es ist vielmehr eine Sammlung von erprobten und bewährten Methoden wie man ein Honeynet aufsetzt und von den Mitgliedern der Honeynet Research Alliance http://www.honeynet.org/alliance wird erwartet, das sie diese befolgen. Dieser Artikel stellt einen Weg unter vielen vor, wie man diese Anforderungen erfüllen kann.

Das Schlüsselelement eins jeden Honeynets ist das Gateway, die Komponente die das Honeynet vom Rest der Welt trennt. Dieses Gateway ist wie eine Mauer (darum nennen wir es auch die Honeywall). Jeglicher Verkehr in das oder aus dem Honeynet muß durch diese Honeywall hindurch. Sie ist das Nervenzentrum des Honeynets, hier passieren die Wunder. Für ein GenII Honeynet ist dieses Gateway eine Layer2-Bridge. Sie können ein Beispiel unserer angestrebten Honeynetarchitektur in Abbildung A http://www.honeynet.org/papers/gen2/figureA.jpg sehen. In diesem Beispiel ist unser Honeynet ein 192.168.1.0/24 Netz. In der Vergangenheit wurden Honeynets üblicherweise mit öffentlichen Adressen oder in "perimeter Networks" (wie übersetzt man das?) aufgesetzt. Durch die Verwendung einer Layer2-Bridge können wir, wie hier gezeigt, das Honeynet in das interne Netz integrieren. Dadurch wird es uns möglich, nicht nur Angriffe von außen sondern auch von innen zu beobachten und daraus zu lernen.

In der Abbildung ist zu erkennen, das die Honeywall (das Gateway) die produktiven Systeme vom Honeynet (mit den Opferrechnern) trennt. Die externe Netzwerkkarte (eth0) ist an das Produktivsystem angeschlossen, die interne Karte (eth1) an das Honeynet. Da es sich um eine Bridge handelt, befinden sich interne wie externe Systeme auf dem gleichen IP-Netzwerk. Außerdem gibt es noch eine dritte Netzwerkkarte (eth2), die zur Fernadministration, einschließlich der Verschiebung von gesammelten Daten an einen zentralen Ort, der Bridge dient. Die interne und externe Netzwerkkarte arbeiten im Bridge-Modus, so das sie keine IP-Adresse zugewiesen haben. An die dritte Schnittstelle (eth2) ist aber ein IP-Stack gebunden, in diesem Fall hat die Karte die Adresse 10.1.1.1. Bei diesem Netz handelt es sich um ein separates abgesichertes Netz zu Administrationszwecken. Der Vorteil dieses Aufbaus liegt darin, das das Gateway nur extrem schwer zu entdecken ist, da es keinen Hop darstellt, der TTL-Zähler unverändert bleibt und ihm auch keine MAC-Adresse zugewiesen ist. Außerdem können wir die Installation des Honeynets durch die Zusammenlegung von Datenkontrolle und -aufzeichnung auf ein Gerät vereinfachen.

Der nächste Schritt besteht darin, unser Gateway so aufzusetzen, das es unseren Anforderungen genügt. Für das Gateway kommt eine gehärtete Minimalinstallation von Linux zum Einsatz. Es ist entscheidend, das dieses System vertrauenswürdig ist und kein Angreifer Zugriff darauf hat. Als nächstes müssen wir sicherstellen, das das Gateway Bridging unterstützt. Die meisten Linuxdistributionen unterstützen es von Haus aus. Für den Fall das nicht, kann man sich die Bridging rpms oder die Quelltexte von http://bridge.sf.net herunterladen.

gateway #rpm -q bridge-utils
bridge-utils-0.9.3-4
Unglücklicherweise unterstützen die meisten Distributionen zwar das Bridging aber nicht IPTables im Bridging-Modus. IPTables ist aber unverzichtbar, da es nicht nur unser Gateway sichern soll sondern auch zur Datenkontrolle (wird später erklärt) eingesetzt werden soll. Um IPTables auf einem Rechner der als Bridge fungiert nutzen zu können, ist es erforderlich den Kernel zu patchen und anschließend neu zu kompilieren. Auch diesen Kernelpatch kann man von http://bridge.sf.net herunterladen. Nachdem sichergestellt ist, das das bridging installiert ist und der Kernel entsprechend gepatcht ist um IPTables in diesem Modus zu unterstützen kann man mit der Konfiguration des Gateway beginnen. Das ist wesentlich einfacher, als es sich anhört. Das Honeynet Project hat das rc.firewall Skript
http://www.honeynet.org/papers/honeynet/tools/rc.firewall entwickelt. Dieses Skript implementiert fast alle kritischen Punkte des Gateways und wir werden uns im Laufe dieses Artikels immer wieder darauf beziehen. Auf unserem Gateway wird das Skript folgendes tun:
  • Bridging aktivieren
  • Das Gateway mit einer Firewall versehen
  • Die Management-Schnittstelle konfigurieren
  • Festlegen wer wie von wo das Gateway administrieren kann
  • Netzwerkaktivität protokollieren
  • Datenkontrolle sicherstellen
Wie sie sehen, ist dieses Skript extrem wichtig, da es das Gateway so konfiguriert, das es die meisten Anforderungen eines Honeynets erfüllt. Um dieses Skript lauffähig zu machen (und damit Ihre Honeywall zu konfigurieren) müssen Sie lediglich die Variablen anpassen und es starten (Anmerkung: lassen Sie das Skript nicht laufen bevor Sie den gesamten Artikel gelesen haben). Anstatt jede Variable und ihre Funktion detailliert vorzustellen gibt es hier http://www.honeynet.org/papers/gen2/rc.firewall ein fertiges Skript, das wir für unsere oben beschriebene Architektur verwendet haben. Nachdem Sie das Skript für Ihre Architektur angepaßt haben können Sie zur Datenkontrolle weitergehen.

Datenkontrolle

Der Zweck der Datenkontrolle ist es zu verhindern, das Angreifer das Honeynet benutzen um andere Nicht-Honeynet Systeme anzugreifen oder anders zu schädigen. Datenkontrolle mindert dieses Risiko. Die Herausforderung ist jedoch folgende: wie viel nach außen gerichtete Aktivität kann man kontrollieren? Je mehr man dem Angreifer gestattet zu tun, desto mehr kann man lernen. Allerdings gilt auch: je mehr man dem Angreifer gestattet zu tun, desto mehr Schaden können sie auf anderen Systemen anrichten. Also muß man ihre Aktivitäten genug kontrollieren um Schaden für andere zu verhindern aber nicht zu sehr, sonst kann man nichts lernen. Wie viel Freiheit man einem Angreifer zugesteht, hängt also von dem Risiko ab, das man bereit ist einzugehen. Eine zusätzliche Herausforderung besteht darin, den Angreifer zu kontrollieren ohne das er die Kontrolle bemerkt. Um diese Punkte zu erfüllen, werden wir zwei Techniken verwenden: Verbindungen zählen und NIPS. Verbindungen zählen bedeutet, das man die Zahl der ausgehenden Verbindungen, die ein Honigtopf aufbauen kann, beschränkt. NIPS (Network Intrusion Prevention System) kann bekannte Angriffe blockieren oder außer Gefecht setzen. Kombiniert man diese beiden hat man einen mächtigen und flexiblen Mechanismus zur Datenkontrolle. Wir werden beide auf unserem Layer2 Gateway einsetzen. Die Datenkontrolle wird hier angesetzt, da dies der Punkt ist, wo jeglicher Verkehr hindurch muß.

Nachdem Sie ihr Gateway wie oben beschrieben konfiguriert haben, folgt als nächster Schritt die Einschränkung der Verbindungen. Wir kontrollieren, wie viele Verbindungen ein Angreifer von unserem Honigtopf aus initiieren kann und blockieren beim Erreichen eines bestimmten Limits weitere Versuche. Für diese Aufgabe verwenden wir IPTables, das durch das rc.firewall Skript installiert und konfiguriert sein sollte. Im Skript kann man festlegen wie viele TCP, UDP, ICMP oder OTHER Verbindungen nach draußen aufgebaut werden dürfen. Wie viele das sind hängt von Ihrer Risikobereitschaft ab. Das Honeynet Project erlaubt durchschnittlich 15-30 Verbindungen pro Tag. Diese Einschränkung hindert den Angreifer daran, vom Honeynet aus eine Vielzahl von Systemen zu scannen, anzugreifen oder Denial-of-Service (DoS) Angriffe zu starten. Es ist schwierig Schaden anzurichten, wenn man in der Anzahl seiner Verbindungen eingeschränkt ist. Die Standardeinstellungen im Skript sind wie folgt. Beachten Sie, das die Variable OTHER jedes IP-Protokoll umfasst, das NICHT TCP, UDP oder ICMP ist (also zum Beispiel IPsec, getunneltes IPv6, Network Voice Protocol usw.)

### Set the connection outbound limits for different protocols.
SCALE="day"
TCPRATE="15"
UDPRATE="20"
ICMPRATE="50"
OTHERRATE="15"
Auf diese Weise implementiert IPTables die Verbindungseinschränkung. Wenn ein Angreifer in einen Honigtopf einbricht, gibt es verschiedene Gründe Verbindungen nach außen aufzubauen (Toolkits herunterladen, automatische Bots, IRC chats, emails versenden usw.). Wird eine solche Verbindung aufgebaut, zählt die Firewall sie. Wird das Limit erreicht, blockiert IPTables jede weitere Verbindung von diesem Honigtopf. Danach setzt sich IPTables zurück und erlaubt von da an so viele Verbindungen pro Zeiteinheit wie vorgegeben. Nehmen wir zum Beispiel an, das TCP Limit läge bei 25 Verbindungen pro Tag. Bricht jemand in den Honigtopf ein, stehen ihm 25 Verbindungen frei. Erreicht er dieses Limit, kann er keine mehr starten. IPTables wird dann zurückgesetzt und erlaubt ab dann nur noch 25 Verbindungen in dem angegebenen Zeitraum (hier: 24 Stunden). Das heißt pro Stunde kommt eine Verbindung zustande. Wäre der Zeitraum nicht ein Tag sondern z.B. eine Stunde gewesen, so hätte der Angreifer pro Stunde 25 Verbindungen starten können (d.h. alle 144 Sekunden eine). Wie so etwas in Wirklichkeit aussieht kann man hier http://www.honeynet.org/papers/gen2/win2000.txt anhand einer IPTables Protokolldatei sehen. Es handelt sich um einen Windows2000 Honigtopf der mit dem Code Red II Wurm infiziert ist und jetzt versucht weitere Opfer zu finden. Eine nette Fähigkeit von IPTables ist es die Limits getrennt zu verwalten, d.h. ist das TCP Limit erreicht hat das keinen Einfluß auf UDP, ICMP oder OTHER , es sei denn, auch deren Limits wären erreicht.

Nachdem die Verbindungsbeschränkung mit Hilfe des rc.firewall Skriptes aufgesetzt ist, folgt als nächstes die Implementierung der NIPS Funktionen. Die Aufgabe von NIPS ist es, bekannte Angriffe zu erkennen und zu blockieren. Dies wird erreicht, indem jedes einzelne Paket auf seinem Weg durch das Gateway untersucht wird. Erfüllt ein Paket die IDS Regeln wird nicht nur ein Alarm generiert (wie bei einem traditionellen NIDS) sondern man kann auch festlegen ob das Paket verworfen (und die Attacke dadurch blockiert) oder verändert werden soll (macht die Attacke wirkungslos). Der Vorteil hier ist das dramatisch gesunkene Risiko eines erfolgreichen Angriffs. Im Fall der Verbindungsbeschränkung erlauben wir standardmäßig 15 ausgehende Verbindungen pro Tag. Aber was passiert wenn das Honeynet durch einen Wurm infiziert wird, der versucht in diesen ersten 15 Verbindungsversuchen andere Systeme zu befallen? Die Einschränkung reduziert zwar die Zahl der Systeme die er infizieren kann, aber das Risiko bleibt. Die Idee hinter einem NIPS ist, diese Attacken zu erkennen und zu blockieren oder außer Gefecht zu setzen. Zu diesem Zweck nutzt das Honeynet Project Snort_inline
http://www.honeynet.org/papers/honeynet/tools/, eine modifizierte Version von Snort, die Pakete verwerfen oder modifizieren kann.

Damit snort_inline als ein NIPS fungieren kann, braucht es jemanden der für ihn das routing übernimmt, da snort_inline nicht weiß wie es als Router (ip_forward) arbeiten soll. Also brauchen wir jemanden, der die Pakete für snort_inline routet und während des Routingprozesses http://www.honeynet.org/papers/honeynet/tools/ diePakete an snort_inline zur Analyse übergibt. Sobald snort_inline die Analyse beendet hat reicht es die Pakete an den Routingprozess zurück. Dieser Prozess ist IPTables. Wir konfigurieren IPTables so, das es Pakete vor der Weiterleitung zur Analyse durch snort_inline in den user space übergibt und anschließend weiterleitet. Diese Fähigkeit von IPTables heißt "user space queuing" und setzt voraus, das das ip_queue Modul in den Kernel geladen ist. Um diese Fähigkeit zu aktivieren muß lediglich die Option QUEUE im rc.firewall Skript gesetzt werden (das daraufhin auch das Kernelmodul ip_queue aktiviert). Etwas sollte man allerdings beachten, wenn man snort_inline und die Fähigkeit Verbindungen zu zählen von IPTables einsetzt: IPTables zählt die Verbindung unabhängig davon, ob snort_inline das Paket durchlässt oder nicht. Dieses Benehmen kommt daher, da alle Pakete bereits die interne Netzwerkkarte passiert haben bevor snort_inline sie analysieren kann. Die Verbindung wurde also schon gezählt, bevor snort_inline sie überhaupt sieht.

### IPTables script can be used with the Snort-Inline filter
#QUEUE="no"              # Do not use experimental QUEUE support
QUEUE="yes"              # Use experimental QUEUE support
Zu Ihrer Information: wenn Sie die snort_inline Fähigkeiten aktivieren, dann MÜSSEN Sie snort_inline laufen haben. Wenn nicht, oder wenn snort_inline aus irgendeinem Grund stirbt, werden keine Pakete durch IPTables geroutet (dies ist kein Fehler, sondern dient der Sicherheit). Deswegen ist unser nächster Schritt das Konfigurieren von snort_inline. Es ähnelt sehr stark dem von snort, es nutzt nur einen anderen Regelsatz. Denken Sie daran: es ist nicht unser Ziel, allen ausgehenden Verkehr zu verbieten, sondern nur Angriffe. Wir möchten also ein Regelwerk, das nur tatsächliche Angriffe oder Exploits behandelt. Ausgehende Anfragen wie zum Beispiel ein ICMP Ping, ein finger oder ein einfaches http GET Kommando sollen nicht geblockt werden. Wenn wir alle snort-Regeln eintragen, kann der Angreifer nichts nach außen gerichtetes unternehmen. Daher nutzen wir also nur die Regeln, die tatsächlich Angriffe beschreiben. Jede Organisation wird wahrscheinlich andere Definition von "Angriff" haben, daher empfehlen wir, die snort_inline Regeln durchzusehen und gegebenenfalls anzupassen, bevor man sie verwendet. Unser Regelwerk muß außerdem die Umkehrung eines typischen snort-Regelwerks sein, da diese sich auf eingehende Attacken konzentrieren, wohingegen wir nach ausgehenden Attacken suchen. Das Ziel ist es, den Rest der Welt vor dem Honeynet zu schützen. Der letzte Unterschied besteht darin, das wir bei Aktivität keine Alarme auslösen, sondern Angriffe blockieren oder modifizieren wollen. Um diesen Prozess zu vereinfachen, hat das Honeynet Projekt zwei Regelwerke geschaffen, die man zu diesem Zweck einsetzen kann. Das erste ist das drop-rules.tgz http://www.honeynet.org/papers/gen2/figureB.gif. Es dient zum Analysieren von ausgehenden Paketen und wirft bei Erkennen eines Angriffs das betroffene Paket weg oder blockiert es. Was genau geschieht, kann man sich an dem zuvor erwähnten Beispiel einer verworfenen Code Red II http://www.honeynet.org/papers/gen2/cr2.txt Attacke ansehen. Das zweite Regelwerk nennen wir das replace-rules http://www.honeynet.org/papers/gen2/figureC.gif Regelwerk. Dieses Regelwerk blockiert keine Angriffe, sondern verändert den Inhalt der eigentlichen Attacke auf Paketebene und lässt sie so ins Leere laufen. Diese Art von Kontrolle ist für den Angreifer wahrscheinlich noch schwerer zu entdecken. Sie können sehen wie ihre Angriffe die angepeilten Ziele erreichen, aber nicht erklären, warum sie keine Wirkung zeigen. Die drop-rules finden Sie in der Honeynet Tools Section http://www.honeynet.org/papers/honeynet/tools/. An den replace-rules arbeitet das Projekt zur Zeit.

Bei unserer Installation werden wir das "drop-rules" Regelwerk und die
snort_inline.conf Konfigurationsdatei im Verzeichnis /etc/ snort_inline installieren. Wir nehmen ein anderes Verzeichnis als /etc/snort um nicht mit den beiden Versionen durcheinanderzukommen. Um snort_inline zu starten, rufen wir das snort_inline startskript http://www.honeynet.org/papers/honeynet/tools/snort_inline.sh auf. Dieses Skript ist mit allen nötigen Werten vorkonfiguriert um snort_inline korrekt zum Laufen zu bekommen. Um das Leben viel einfacher zu machen, gibt es alle snort_inline Konfigurationsdateien, Regeln, Startskripte und sogar eine vorkompilierte Binärdatei zusammen als Honeynet snort_inline Toolkit http://www.honeynet.org/papers/honeynet/tools/snort_inline.tgz. Durch das Verwenden dieses Paketes sollte die Installation von snort_inline wesentlich einfacher werden. Vergessen Sie nicht: die Kombination dieser Technologien kann helfen das Risiko dramatisch zu reduzieren, aber eliminieren kann es das Risiko nicht. Immer wenn man Hacker zu sich einlädt, kann etwas schief gehen. Das ist der Grund, warum wir im letzten Kapitel erklären, wie man seine Umgebung testet. Aber selbst dann kann man nicht absolut sicher ein, da die Angreifer ständig neue Methoden und Vorgehensweisen entwickeln.

Datensammlung

Nachdem wir die Datenkontrolle sichergestellt haben, geht es jetzt an das Aufsetzen der Datensammlung. Ihr Zweck besteht darin, jede Aktivität des Angreifers zu protokollieren. Eigentlich ist das Sinn des gesamten Honeynets: Daten zu sammeln. Ohne das ist unser Honeynet wertlos. Der Trick bei der Datensammlung ist es, in so vielen Schichten wie möglich zu sammeln. Eine einzige Schicht verrät niemals alles. Ein Beispiel: viele Leute meinen, es reiche doch aus die Tastatureingaben des Angreifers zu kennen. Gut, aber was geschieht, wenn er ein Tool startet? Wie will man wissen, was dieses Tool macht, wenn man es nicht abfängt oder zumindest den von ihm generierten Netzwerkverkehr? Das Honeynet Projekt hat drei kritische Punkte zum Sammeln definiert: Firewallprotokolle, Netzwerkverkehr und Systemaktivität. Wir werden ausführlich erklären, wie man alle drei implementiert.

Firewallprotokolle sind recht einfach und schon behandelt worden. Durch den Einsatz des rc.firewalls Skripts protokollieren wir bereits alle ein- und ausgehenden Verbindungen in /var/log/messages. Diese Informationen sind wichtig, da sie den ersten Anhaltspunkt darstellen, was unser Angreifer macht. Sie sind außerdem die erste Warnung, das ein ausgehender Angriff beginnt. Die Erfahrungen aus dem Projekt haben gezeigt, das die Protokolle wichtig für die schnelle Erkennung von neuen oder unbekannten Vorgängen sind. Das Skript identifiziert vier verschiedene Arten von Verkehr: TCP, UDP, ICMP und OTHER. Wie bei der Datenkontrolle steht OTHER für jeden Verkehr, der nicht vom Typ 1, 6 oder 17 ist. Außerdem ist es wahrscheinlich sowieso das interessanteste, denn jemand der nicht Standard-IP Protokolle nutzt, wird sehr wahrscheinlich eine neue Attacke oder Methode ausprobieren, die bislang unbekannt war (wie bei der Hintertür im Scan des Monats 22 http://www.honeynet.org/scans/scan22/).

Die zweite Schicht ist das Abfangen jedes Paketes im Ganzen, wenn es das Honeynet betritt oder verlässt. Dies könnte zwar der snort_inline Prozeß erledigen, allerdings wollen wir uns nicht zu sehr auf eine Alternative stützen. Stattdessen wollen wir einen zweiten Prozeß starten und so konfigurieren, das er alle Aktivitäten protokolliert. Dies lässt sich durch die Standard snort_inline Konfigurationsdatei http://www.honeynet.org/papers/honeynet/tools/snort.conf des Projekts erreichen. Diese Datei schreibt den gesamten IP-Verkehr zur weiteren Analyse in eine tcpdump-Datei. Diese Dateien sollen außerdem täglich rotieren. Dafür verwenden wir das snort.sh Startskript http://www.honeynet.org/papers/honeynet/tools/snort.sh. Dieses Startskript wird täglich von cron gestartet. Beachten sie, das wir in dem Skript den Sniffer an die interne Netzwerkkarte eth1 binden. Das ist wichtig! Sollten sie aus Versehen den Sniffer an die externe Karte eth0 binden, so schneiden sie nicht nur Daten aus dem Honeynet mit, sondern den ganzen Verkehr der zu dem externen Netz gehört. Dadurch werden die Daten nahezu unbrauchbar. Durch das Verwenden der internen Karte fängt man nur den Verkehr in das und aus dem Honeynet ab: genauso, wie es sein soll. Ein weiterer Vorteil des Skriptes ist es, das man einen Standard für die Ablage der Protokolldateien hat, was sehr wichtig wird, wenn man mehrere Honeynets hat, die alle zu einem zentralen Punkt protokollieren (dazu später mehr).

Der dritte und am schwierigsten zu realisierende Punkt ist das Aufzeichnen der Aktivitäten des Hackers am System selbst. Vor einigen Jahren war das noch einfach, da die meisten Fernzugriffe über Klartext-Protokolle wie FTP, http oder telnet erfolgten. Man musste lediglich die Verbindung belauschen, um die Tastatureingaben abzufangen. Heute jedoch haben die Bösen die Verschlüsselung entdeckt. Sie verwenden SSH oder 3DES verschlüsselte Tunnel um mit den kompromittierten Systemen zu kommunizieren. Also kann man heute nicht mehr die Tastatureingaben am Kabel belauschen, sondern nur an der Maschine selbst. Das Honeynet Projekt hat dazu Sebek2 entwickelt. Sebek2 ist ein Kernelmodul, das in der Lage ist, Tastatureingaben zu protokollieren und Dateien abzufangen, die per secure copy (scp) kopiert werden. Einmal installiert macht es sich unsichtbar und dadurch nahezu unmöglich, es aufzuspüren und zu entladen. Die Informationen die Sebek2 sammelt werden nicht auf dem Honigtopf, wo der Angreifer sie entdecken kann, gespeichert. Statt dessen werden sie per UDP an eine Überwachungsmaschine (wie z.B. das lokale Gateway oder eine entfernte Maschine in einem anderen Netzwerk) gesandt. Angreifer können diese Pakete weder sehen noch abhören, da das Kernelmodul sie verbirgt. Auch wenn der Angreifer seine eigenen Überwachungstools nutzt oder herunterlädt, bleibt die Aktivität von Sebek2 ihm verborgen. Dies wird erreicht, indem man den Honigtopf so verändert, das er Pakete mit einer vorgegebenen MAC-Adresse weder sehen noch mitschneiden kann. Sebek2 schickt dann einfach seine Daten mit dieser MAC-Adresse auf den Weg, wo sie dann von dem Gateway abgefangen werden. Da alle Honigtöpfe von Sebek2 kontrolliert werden kann keiner von ihnen genutzt werden um die Aktivitäten zu belauschen.
Anmerkung: wenn es in ihrem Honeynet einen Honigtopf ohne Sebek2 gibt und der Angreifer erlangt Kontrolle über ihn, kann er alle Sebek2-Pakete von anderen Systemen belauschen.

Da es sich bei Sebek2 um ein Kernelmodul handelt, muß es passend für das jeweilige OS und die Kernelversion kompiliert werden. Die Installation von Sebek2 ist problemlos, da es lediglich fünf Optionen im Installationsskript gibt. Wir installieren so, wie unten gezeigt, d.h. belauschte Tastatureingaben werden in UDP-Pakete verpackt und an die IP-Adresse 192.168.1.254 (den Router) mit dem Zielport 34557 verschickt. Unser Angreifer wird diese Pakete jedoch nie zu sehen bekommen, da der Kernel alle Pakete mit einer SRC MAC Adresse von 0A:0B:0C versteckt (Sebek2 wertet nur die ersten drei der sechs Oktette der MAC Adresse aus). Diese Einstellungen sollten auf allen Honigtöpfen vorgenommen werden, damit sie sich nicht gegenseitig sehen können. Diese Pakete kommen nicht tatsächlich am Router an, da das Gateway sie blockt (und protokolliert). Alle Optionen sind anpassbar an die Bedingungen und die Vorgaben ihres eigenen Honeynets. Wenn sie zum Beispiel die Pakete an ein System in einem anderen Netz schicken möchten, tragen sie die IP-Adresse des Zielsystems und die Ziel MAC-Adresse des lokalen Routers ein. Passen sie auf, das sie das sebek.sh Installationsskript, das dem Sourcecode beiliegt verwenden, da dieses Skript außer der sebek Installation auch noch ein Modul installiert um die Gegenwart von sebek zu verbergen.

#----- sets destination IP for sebek packets
DESTINATION_IP="192.168.1.254"

#----- sets destination MAC addr for sebek packets
DESTINATION_MAC="00:01:C9:F6:D3:59"

#----- defines the destination udp port sebek sends to
DESTINATION_PORT=34557

#----- controls what SRC MAC OUIs to hide from users
#----- Only the first 3 octets are evaluated.
FILTER_OUI="0A:0B:0C"

#----- controls the output interface
INTERFACE="eth0";
Einmal konfiguriert und gestartet, protokolliert Sebek2 die gesamte Systemaktivität ins Netz. Diese Pakete, die von dem Honigtopf weder gesehen noch belauscht werden können, werden passiv am Gateway an der internen Schnittstelle eth0 gesammelt. Diese Pakete werden dann verwendet um Eingaben oder Dateien die der Angreifer heruntergeladen hat zu rekonstruieren. Unser Honeynet hat einen zusätzlichen Vorteil. Da wir eine eigene Schnittstelle zur Administration haben, kann unser Honeynet automatisch protokollierte Daten an eine zentrale Stelle hochladen. Dies kann extrem nützlich sein, wenn sie mehrere Honeynets betreuen. Durch die Kombination der Daten aus verschiedenen Honeynets lassen sich Frühwarnungen, Vorhersagen und statistische Analysen gewinnen oder neue Werkzeuge und Trends identifizieren. Das Honeynet Projekt benutzt dieses Skript http://www.honeynet.org/papers/honeynet/tools/linux-upload.sh um die Daten täglich automatisch hochzuladen. Das Honeynet Projekt portiert Sebek2 gegenwärtig auf Solaris, OpenBSD und Win32.

Alarmierung

Es gibt noch einen letzten Punkt, der bedacht werden will, bevor man sein Honeynet fertig stellt: automatisierte Alarmierung. Wenn jemand in das eigene Honeynet einbricht ist das eine großartige Gelegenheit, etwas zu lernen. Jedenfalls wenn man mitbekommt, das jemand da ist. Das der Administrator über einen erfolgreichen Einbruchsversuch informiert wird ist von entscheidender Wichtigkeit für ein Honeynet. Idealerweise hätte man natürlich eine Rund-um-die-Uhr Betreuung durch einen erfahrenen Administrator. Mit einem entsprechend konfigurierten Programm ist das aber nicht nötig. Wir haben in der Überwachung unserer Honeynets mit Swatch http://swatch.sourceforge.net/ (Simple Watcher) große Erfolge gehabt. Swatch ist en komplett ausgestattetes automatisches Überwachungswerkzeug, das in der Lage ist Admins über potentiell erfolgreiche Einbruchsversuche zu informieren. Swatch überwacht Protokolldateien auf bekannte Muster, die in einer Konfigurationsdatei beschrieben werden. Findet es ein solches Muster, kann es selbstständig Alarme per email, Telefon oder systemeigene Mechanismen auslösen und darüber hinaus andere Programme/Befehle ausführen. Eine einfache Swatch Regel enthält das zu überwachende Muster, gefolgt von einer Liste von zu startenden Aktionen. Das folgende Beispiel basiert auf Swatch 3.0:

watchfor /Firewall:  OUTBOUND CONNECTION/
     echo normal
     mail=admin@honeynet.org,subject=------ ALERT!
	 OUTBOUND CONN --------
     throttle 10:0:0
Die "mail=" Aktion enthält eine Liste von Adressen, an die der Alarm zu schicken ist, während der "throttle" Befehl einschränkt, wie oft die Aktion für diese Regel pro Stunde:Minute:Sekunde ausgeführt werden darf (sehr nützlich um überfüllte Mailboxen zu vermeiden, wenn ein Alarm ausgelöst wird). Das obige Beispiel überwacht /var/log/messages, wohin IPTables alle ein- und ausgehenden Verbindungen protokolliert. Es sucht nach ausgehenden Verbindungen, ein sehr guter Indikator dafür, dass das Honeynet kompromittiert worden ist. Bei Übereinstimmung mit dem gesuchten Muster, wird eine email an den Honeynet Administrator geschickt. Allerdings ist die Häufigkeit solcher Mails in diesem Beispiel auf zehn pro Stunde begrenzt. Die überwachten Muster und die unternommenen Aktionen unterscheidne sich natürlich zwischen den einzelnen Honeynet Installationen. Wesentlich wichtiger als die Feinheiten der Swatch-Konfigurationsdatei ist ein Verständnis dafür, auf welche Ereignisse im Honeynet ein Administrator achten muß und welche Informationen ein Alarm liefern sollte. Die besten Quellen für Informationen über feindliche Aktivitäten sind die Firewall- und snort_inline Protokolle.

Von der Firewall:
Ausgehende Verbindungen von einem Honigtopf sind gute Hinweise darauf, daß die Maschine kompromittiert wurde. Da es keine Benutzer in einem Honeynet gibt, ist Verkehr, der das Honeynet verlassen will sehr wahrscheinlich von einem Eindringling. Es mag von Zeit zu Zeit Fehlalarme geben (z.B. wenn der ftp-Server eine ausgehende Ident-Verbindung aufbaut), aber generell ist dies der beste Indikator für eine Kompromittierung und potentiell bösartige Aktivitäten. Sie sollten vielleicht Alarme über ausgehende Verbindungen nicht einschränken, da die Zahl der erhaltenen Alarme selbst ein Hinweis auf die Art von Aktivität des Angreifers sein kann. Eine andere Möglichkeit wäre es, die Firewall-Protokolle auf Einträge von Sebek2 zu überwachen. Sebek2-Pakete sind ganz hervorragend geeignet, um die Anwesenheit von jemandem festzustellen und werden von der Firewall protokolliert.

Vom NIPS:
Wie schon besprochen ist es die Aufgabe des NIPS (wir nutzen snort_inline) ausgehende Angriffe aufzuspüren und zu blocken. Sie sollten ihren Alarmmechanismus (z.B. Swatch) vielleicht so konfigurieren, das er nicht nur Firewall-Protokolle sondern auch snort_inline Alarme überwacht. Wenn ein Angriff entdeckt (und geblockt) wird, möchten Sie das sofort und unverzüglich wissen.

Das Ziel einer automatisierten Alarmierung ist es, die Administratoren mit so vielen Informationen zu versorgen, das sie auf einen erfolgreichen Angriff reagieren können. Jeder Alarm den Swatch auslöst sollte als Minimum folgendes enthalten: die Quell- und Zieladresse sowie den Port des abgefangenen Paketes, datum und Uhrzeit an denen das Ereignis stattgefunden hat und genug Informationen, damit der Administrator sofort aktiv werden kann. Standardmäßig schließt Swatch die Zeile aus dem Protokoll ein, die auf die Regel passte. Ein Beispielalarm für die obige Regel sähe in etwa so aus:

To:  admin@honeynet.org
From:  yourdatacontrol@yourdomain.org

Subject:  ------ ALERT!: OUTBOUND CONN --------

Apr  6 17:19:05 honeywall FIREWALL:OUTBOUND CONN UDP:IN=br0
PHYSIN=eth1 OUT=br0 PHYSOUT=eth2 SRC=192.168.1.101
DST=63.107.222.112 LEN=123 TOS=0x00 PREC=0x00 TTL=255 ID=43147
PROTO=UDP SPT=5353 DPT=79 LEN=103
Sogar mit den Tools die im Abschnitt über Datenkontrolle vorgestellt wurden erfordert ein Honeynet ständige Überwachung. Korrekt konfiguriert kann Swatch dazu dienen, Administratoren schnell über Vorgänge in ihrem Netzwerk zu informieren.

Testen

Nachdem wir Datenkontrolle und Datensammlung konfiguriert haben, ist der nächste Schritt das Testen des Gateways. Für die Tests brauchen wir ein System mit einer externen Netzwerkschnittstelle. Ausgehend von Abbildung A http://www.honeynet.org/papers/gen2/figureA.jpg nehmen wir die 192.168.1.20 als Testsystem. Wir fangen mit der Datenkontrolle an: erfasst unser Honeynet erfolgreich ein- und ausgehende Verbindungen? Also stellen wir vom Testsystem aus eine Verbindung zu einem der Honigtöpfe innerhalb des Honeynets her. Basierend auf ihrem Regelwerk sollte die Verbindung erlaubt worden sein. Wenn ja, sollte sich in /var/log/messages ein Eintrag ähnlich diesem finden:

Mar 23 20:55:09 honeywall kernel: INBOUND TCP: IN=br0 PHYSIN=eth0 OUT=br0 PHYSOUT=eth1
SRC=192.168.1.20 DST=192.168.1.101 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=48699
DF PROTO=TCP SPT=36797 DPT=21 WINDOW=5840 RES=0x00 SYN URGP=0
Nachdem Sie überprüft haben, das eingehende Verbindungen funktionieren, ist der nächste Schritt das Testen von ausgehenden Verbindungen. Fangen Sie mit dem Zugriff auf einen der Honigtöpfe hinter dem Gateway an (wir empfehlen, das sie über die Konsole auf die Honigtöpfe zugreifen, da der Honigtopf alle Fernzugriffe, wie SSH, lokal protokolliert). Von dort aus versuchen Sie Zugriffe auf verschiedene Systeme außerhalb des Honeynets. Dies entspricht der Situation, das ein Honigtopf kompromittiert worden ist und jetzt von dort aus ausgehende Verbindungen versucht werden, möglicherweise auch ein Angriff. Die Verbindungen sollten in /var/log/messages auf der Honeywall protokolliert werden. In unserem Fall können wir mehrere ausgehende FTP-Verbindungen zu dem Testsystem im Produktionsnetz versuchen. Wenn wir das Limit von fünfzehn Verbindungen erreichen, wird ein "Drop TCP" Eintrag festgehalten. Sie sollten jetzt Einträge ähnlich diesen hier sehen:

Mar 23 17:45:36 laptop kernel: OUTBOUND CONN TCP: IN=br0 PHYSIN=eth1 OUT=br0 PHYSOUT=eth0
SRC=192.168.1.101 DST=192.168.1.20 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=36399
DF PROTO=TCP SPT=1026 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Mar 23 21:14:07 laptop kernel: Drop TCP after 15 attempts IN=br0 PHYSIN=eth1 OUT=br0
PHYSOUT=eth0 SRC=192.168.1.101 DST=192.168.1.20 LEN=60 TOS=0x00 PREC=0x00 TTL=64
ID=63391 DF PROTO=TCP SPT=1030 DPT=21 WINDOW=5840 RES=0x00 SYN URGP=0
Als nächstes möchten wir sicherstellen, das unsere NIPS-Technologie (snort_inline) funktioniert. Glücklicherweise kommen die "drop rules" mit einigen Testregeln, die speziell für Tests entworfen wurden. Stellen sie sicher, das diese Regeln aktiviert sind, bevor Sie die Tests starten. Das Regelwerk das Sie verwenden legt auch fest, welche Tests Sie durchführen können. Nutzen Sie das "drop rules" Regelwerk, testen Sie einfach indem Sie zuerst die Standardtestregel aktivieren, snort_inline mit dem snort_inline.sh http://www.honeynet.org/papers/honeynet/tools/snort_inline.sh Startskript neu starten und dann versuchen, eine ausgehende telnet-Verbindung aufzubauen. Snort_inline sollte den Versuch erkennen, die Verbindung beenden und ins Protokoll schreiben. Der telnet-Versuch sollte nicht funktionieren sondern mit einem Time-Out enden. Sollten Sie ein "replace rules" Regelwerk verwenden, gehen Sie wie oben vor, nur versuchen sie statt telnet ein HTTP GET Kommando. Auch hier sollte snort_inline den Versuch bemerken, verändern und ins Protokoll schreiben. Um sicher zu gehen das die Veränderung stattgefunden hat, stellen Sie sicher, dass Sie an der EXTERNEN Netzwerkkarte eth0 lauschen. Lauschen Sie NICHT an der internen Karte eth1, da das GET Kommando erst geändert wird, nachdem es die interne Karte passiert hat, aber bevor es die externe Karte verläßt. Vergewissern Sie sich, dass Sie nach den Tests die Testregeln wieder deaktivieren (oder die Bösen können diese Tests auch einfach durchführen).

03/23-21:21:05.915340 [**] [1:0:0] Dropping Telnet connection [**]
[Priority: 0]  192.168.1.101:39528 -> 192.168.1.20:23
03/23-21:21:24.054533 [**] [1:0:0] Modifying HTTP GET command [**]
[Priority: 0]  192.168.1.101:38533 -> 192.168.1.20:80
Nachdem die Datenkontrolle überprüft ist, testen wir die Datensammlung. Wenn unser Honeynet nicht alle Aktivitäten protokolliert, dann hat es keinen Wert. Die Funktion der Datensammlung prüfen wir durch Durchsicht der Protokolle. Hat das Honeynet die gerade durchgeführten Tests protokolliert? Zuerst testen wir die Firewall-Protokolle. Das ist einfach, da alle Verbindungen nach in /var/log/messages geschrieben werden sollten. Im einzelnen sollten wir zuerst die eingehende Verbindung sehen, danach die ausgehenden Verbindungen zu unserem Testsystem und als letztes eine Warnmeldung das das Limit für ausgehende Verbindungen erreicht wurde und alle weiteren Verbindungen verweigert werden.
Als nächstes prüfen wir die Netzwerkprotokolle. Wir möchten sichergehen, das wir jedes Paket und den gesamten (Daten-)Inhalt jeder Verbindung, ein- und ausgehend, abgefangen haben. Gemäß unseres Startskriptes sollten diese Protokolle unter /var/log/snort/$DAY stehen, wobei $DAY für den jeweiligen Tag steht. Unserer Erfahrung nach ist es am besten, die Protokolle täglich neu zu beginnen. In diesem Fall stehen die gesuchten unter /var/log/snort/Mar_23. Die Datei, die uns hauptsächlich interessiert ist die binäre Protokolldatei snort.log.*. Es ist möglich, dass Sie außerdem diverse Verzeichnisse mit IP-Adressen als Namen finden. Diese Verzeichnisse enthalten den Inhalt von Paket mit ASCII-Inhalten, wie z.B. FTP Befehle oder html-Seiten. Sie können prüfen, ob snort alle Pakete aufgezeichnet hat, indem Sie die binäre Datei snort.log.* auswerten:
honeywall #snort -vdr snort.log.*
Zum Schluß überprüfen wir die Sebek2 Protokolle. Hier finden sich die Tastatureingaben die das Sebek2 Kernelmodul protokolliert und über das Netzwerk gesendet hat. Diese Pakete sollte der Sniffer (snort) abgefangen haben und man sollte daher in der Lage sein, sie aus derselben Binärdatei die wir gerade analysiert haben, wiederherzustellen. Dazu nutzen wir zuerst sebeksniff, um die Daten wiederherzustellen. Sebeksniff erstellt für jeden Honigtopf (basierend auf der IP-Adresse) eine eigene Datei in /var/log/sebek, die wir dann z.B. nach Tastaureingaben oder Dateiübertragungen per scp (secure copy) durchsuchen können. Die hierzu nötigen Kommandos sind

honeywall #sebeksniff -p 34557 -f snort.log.*
honeywall #sbdump.pl -c /var/log/sebek/192.168.1.101
http://www.honeynet.org/papers/gen2/sbdump.txt
Und das war es. Wenn Sie die Daten analysieren konnten, hat Ihre Datensammlung korrekt gearbeitet. Schauen Sie auch nach Ihrer E-Mail: Sie sollten von Swatch über die gerade gelaufenen Tests benachrichtigt worden sein. Und da Sie ein echter Profi im Bereich der Security sind, wissen wir, das Sie ihr Honeynet Gateway einmal neu starten und noch einmal testen werden, nur um sicher zu gehen.

Nachwort

Wir haben soeben Schritt für Schritt gelernt, wie man ein GenII Honeynet basierend auf einem Bridging Gateway unter Linux aufsetzt. Diese Installation nutzt einige der fortgeschrittensten Technologien für Honeynets. Für die Zukunft hoffen wir, GUIs für die Administration von Honeynets und die Analyse der gesammelten Daten entwickeln und veröffentlichen zu können. Außerdem arbeiten wir an einer bootfähigen Honeywall CD die alle Fähigkeiten mitbringt, die hier besprochen wurden.

Anm. d. Übersetzers

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/gen2
Bitte beachten Sie auch, das das Aufsetzen und Inbetriebnehmen eines Honeynets eventuell rechtliche Konsequenzen haben kann. Falls Sie sich nicht sicher sind, holen Sie sich VORHER fachlichen Rat.


[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