Management und Wissen, Honeypot-Systeme

Honeypots im Unternehmen

Erkenntnisgewinn beim Verteidiger, Zeitverlust und Verwirrung beim Angreifer – Honeypots können vielfältig zur Sicherung von IT-Landschaften im Unternehmen beitragen. Doch auch die Fallen müssen gut gesichert werden, damit sie nicht zur Spielwiese für Angreifer mutieren.

Von Andreas Bunten, Dietzenbach

Aktuell erleben Honeypots einiges an Aufmerksamkeit – auch als zusätzliche Sicherheitsmaßnahme in Unternehmen. Ein Anzeichen dafür ist der Ende 2012 veröffentlichte Bericht der Europäischen Agentur für Netz- und Informationssicherheit (ENISA) zum Thema Honeypots und wie diese für mehr IT-Sicherheit sorgen können [5]. Der Report untersucht ausführlich aktuelle Open-Source-Projekte und ihre Praxistauglichkeit.

Tatsächlich sind die Anforderungen an Honeypots in Unternehmen in der Regel etwas anders als beispielsweise bei Anti-Malware-Anbietern oder im Forschungsbereich (vgl. Kasten): Die Sicherheit der produktiven Systeme muss im Unternehmensumfeld deutlich stärker gewährleistet werden. Da Honeypots einem Angreifer bis zu einem gewissen Grad Zugriff gewähren, ist dies nicht leicht zu garantieren – High-Interaction-Honeypots, die viel Interaktion zulassen und inhärent gefährlicher sind, scheiden dadurch meistens komplett aus. Außerdem muss der Aufwand für Betrieb und Auswertung der Daten absehbar und möglichst gering ausfallen.

[Aufmachergrafik: heller, corporate design]

Honigtöpfe, Lockvögel, Zuckerbrot, ...

Honeypots haben eine lange Geschichte hinter sich und es ist nicht ganz klar, seit wann sie auch in der IT eingesetzt werden. Eine der ersten Erwähnungen lieferte Clifford Stoll in seinem Buch "Das Kuckucksei" [1], in dem er beschreibt, wie er einen Einbruch in ein System des Lawrence Berkeley National Laboratory im August 1986 aufklärt – dabei wurde der Angreifer mithilfe erfundener Daten zum SDI-Programm der USA dazu verleitet, so lange online zu bleiben, dass die Telefonverbindung zurückverfolgt werden konnte.

Was sind Honeypots?

Allgemein kann man einen Honeypot als Ressource definieren, deren Wert darin liegt, dass sie angegriffen, missbraucht oder anderweitig unautorisiert genutzt wird [2]. Dabei kann es sich um einen Netzwerkdienst, eine Anwendung, ein Serversystem oder sogar nur um eine Information handeln.

Beispielsweise könnte man einen Netzwerkdienst in einer vermeintlich verwundbaren Version anbieten: Das System ist so präpariert, dass ein Angriff erfolgreich zu sein scheint, aber alle Aktionen protokolliert werden. Der Betreiber des Honeypots wartet nur darauf, dass eine Attacke in Form illegitimer Login-Versuche stattfindet. Ob dieser Angriff von einem automatisierten Wurm stammt oder ob ein menschlicher Hacker angreift, ist zweitrangig.

Je nach Interessenlage gibt es verschiedene Gründe, Honeypots zu betreiben (s. a. [3]):

Anti-Malware-Anbieter betreiben Honeypots, um neue Varianten von Schadsoftware zu entdecken, die sich im Internet verbreiten. Die so erkannten Viren und Würmer werden analysiert und gehen in die nächsten Signatur-Updates ein.
Sicherheitsteams von Providern sowie Computer-Emergency-Response-Teams (CERTs) betreiben häufig Honeypots im IP-Adressraum ihrer Kunden, um herauszufinden, ob dort Angriffe stattfinden. Oft ist den Besitzern infizierter Systeme dieser Umstand nicht bewusst, sodass eine frühe Warnung durch ein Sicherheitsteam einen hilfreichen Zusatzdienst darstellt.
Forscher verwenden Honeypots, um in Erfahrung zu bringen, wie sich Schadsoftware verbreitet und wie Angreifer vorgehen. Daraus entstehen neue Schutzmaßnahmen und Hinweise für Administratoren, um ihre Systeme besser abzusichern (vgl. [4]).

Es existieren verschiedene Arten von Honeypots, die sich vor allem nach den folgenden Kriterien unterscheiden lassen:

