Honeynet-Projekt

Ein Honeynet ist eine Menge von Maschinen (so genannte Honeypots), welche die Aufgabe haben, Angriffe auf ein Netzwerk aufzuzeichnen. Die Grundidee eines Honeypots ist es, eine Menge von Netzwerkdiensten anzubieten, die legitimen Benutzern unbekannt sind und die keine Funktion im operativen Betrieb des Netzwerk erfüllen. Nachdem die Dienste unbekannt sind, können sie nur dann gefunden werden, wenn ein Angreifer das gesamte Netzwerk nach bestimmten Diensten absucht. Typischerweise geschieht dies mittels eines Portscanners, der Anfragen an alle Rechner im Netz sendet. Falls ein Dienst von einer Maschine angeboten wird, beantwortet diese die Anfrage entsprechend und signalisiert dadurch dem Angreifer die Verfügbarkeit eines Services. Nachdem der Angreifer nicht weiß, welches Service zu den operativen Rechnern und welches zu einem Honeypot gehört, werden Attacken normalerweise gegen alle ent- deckten Dienste gestartet. Ein Honeypot sollte jedoch niemals legitime Anfragen erhalten. Daher ist jede Verbindung zu einem der Dienste eines Honeypots automatisch verdächtig.

Man unterscheidet üblicherweise zwischen zwei verschiedenen Arten von Honeypots, low-interaction und high-interaction Honeypots [1]. Ein low-interaction Honeypot stellt keine wirkliche Implementierung eines Netzwerkdienstes zur Verfügung, sondern emuliert nur einen Teil der Funktionalität. Im einfachsten Fall wird auf jede Anfrage mit einer standardisierten Antwort reagiert (z. B bei honeyd [2]). Andere low-interaction Honeypots realisieren einen größeren Teil der Funktionalität und erlauben es, mehrere Pakete mit einem Angreifer auszutauschen (z. B. nepenthes [3] oder honeytrap [4]). Dies hat den großen Vorteil, dass bei solchen Honeypots mehr Daten vom Angreifer gesendet werden, die dann gespeichert und analysiert werden können. So kann man zum Beispiel die Payload von neuer Malware (wie z. B. von Würmern) sammeln, die sich automatisch im Netzwerk verbreiten.

Bei einem high-interaction Honeypot wird das Netzwerkservice tatsächlich vollständig implementiert und läuft typischerweise auch direkt auf einem richtigen Server. In diesem Fall lassen sich natürlich die meisten Informationen sammeln. Das Problem mit high-interaction Honeypots ist jedoch, dass es aufwendig ist, diese zu installieren und zu warten. So muss man zum Beispiel nach jedem erfolgreichen Angriff gegen einen Netzwerkdienst den Rechner von den Auswirkungen dieser Attacke säubern, typischerweise durch eine Neuinstallation des Betriebssystems. Außerdem lassen sich auf einer physika- lischen Maschine oft nur wenige high-interaction Honeypots parallel unterbringen (z. B. mittels VMware [5]), während ein einzelner Rechner oft tausende low-interaction Honeypots laufen lassen kann. Dies ist wichtig, wenn man bedenkt, dass von einem Honeynet oft mehrere tausend IP-Adressen abgedeckt werden müssen.

Nachdem die Dienste eines Honeypots durch einen Angreifer gefunden werden sollen, ist es von Vorteil, möglichst viele Honeypots in einem Honeynet zusammenzufassen. Vor allem wenn ein Angreifer (oder ein Computerwurm) zufällig ausgewählte IP-Adressen mit einem Portscan untersucht, erhöht sich klarerweise die Chance, dass ein Honeypot darunter ist, wenn mehr Adressen von dem Honeynet abgedeckt werden. Daher war es uns sehr wichtig, vom ZID einen möglichst großen, unbenutzten Adressbereich zur Verfügung gestellt zu bekommen. Der gesamte Traffic zu diesen Adressen sollte dabei zu unserem Honeynet umgeleitet werden. Der ZID hat uns für unser Honeynet großzügigerweise 4.096 IP-Adressen zur Verfügung gestellt, die in 16 Class C Netzwerke mit jeweils 256 Adressen aufgeteilt sind. Das Routing des TU-Netzwerks wurde vom ZID so angepasst, dass alle Pakete an diese Adressen an einen Rechner in unserem Lab weitergeleitet werden, der das Honeynet hostet. Dieser Rechner ist so konfiguriert, dass er auf Anfragen an jede der 4.096 IP-Adressen entsprechend antwortet.

