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 (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.
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, 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 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 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 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:
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
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.
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 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,
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 die Pakete 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 supportQUEUE="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. 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 Attacke
ansehen. Das zweite Regelwerk nennen wir das replace-rules
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. 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 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. 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.
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).
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 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. 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 packetsDESTINATION_IP="192.168.1.254" #----- sets destination MAC addr for sebek packets