Art der Ressource: Klassische Honeypots bieten Netzwerkdienste an, zu denen sich Angreifer verbinden können. Hier spricht man von Server-Honeypots. Als "Gegenstück" dazu entstanden Client-Honeypots, die sich zu (möglicherweise schädlichen) Serverdiensten verbinden – der Honeypot simuliert dabei in der Regel einen Webbrowser: Wird dieser von einer böswillig manipulierten Webseite angegriffen, erfolgt eine entsprechende Aufzeichnung.
Grad der Interaktion: Hier unterscheidet man zwischen einer mehr oder minder realistischen Simulation einer Ressource im Falle eines Low-Interaction-Honeypots und der Bereitstellung eines realen Systems bei High-Interaction-Honeypots. Ein Low-Interaction-Honeypot kann effizient viele Dienste simulieren – ein menschlicher Angreifer wird andererseits schnell bemerken, dass es sich nicht um einen realen Service handelt. High-Interaction-Honeypots bestehen hingegen zwar oft aus virtualisierten Systemen, aber es wird die echte Software für die jeweilige Ressource eingesetzt – dadurch können sie durchaus auch menschliche Angreifer täuschen. Im Gegenzug geht man jedoch ein größeres Risiko ein, da die Angreifer unter Umständen leichter aus der Honeypot-Umgebung ausbrechen können. Zudem ist die Auswertung der gewonnenen Daten deutlich aufwändiger.

Es existieren noch weitere Honeypots, die etwas aus diesem Schema herausfallen: Ein Beispiel sind so genannte Honey Token – bloße Daten, deren Nutzung detektiert werden kann: Dabei kann es sich um Anmeldeinformationen handeln, die nicht regulär benutzt werden und in einer bestimmten Datei lagern. Meldet sich jemand mit den Daten an, ist es daher möglich, auf Missbrauch zu schließen und entsprechende Spuren auszuwerten. Weiterhin werden spezialisierte Honeypots für bestimmte Situationen verwendet – zum Beispiel USB-Honeypots, die Schreibversuche durch Malware detektieren.

Einsatz-Szenarien

Nachfolgend sind fünf verschiedene Einsatz-Szenarien für Honeypots in Unternehmen erläutert.

Ablenkung der Angreifer in der DMZ

Vor dem eigentlichen Angriff auf eine Unternehmens-IT findet in der Regel eine Erkundung des Ziels statt – beispielsweise ein Scan des erreichbaren Netzwerks, also oft des speziell abgetrennten Bereichs mit Server-Systemen, die Dienste für das Internet anbieten ("Demilitarisierte Zone" – DMZ).

Neben den regulären Servern kann hier ein spezieller Honeypot – eine so genannte Tarpit – nützlich sein: Dieses System bietet scheinbar verschiedene Netzwerkdienste an, verlangsamt aber seine Antworten im Laufe einer Session zusehends. Der Name Tarpit geht auf einen natürlichen Asphaltsee bei Los Angeles zurück, in dem bereits vor mehreren zehntausend Jahren Mammuts und andere Säugetiere "hängen geblieben" und versunken sind. Die ursprüngliche Idee bestand darin, Netzwerk-Würmer durch das zähe Antwortverhalten zu verlangsamen und unschädlich zu machen – durch massiv paralleles Scannen heutiger Wurm-Software ist dies allerdings nicht mehr effektiv.

Wird ein Scan gegen eine solche "Teergrube" durchgeführt, muss ein einzelner Angreifer allerdings dennoch viel Zeit und Geduld mitbringen: Die Verbindungen werden gehalten, aber der Dienst antwortet quälend langsam. Je nach Angriffs-Werkzeug kann die Untersuchung eines einzelnen Dienstes über eine Stunde dauern. Zur Behinderung der Erkundung vor einem Angriff und damit zur Demotivation der Angreifer sind Tarpits daher noch immer sehr geeignet.

Eine Tarpit bietet keinen regulären Dienst an und zugreifende Systeme sind damit grundsätzlich verdächtig – die gewonnenen Informationen können als zusätzliche Bewertung in andere Sicherheitssysteme einfließen.

Es gibt eine Reihe Open-Source-Implementierungen, die in der Regel sehr simpel sind und damit wenig Fehlerpotenzial bieten. Dennoch sollte ein Tarpit-System gründlich abgesichert werden, um zu vermeiden, dass die Angreifer von einem kompromittierten Honeypot aus weitere Systeme attackieren.

Ersatz für ein IDS im internen Netzwerk