Ein wichtiger Forschungsschwerpunkt bei uns am Secure Systems Lab [6] ist das Studium von Malware (wie Viren und Würmer). Insbesondere untersuchen wir Techniken, um neuartige Formen von bösartigem Code erkennen und klassifizieren zu können. Dazu ist es natürlich notwendig zu wissen, welche Arten von Malware sich zurzeit besonders aktiv im Internet verbreiten. Außerdem benötigen wir real-world Samples, an welchen wir unsere neuen Algorithmen und Techniken ausgiebig testen können. Um einen Einblick in die Verbreitung von Malware zu erhalten und eine repräsentative Menge von Vertretern der verschiedenen Klassen sammeln zu können, eignen sich besonders low-interaction Honeypots. Deshalb haben wir auf unserem Honeynet nepenthes installiert, ein low-interaction Honeypot, der explizit zum Sammeln von Malware, Viren und Trojanern ausgelegt ist.

Ein wichtiger Punkt, der berücksichtigt werden muss, ist, dass das Weiterleiten des Netzwerkverkehrs vom ZID an unser Honeynet vor etwaigen Filtern oder Firewalls erfolgt, damit wir die ganze Breite von bösartigem Traffic überwachen können. Das widerspricht allerdings der Sicherheitspolicy des ZID, die einen Grundschutz für alle Rechner innerhalb des Netzwerks vorsieht [7]. Dieser Grundschutz blockiert automatisch Pakete zu bestimmten Diensten, die sich in der Vergangenheit als besonders anfällig für Angriffe gezeigt haben. Dieser Grundschutz ist natürlich vernünftig, um das Netzwerk vor Angreifern zu schützen. Er stellt allerdings ein Problem für unser Honeynet dar, weil wir ja gerade an diesen Angriffen interessiert sind. Glücklicherweise konnte ein Kompromiss erzielt werden und ein Class C Netzwerk kann jetzt völlig uneingeschränkt vom Internet erreicht werden. Dies erlaubt uns auch, einen Vergleich zu ziehen zwischen jenem Bereich, der vom Grundschutz abgedeckt ist, und jenem, der freigeschaltet ist. Zum Beispiel lässt sich zeigen, dass bestimmte, populäre Angriffe Dienste betreffen, die als Teil des Grundschutzes automatisch vom ZID geschützt werden.

Unser Honeynet zeichnet alle Pakete auf, die an eine der 4.096 IP-Adressen unseres Honeynets geschickt werden. Das erlaubt es uns, Statistiken zu erstellen, die zeigen, wie intensiv das Netzwerk der TU Wien Angriffen aus dem Internet ausgesetzt ist. Außerdem lässt sich verfolgen, welche Dienste zu einem bestimmten Zeitpunkt besonders interessant für Angreifer sind. Falls es zu einer plötzlichen Änderungen kommt und ein unbeachteter Dienst auf einmal besonders viel Netzwerkverkehr anzieht, kann das ein Hinweis darauf sein, dass eine neue Schwachstelle in diesem Dienst entdeckt worden ist, die von Angreifern aktiv ausgenützt wird. Der ZID könnte in diesem Fall reagieren und diesen Dienst zum Beispiel kurzfristig in den Grundschutz aufnehmen, um eine Infektion der Maschinen innerhalb der TU zu verhindern.

Die folgende Graphik zeigt die Gesamtanzahl der Verbindungen pro Tag für den Monat Oktober. Insgesamt wurden in den 31 Tagen 7.695.402 Verbindungen registriert (durchschnittlich fast 250.000 pro Tag). Sehr schön kann man die Schwankungen während der Woche erkennen; an Wochenenden wird typischerweise weniger Traffic gemessen.

