Mit Honeynet Hacker fangen

Honeywall, das Honeynet der neuesten Generation

Praxis & Tipps | Praxis

Mit Speck fängt man Mäuse, mit Honeypots Hacker – und hält sie damit von den wirklich wichtigen Systemen fern.

Honeypots und Honeynets sind bereits seit einiger Zeit als effektive Sicherheitskomponenten bekannt. Dennoch findet man sie noch immer hauptsächlich im Hochschulumfeld. Das könnte sich mit der Toolsammlung "Roo" ändern: Denn damit steht ein (kostenloses) Instrument zur Verfügung, das es erlaubt, ein Honeynet einfach aufzusetzen und zu administrieren sowie potenzielle und tatsächliche Angriffe effizient zu analysieren.

Sehen sich IT-Verantwortliche mit Angriffen auf ihre Systeme konfrontiert, stehen sie vor der Frage, ob es sich um einen gezielten Angriff (etwa Wirtschaftsspionage) oder um "Grundrauschen" aus dem Internet (Portscans, Wurm-Attacken et cetera) handelt. Und obwohl Firewalls oder gar Intrusion-Detection-Systeme (IDS/IPS) im Einsatz sind, ist diese Frage meist gar nicht oder nur mit erheblichem Aufwand zu beantworten.

Seit einigen Jahren diskutieren Sicherheitsexperten daher den Einsatz so genannter "Honeypots" [Siehe L.Grunwald, J.Schlichting; Netzsicherheit; Süße Falle; Honey-Techniken zur Einbruchsvorsorge; iX 6/03, S.102]: Ähnlich wie echte Honigtöpfe in freier Natur Bären und allerlei weiteres Getier anlocken sollen, handelt es sich bei Honeypots um dedizierte Systeme, deren einziger Zweck darin besteht, Angreifer anzulocken und kompromittiert zu werden. Da auf den Systemen keine produktiven Anwendungen laufen dürfen, ist – so sagt die Theorie – jegliche Aktivität zumindest verdächtig.

Betreibt man im Rahmen einer Infrastruktur gleich mehrere Honeypots, spricht man auch von Honeynets. Und obgleich Honeynets äußerst mächtige Werkzeuge beim Umgang mit Sicherheitsvorfällen sind, halten sich vor allem Firmen mit deren Einsatz noch immer sehr zurück. Neben der oft recht aufwendigen Administration derartiger "Opfersysteme" (insbesondere in heterogenen Umgebungen) schreckt in der Praxis meist das verbleibende Restrisiko ab: Schließlich könnte ein Angreifer ein erfolgreich kompromittiertes System auch dazu verwenden, weitere Systeme, zum Beispiel von Mitbewerbern, anzugreifen.

Problematisch ist ferner die mangelnde Korrelation der gesammelten Logdaten. Selbst ein einzeln aufgesetzter Honeypot erzeugt an verschiedensten Stellen Logs (Firewall, IDS, Netzwerkpakete et cetera), die der Administrator erst manuell zueinander in Beziehung bringen muss, will er einem Verdacht nachgehen.

An genau dieser Stelle setzt Roo an: Es sammelt an zentraler Stelle – daher auch der Name "Honeywall" – die Logdaten verschiedenster Quellen wie Argus, Snort, Sebek, p0f und weitere, "normalisiert" sie und schreibt sie in eine MySQL-Datenbank. Eine definierte Schnittstelle bietet anschließend umfangreiche Möglichkeiten für deren Auswertung. Diese Datenaggregation übernimmt der neue Daemon hflowd, der eine bedeutende Rolle in Roo spielt.

Das grundlegende Konzept hinter Roo sieht dabei die folgenden vier Auswertungen vor:

  1. Für jede (versuchte) Verbindung von einem Honeypot nach außen: Zeige die dazugehörige auslösende eingehende Verbindung an.
  2. Für eine eingehende Verbindung: Zeige alle zu dieser Verbindung gehörenden Honeypot-Aktivitäten (Prozesse) an.
  3. Zeige alle dazu gehörenden Netzwerkpakete an.
  4. Zeige die Tastatureingaben des Angreifers auf dem Honeypot an.
Walleye wertet die Prozesse auf einem Honeypot aus.

Die webbasierte Schnittstelle "Walleye" ("on the honeywall") bietet dabei die Verknüpfung dieser Auswertungen bis hin zu kompletten Prozessbäumen sowie Netzwerkmitschnitten an.