In internen Netzen arbeiten oft Intrusion-Detection-Systeme (IDS), um Systeme und Daten zu schützen: Sie belauschen den Netzwerkverkehr und suchen anhand von Signaturen nach illegitimem Verhalten und bekannten Angriffen. Unglücklicherweise ist gerade im internen Netz schwer vorherzusagen, was normaler oder gefährlicher Netzwerkverkehr ist. In der Praxis werden daher oft viele Signaturen deaktiviert oder man muss mit einer hohen Zahl an Falschmeldungen leben.

Ein Honeypot kann hier ähnliche Dienste leisten: Dazu bietet er typische Dienste an und bindet mehrere IP-Adressen aus dem regulären Adressbereich. Kommen zum Beispiel mehrere kleine Netzbereiche zum Einsatz, wäre es möglich, die jeweils ersten und letzten IP-Adressen für den Honeypot zu reservieren. In der Praxis lassen sich bis zu mehrere Tausend Adressen an ein Honeypot-System binden, ohne dass es zu Performance-Problemen kommt.

In diesem Anwendungsszenario genügt teilweise schon die Information, dass ein bestimmtes System einen Verbindungsversuch unternommen hat. Nutzt man hinreichend viele IP-Adressen für den Honeypot, dann ist es auch relativ einfach, zwischen einem "Vertipper" des Benutzers bei der Eingabe der Netzwerk-Adresse und dem systematischen Scan einer Schadsoftware zu unterscheiden.

Bei Einsatz eines Honeypots anstatt eines IDS werden allerdings weniger Gefahren erkannt, da nur Zugriffe direkt auf den Honeypot zu bemerken sind. Im Gegenzug reduziert sich die Rate der Falschmeldungen erheblich – so steigt die Wahrscheinlichkeit, dass auf eine Meldung wirklich reagiert wird. Man sollte hier vorsichtig abwiegen, welche Gefahren entdeckt werden müssen: Eine sich automatisch verbreitende Schadsoftware löst sicher schnell einen Honeypot-Alarm aus – ein manuell agierender Angreifer, der gezielt vorgeht, eher nicht.

Angriffsfrüherkennung für Webanwendungen

Um Angriffe gegen Webanwendungen zu erkennen, werden in der Regel IDS oder spezialisierte Web-Application-Firewalls (WAF) verwendet. Leider sind alltäglich automatisierte wahllose Angriffsversuche zu beobachten, die nur sehr selten Erfolg haben. Doch IDS- und WAF-Systeme können leider kaum zwischen bloßen Angriffsversuchen und tatsächlich gefährlichen oder gar erfolgreichen Angriffen unterscheiden.

Hier eröffnet ein spezieller Honeypot in Form einer vermeintlich verwundbaren Webanwendung neue Möglichkeiten: Zur Sicherheit wird der Lockvogel getrennt von den produktiven Webservern betrieben, ein spezieller Server blendet jedoch dessen Webanwendung in die reguläre Website ein – der Honeypot erscheint dem Angreifer somit als Teil des normalen Internetauftritts. So bleibt ein gewisser Spielraum für Manipulationen, innerhalb dessen ein potenzieller Angreifer "beweisen" kann, dass er tatsächlich eine Gefahr darstellt. Wird beispielsweise ein bestimmter Parameter der Webseite manipuliert, antwortet der Honeypot mit einer vermeintlichen Datenbank-Fehlermeldung – die weiteren Zugriffe der Angreifer werden nun beobachtet, um seine Gefährlichkeit einzuschätzen. Weiterhin könnte es möglich sein, durch Ausnutzung einer vorgeblichen Directory-Traversal-Schwachstelle, eine (spezielle) Passwort-Datenbank zu stehlen: Werden diese Credentials auf der regulären Website verwendet, ist klar, dass dies kein harmloser Angriffsversuch oder nur ein Versehen war.

Erkennung manipulierter Webserver-Inhalte

Drive-By-Downloads sind leider zu einem alltäglichen Phänomen geworden: Angreifer brechen in einen (legitimen) Webserver ein und hinterlegen Exploits zur Ausnutzung von Schwachstellen im Webbrowser der Besucher – für den Betreiber des missbrauchten Webservers ist das in der Regel sehr peinlich, obwohl er selbst ebenfalls ein Opfer der Angreifer war.

Die Absicherung von Webservern und die fortwährende Prüfung ihrer Integrität sind eine umfassende Herausforderung. Manche Organisationen sind zudem in der Position, keinen direkten Zugriff auf einen Webserver zu besitzen, aber dennoch dessen Sicherheit kontrollieren zu wollen – das trifft zum Beispiel auf Hosting-Provider zu. Doch auch in normalen IT-Umgebungen von Firmen kommt es öfter dazu, dass bestimmte Abteilungen für den Inhalt der Webserver zuständig sind und die IT-Security oder Netzwerk-Gruppe keinen direkten Zugriff hat.