In Tabelle 1 werden jene zehn Dienste (mit Portnummer) aufgelistet, die das häufigste Ziel von Verbindungen waren. Diese Tabelle zeigt, für welche Dienste sich Angreifer und Computerwürmer am meisten interessieren. Interessant ist, dass unter den Top-10 auch Port 135 aufscheint, der eigentlich durch den Grundschutz von außen nicht erreichbar ist. Ein Großteil der Verbindungen zu diesem Port kamen von Rechnern innerhalb des TU-Netzes, die durch die Firewall nicht blockiert werden.

In Tabelle 2 werden jene Dienste aufgelistet, die am häufigsten in jenem Class C Netzwerk kontaktiert wurden, das ohne Grundschutz direkt aus dem Internet erreichbar ist. Es fällt auf, dass diese Liste Tabelle 1 sehr ähnlich ist. Der größte Unterschiede zeigt sich bei den Ports 139 und 4444. Beide Ports tauchen im Zusammenhang mit Wurmangriffen auf, 139 wird von Sasser angegriffen, 4444 wird vom Backdoor des Blaster Wurms verwendet.

Seit das Honeynet in Betrieb genommen wurde, ist es uns gelungen, mittels nepenthes 180 unterschiedliche Malware Samples zu sammeln. Diese Samples, typischerweise Würmer, werden von uns im Rahmen unserer Forschung weiter analysiert. Außerdem leiten wir die Samples an Ikarus (einen Wiener Antivirushersteller) weiter, der dann bei Bedarf die Signaturdatenbank seines Virenscanners auf den neuesten Stand bringen kann.

Ein weiterer Nutzen des Honeynets liegt darin, dass wir jene Maschinen innerhalb des TU-Netzwerks identifizieren können, die das Netzwerk nach Diensten absuchen (scannen). Üblicherweise ist so ein Verhalten ein deutliches Zeichen dafür, dass die Maschine mit einem Computerwurm infiziert ist, der nach weiteren Opfern sucht. Wir übermitteln die Liste der gefundenen Scanner täglich und automatisch an die Security-Abteilung des ZID, der dann entsprechende Maßnahmen einleiten kann. Im Oktober haben wir insgesamt 24 infizierte Maschinen innerhalb des TU-Netzwerks entdeckt. Die Mehrzahl dieser Rechner waren interessanterweise Maschinen, die sich über das drahtlose Netzwerk oder über Einwahlleitungen von zu Hause mit dem TU-Netzwerk verbunden haben. Es waren aber auch einige Rechner von Universitätsinstituten darunter.

Ein Honeynet kann nicht nur dabei helfen, die Trends von Angriffen im Internet zu beobachten und zu dokumentieren, sondern dient auch dazu, Malware zu sammeln, die sich erfolgreich im Netz verbreitet. Für unser Honeynet auf der TU Wien hat der ZID großzügigerweise einen Adressbereich von 4.096 IP-Adressen zur Verfügung gestellt. Unsere Honeypots registrieren im Durch- schnitt täglich fast 250.000 Verbindungen und helfen mit, infizierte Maschinen im TU-Netz zu identifizieren.

Natürlich lässt sich das Honeynet noch weiter ausbauen. Zum Beispiel kann man die Anzahl der überwachten IP-Adressen oder die Menge jener Rechner, die nicht vom Grundschutz betroffen sind, erhöhen. Zusätzlich möchten wir das Honeynet noch mit Client-Honeypots erweitern. Anders als bei dem oben beschriebenen Netzwerk, wo Honeypots auf Angriffe von außen warten, surfen Client-Honeypots automatisiert im Internet. Das Ziel ist es, aktiv bösartige Seiten im Web zu entdecken, die Schwachstellen im Browser ausnützen. Wenn eine Menge von Client-Honeypots automatisch im Web surfen, kommt es natürlich zu einem hohen Paketaufkommen im Netzwerk. Auch hier sind wir auf die Unterstützung vom ZID angewiesen, der die entsprechende Bandbreite zur Verfügung stellen müsste.

[1] Lance Spitzner; Honeypots - Tracking Hackers; Addison-Wesley, 2003

[2] http://www.honeyd.org/

[3] http://nepenthes.mwcollect.org/

[4] http://honeytrap.sourceforge.net/

[5] http://www.vmware.com/

[6] http://www.seclab.tuwien.ac.at/

[7] http://www.zid.tuwien.ac.at/security/portsperren.php