Eine potenzielle Überwachungsarchitektur: Alle Produktivsysteme sind von den zu überwachenden Rechner getrennt.

Bei Roo handelt es sich um ein cirka 300 MByte großes ISO-Image, das auf eine CD gebrannt und anschließend sofort gebootet werden kann. Es basiert auf einem gehärteten und stark abgespeckten Fedora Core 3. Aber Achtung: Im Gegensatz zu den meisten Live-Linux-Distributionen wie Knoppix lässt sich die Honeywall nicht von der CD starten – das gesamte System installiert sich auf der Festplatte, sobald man nach dem Booten der CD die Return-Taste drückt. Das erhöht nicht nur die Performance der Honeywall, es vereinfacht auch die Administration des Systems erheblich.

Roo lässt sich mit mindestens zwei, besser drei Netzwerkkarten betreiben: Zwei baut man als "Layer 2 Bridge" zwischen Internet und den zu überwachenden Honeypots ein, sie besitzen daher keine eigene IP-Adresse. Eine optionale dritte Netzwerkkarte – mit eigener IP-Adresse – dient dem SSL oder SSH-geschützten administrativen Zugriff auf die Honeywall.

Die Installation gestaltet sich denkbar einfach: Nachdem das komplette System automatisch auf die Festplatte kopiert wurde, führt ein einfaches Textmenü den Benutzer durch sämtliche Konfigurationsoptionen und nach wenigen Minuten ist die neue Honeywall einsatzbereit. Man braucht jetzt lediglich einen oder mehrere "Opferrechner", die die Honeywall überwachen soll. Dafür eignet sich prinzipiell jeder Rechner, auf dem keine produktiven Anwendungen laufen.

Walleye zeigt, wer mit welchen Mitteln auf den Honeypot-Rechner zugreift.

Bevor man Roo in Betrieb nimmt,sollte der Administrator jedoch einige kleinere Änderungen manuell durchführen. Beispielsweise lassen sich die korrekte Zeitzone sowie das Tastaturlayout nicht durch das Konfigurationsmenü, sondern nur durch Standard-Unix-Kommandos anpassen. Erst anschließend sollte man die vorinstallierten Passwörter der beiden Benutzer "roo" und "root" von "honey" auf einen vernünftigen Wert setzen. Hat man die Passwörter nämlich vor dem Wechsel des Tastaturlayouts bereits geändert, läuft man Gefahr, auf bestimmte Sonderzeichen nur noch schwer zugreifen zu können.

Ferner sollte der Verantwortliche auch bei der Honeywall vor dem Rollout aktualisierte Pakete und Security-Patches installieren. Das komplette System ist RPM-basiert, als Update-Mechanismus steht yum ("yellowdog updater modified") zur Verfügung.Das Kommando yum update führt dabei alle notwendigen Updates GnuPG-gesichert automatisch aus, sofern die Honeywall über eine Internet-Anbindung verfügt.

Es empfiehlt sich, in jedem Fall dieses Update einzuspielen, da auf diesem Wege nicht nur überarbeitete Honeywall-, sondern insbesondere gepatchte Fedora-Pakete installiert werden (hier hat es in jüngster Zeit einige CERTAdvisories gegeben).Schließlich kann man in der crontab des root-Benutzers die folgende Zeile auskommentieren:

  • 0 1 * * * /usr/local/bin/summary.sh

Dieses Skript sendet einmal täglich eine äußerst nützliche Zusammenfassung aller verdächtigen Verbindungen und IP-Adressen an eine frei konfigurierbare E-Mail-Adresse. Offenbar waren die Entwickler bislang nicht selbstbewusst genug, es regelmäßig starten zu lassen – in der Praxis läuft es jedoch sehr stabil.

Das Kernelmodul Sebek erfasst die Tastatureingaben eines Angreifers

Eine der zahlreichen Stärken der neuen Honeywall ist die nahtlose Integration mit dem Tool Sebek. Bei Sebek handelt es sich um ein verstecktes Kernelmodul, das bestimmte Aktivitäten auf dem betreffenden Host aufzeichnen und an einen anderen Host weiterleiten kann. Sebek schreibt vor allem die Systemkommandos open, fork und socket mit und ist damit in der Lage, die Tastatureingaben eines Angreifers mitzuschneiden. Da Sebek tief im Betriebssystem operiert, funktioniert das selbst dann, wenn ein Angreifer beispielsweise von einem kompromittierten Honeypot eine SSL-geschützte Verbindung zu einem externen Host aufbauen will.