In solchen Fällen kann der Einsatz von Client-Honeypots hilfreich sein: Diese werden in einem abgeschotteten Bereich betrieben, sodass eine Gefährdung der produktiven Infrastruktur ausgeschlossen ist. Die Client-Honeypots greifen regelmäßig auf die zu beobachtenden Webseiten zu – führt das Laden einer Seite zu einer Kompromittierung beziehungsweise schickt der Webserver einen Exploit an den Client, dann wird Alarm ausgelöst. Der Webserver wurde dann zwar bereits kompromittiert, aber man hat das Problem selbst zeitnah erkannt und musste es sich nicht etwa von einem Kunden erklären lassen oder gar Tage später davon in der Zeitung lesen.

Honey-Daten als Alarmanlage auf dem File-Server

Allzu oft hört oder liest man (hoffentlich nur in den Nachrichten) von gestohlenen Firmendaten. Haben Angreifer erst Zugriff auf sensitive Informationen, scheint das Schlimmste bereits passiert zu sein. Dies ist jedoch in der Praxis oft nur die halbe Wahrheit: In der Regel werden große Datenmengen transferiert, da die Angreifer selten exakt wissen, was und wo genau sie suchen müssen. Diese Datenmengen aus dem Firmennetz herauszuschmuggeln kostet Zeit – selbst wenn ein Angreifer also bereits weitreichenden Zugriff hat, ist es von großem Vorteil, möglichst schnell davon zu erfahren, um vielleicht das (Aller-)Schlimmste noch verhindern zu können.

In diesem Einsatzszenario besteht die zu beobachtende Ressource aus den Daten selbst: Es kann sich dabei zum Beispiel um Dokumente handeln, die in Verzeichnissen oder auf Datei-Servern lagern, die normalerweise nicht genutzt werden. Ihr Inhalt sollte einigermaßen plausibel erscheinen, muss aber nicht "echt" sein. Der Datei-Server sollte Zugriffe auf diese Dateien protokollieren und entsprechend einen Alarm auslösen. Alternativ ist es möglich, ein bereits vorhandenes Data-Leakage-/-Loss-Prevention-System (DLP) zu verwenden: Dieses sollte einen Alarm auslösen, sobald die "verräterischen" Dokumente das eigene Netzwerk verlassen.

Fazit

Eine 2012 oft diskutierte Erkenntnis war, dass Sicherheitsvorfälle und speziell eine Kompromittierung sich heutzutage kaum noch komplett verhindern lassen. Die Schlussfolgerung daraus ist, dass man sich auf den Fall der Fälle vorbereiten sollte, um dann richtig und schnell reagieren zu können: Gerade zur Erkennung von Angreifern, die den ersten Perimeterschutz eines Netzwerks durchdrungen haben, eignen sich Honeypots sehr gut.

Wer diese Chancen zur frühen Erkennung von Sicherheitsvorfällen nutzen will, muss das "wie" und "wo" jedoch sehr sorgfältig abwägen, um nicht neue Schwachstellen zu erzeugen und so den Angreifern womöglich noch in die Hände zu spielen.

Andreas Bunten ist Senior-Consultant im Competence-Center Security der Controlware GmbH. Im Bereich der Unix-Administration und Security ist er bereits seit 1996 tätig und betreibt seit über zehn Jahren verschiedene Arten von Honeypots.

Literatur

[1] Clifford Stoll, The Cuckoo's Egg, Tracking a Spy Through the Maze of Computer Espionage, Gallery Books Reissue, 2005, ISBN 978-1-4165-0778-9

[2] Lance Spitzner, Honeypots, Tracking Hackers, Addison-Wesley, 2002, ISBN 978-0-321-10895-1

[3] Sebastian Wolfgarten, Virtuelle Leimruten, Honeypots zur Analyse von Angriffen auf Clients und Server, <kes> 2006^#2, S. 72

[4] Andreas Bunten, Torsten Voss, Stille Beobachter, SSH-Angreifern mit Honeypots nachstellen, Uptimes 2012-02, S. 13, www.guug.de/uptimes/2012-2/

[5] European Network and Information Security Agency (ENISA), Proactive Detection of Security Incidents II – Honeypots, 2012, www.enisa.europa.eu/activities/cert/support/proactive-detection-of-security-incidents-II-honeypots