Sebek existiert aktuell in verschiedenen Linux- und BSD-Varianten, in einer älteren Version gibt es auch eine Windows-Portierung. Die Installation erfordert in jedem Fall eine (allerdings nicht sonderlich aufwendige) Neuübersetzung des Kernels: Schließlich soll das Werkzeug auch in den Fällen unerkannt bleiben, in denen ein Angreifer einen Honeypot erfolgreich angreifen und einen Netzwerk-Sniffer wie Ethereal darauf installieren konnte. Sebek ist so konzipiert, dass selbst ein Sniffer es nicht bemerkt. Andernfalls würde ein Angreifer ziemlich schnell seine virtuellen Finger von dem System lassen.

Roo ist nun seinerseits in der Lage, die Sebek-Daten beispielsweise über eine UDP-Schnittstelle zu erfassen, ebenfalls in die MySQL-Datenbank zu schreiben und mit den anderen protokollierten Daten in Verbindung zu bringen.

Wer noch einen Schritt weiter gehen möchte, sollte einen Blick auf ein weiteres Open-Source-Werkzeug werfen: mwcollect ist ein kleines, auf Linux/BSD-Systemen laufendes Tool, das Windows-Schwachstellen simuliert und somit Viren, Würmer und andere elektronische Ferkeleien ("Malware") sammeln kann (siehe Kasten So arbeitet mwcollect).

Die Idee dahinter ist, dass ein unter Windows laufender Honeypot zwar ohne großen Aufwand in der Lage ist, die fast ausschließlich hier auftretenden Viren und Würmer zu "fangen", jedoch nach einem Virenbefall oft komplett neu aufgesetzt oder ein sauberes Image zurückgespielt werden muss.

mwcollect hingegen öffnet bestimmte, oft von Malware verwendete Ports (zum Beispiel 2745, einen der "Bagle"-Ports), simuliert dort bestimmte Dienste, nimmt Netzwerkverbindungen auf diesen Ports an und zeichnet sämtliche ankommenden Pakete auf. Eine sehr einfache integrierte Shell-Umgebung bietet sogar die Möglichkeit, über FTP/TFTP andere Dateien, meist ausführbaren Exploit-Code, nachzuladen.

Da das Tool nicht unter Windows läuft, kann der Honeypot nicht kompromittiert werden, die aufgezeichneten Pakete lassen sich jedoch äußerst effektiv analysieren. Versucht ein Angreifer beispielsweise von einem FTP-Server ein Angriffstool nachzuladen, erlaubt mwcollect das und schreibt die heruntergeladene Datei in eine eigene, die man zum Auswerten nun nicht mehr mühselig extrahieren muss. Man kann sie anschließend etwa über den Dienst VirusTotal auf Virenbefall untersuchen – und ganz nebenbei erhält man aus der Logdatei von mwcollect Account- und Passwortinformationen von FTP-Servern, auf denen Angriffstools zum Download angeboten werden (s. Kasten So arbeitet mwcollect).

So arbeitet mwcollect

(…)
[3 22-06-2005 19:01:37] Starting mwcollectd2, have fun!
[3 22-06-2005 19:11:04] Bagle session with invalid auth string: 6D
[3 22-06-2005 23:23:32] Unknown Shell Command: "Minx.pif"
[3 22-06-2005 23:23:32] Downloading of ftp://**********:45872/Minx.pif failed with error code 7.
[3 22-06-2005 23:23:32] Unknown Shell Command: "Minx.pif"
[3 23-06-2005 00:50:52] Unknown Shell Command: "memesystem.exe"
[3 23-06-2005 00:50:52] Downloading of ftp://**********:21/memesystem.exe failed with error code 6.
[3 23-06-2005 00:50:52] Unknown Shell Command: "memesystem.exe"
[3 23-06-2005 00:51:27] Unknown Shell Command: "memesystem.exe"
[3 23-06-2005 00:51:27] Downloading of ftp://**********:21/memesystem.exe failed with error code 6.
[3 23-06-2005 00:51:27] Unknown Shell Command: "memesystem.exe"
[3 23-06-2005 00:55:44] Unknown Shell Command: "run.exe"
[3 23-06-2005 00:55:46] Unknown Shell Command: "run.exe"
[3 23-06-2005 00:55:47] Downloading of ftp://**********:5192/run.exe (ftp://**********:5192/run.exe) successful.
[3 23-06-2005 08:19:30] Unknown Shell Command: "bling.exe"
[3 23-06-2005 08:19:30] Downloading of ftp://**********:1762/bling.exe failed with error code 7.
[3 23-06-2005 08:19:30] Unknown Shell Command: "SMBsvs.exe"
[3 23-06-2005 14:28:37] Unknown Shell Command: "@echo off "
(…)

mwcollect läuftauf Linux/BSD-Systemen und simuliert Windows-Schwachstellen. Dadurch kann es Informationen über Viren, Würmer und weitere Schadprogramme sammeln, ohne von ihnen kompromittiert zu werden.

Die hier beschriebene Honeywall wurde mehrere Wochen in einer Laborumgebung eingesetzt und intensiv getestet. Als Honeypot diente ein mit einer einer IP-Adresse versehener, nicht mehr produktiv benutzter Rechner, der über die Honeywall – aber ansonsten ungeschützt – ins Internet gestellt wurde. Die IP-Adresse war bis dahin unbenutzt und wurde auch anschließend nirgends veröffentlicht.

Der Honeypot lief zunächst unter Windows 2000 (SP 4), die letzten Security Patches sowie Antiviren-Definitionen waren ungefähr ein Jahr alt. Nach wenigen Stunden zeigten sich die ersten Netzwerkverbindungen zu dem Honeypot, kurze Zeit später wurden Port- und Schwachstellenscanner auf ihn aufmerksam und nach cirka zwei Wochen war der Rechner komplett übernommen. Der erheblich zunehmende Netzwerkverkehr zum Honeypot zeigte dabei sehr deutlich, dass die IP-Adresse offenbar in mindestens einer Hacker-Datenbank als "kompromittiert" registriert war.

Mehrere Trojaner und Würmer wurden in dieser Zeit (teils automatisiert, teils manuell) auf dem Honeypot installiert, wie die Roo-Auswertungen schnell zeigten. Der Honeypot versuchte nun, mehrere tausend E-Mails pro Minute zu verschicken, was die Honeywall durch entsprechende Konfiguration verhinderte. Auch zahlreiche weitere versuchte Netzwerkverbindungen blockiert sie.

Da der Honeypot nicht mehr zu "reparieren" war, wurde unter derselben IP-Adresse ein neuer, nun unter OpenBSD 3.7, aufgesetzt. Das System erhielt den Kernelpatch Sebek sowie mwcollect, um weitere Auswertungen unter Roo durchführen zu können.

Da das System offenbar noch immer als kompromittiert gehandelt wurde, trat zunächst ungefähr dieselbe Anzahl an versuchten Netzwerkverbindungen auf. Tatsächlich dauerte es nur sechs Stunden, bis mwcollect den ersten Wurm gefangen hatte. Weitere Würmer sollten in den nächsten Tagen folgen.

Das Honeywall-Werkzeug zeigt alle aufgelaufenen Verbindungen an und setzt sie miteinander in Verbindung

Nach mehreren Tagen unter OpenBSD waren immer weniger Netzwerkverbindungen zum Honeypot zu beobachten, bis schließlich fast ausschließlich das "Grundrauschen" aus dem Internet übrig blieb. Ein weiteres Indiz dafür, dass Rechner nicht nur zufällig missbraucht werden.

Während der kompletten Testphase überwachte die Honeywall, zwischen Honeypot und Internet lauschend, den kompletten Netzwerkverkehr. Zahlreiche Auswertungen konnten durchgeführt werden, und das System lief schon in der Betaversion ausgesprochen stabil. Und obwohl auf der Honeywall ein Intrusion-Detection-System läuft (genauer: mit snort und snort-inline zwei IDS), gehen ihre Warnungen vom Informationsgehalt über "reine" Snort-Warnungen hinaus und enthalten überdies deutlich weniger Fehlalarme ("false positives") als alle kommerziellen IDS-Produkte. Es erfolgten auch Angriffe auf die Honeywall selbst, beziehungsweise auf das Management-Interface, sie blieben aber aufgrund des gehärteten Betriebssystems erfolglos.

Mit der Honeywall "Roo" hat das Honeynet-Projekt ein großer Schritt nach vorne gemacht. Eine beeindruckende Zusammenstellung von Toolkits erlaubt an zentraler Stelle ein einfaches und insbesondere effektives Aufsetzen sowie Administrieren von kompletten Honeynet-Umgebungen. Die vielen umfangreichen Analysemöglichkeiten machen den Einsatz der Honeywall vor allem im Firmen-Umfeld interessant. Im Gegensatz zu den in der Praxis oft wenig bis gar nicht brauchbaren IDS/IPS-Systemen erlaubt sie – vor allem in Kombination mit Sebek und mwcollect – die ausführliche Nachbearbeitung von Vorfällen. Sie hat ihre Stärke vor allem bei der Beantwortung von Fragen nach gezielten Angriffen auf das eigene Netzwerk.

Wo viel Licht ist, findet man naturgemäß auch Schatten: Während die eigentliche Honeywall-Funktion mit minimalen Systemressourcen auskommt, basiert die Analyseumgebung Walleye auf Perl- und Python-Skripts sowie MySQL. Lässt man die Honeywall mehrere Wochen ohne Unterbrechung laufen, wächst die Datenbank sehr schnell an, was die rein webbasierte Auswertung im Laufe der Zeit immer mehr verlangsamt. Wer die Möglichkeit hat, sollte daher seine Datenbank auf leistungsfähigere Systeme exportieren (was die Honeywall anbietet). Ferner laufen noch nicht sämtliche Skripts völlig fehlerfrei – das kann jedoch auch kaum eine kommerzielle Software von sich behaupten. Aufgrund des offenen Quellcodes kann man aber Änderungen jederzeit schnell selbst durchführen und am besten sofort an die Entwickler schicken – diese nehmen Verbesserungsvorschläge dankend entgegen, wie die deutliche Weiterentwicklung seit der Version 1.0 zeigt.

Weiterführende Literatur zum Thema Honeynets ist derzeit leider noch dünn gesät, eine deutsche Übersetzung des Handbuchs steht Online bereit. Man darf gespannt sein, wie sich Roo in nächster Zeit weiterentwickeln wird – die jüngste Idee des Honeynet-Projekts klingt jedenfalls äußerst viel versprechend: Honeygrid. (rek)

Konfiguration der Honeywall Roo

HwPUBLIC_IP=xxx.yyy.15.227
HwLAN_BCAST_ADDRESS=xxx.yyy.15.239
HwHOSTNAME=SecorvoWall
HwSUMNET=xxx.yyy.15.227/255
HwUDPRATE=5
HwSEBEK_DST_IP=192.168.0.44
HwALERT=yes
HwROACHMOTEL_ENABLE=no
HwINET_IFACE=eth0
HwQUEUE=yes
HwTIME_SVR=
HwMANAGE_NETMASK=255.255.255.240
HwSEBEK_DST_PORT=1101
HwSEBEK_LOG=no
HwSCALE=minute
HwFWFENCE=/etc/fencelist.txt
HwMODE=bridge
HwALLOWED_TCP_IN=22 443
HwALIAS_MASK=255.255.255.0
HwMANAGE_IP=xxx.yyy.15.230
HwFWBLACK=/etc/blacklist.txt
HwHONEYWALL_RUN=yes
HwSSHD_PORT=22
HwLAN_IFACE=eth1
HwMANAGE_GATEWAY=xxx.yyy.15.225
HwDOMAIN=secorvo.de
HwMANAGE_IFACE=eth2
Hw_UP_SYSLOG=1
HwICMPRATE=5
HwPRIV_IP=10.0.0.1
HwALERT_EMAIL=root@localhost
HwDNS_SVRS=xxx.yyy.12.2
Hw_UP_HOST=
HwOTHERRATE=5
HwMANAGE_DNS=xxx.yyy.12.2
HwFWWHITE=/etc/whitelist.txt
HwRESTRICT=yes
HwMANAGE_STARTUP=yes
HwSEBEK=yes
HwSSHD_REMOTE_ROOT_LOGIN=no
HwHEADLESS=no
HwFENCELIST_ENABLE=no
HwWALLEYE=yes
HwALLOWED_TCP_OUT=22 25 43 80 443
HwALLOWED_UDP_OUT=53 123
HwDNS_HOST=xxx.yyy.15.227
HwHFLOW_DB=1.1
HwSSHD_STARTUP=yes
HwHPOT_IP=10.0.0.20
HwLAN_IP_RANGE=xxx.yyy.15.224/28
HwSEBEK_FATE=DROP
HwBWLIST_ENABLE=no
HwTCPRATE=5
HwMANAGER=xxx.yyy.15.226
HwMANAGE_DIALOG=yes

Der ursprüngliche Artikel erschien in der iX 01/2006.

Anzeige