Honeypot

Ich war versucht, hier ein Bild von "Winnie the Pooh" mit der Tatze im Honigglas zu platzieren. Denn ein Honeypot (Engl- für Honigtopf) ist in Netzwerken System, welches normalerweise von niemandem angesprochen wird und daher keinerlei Zugriffe erhalten sollte. Angreifer aber "scannen" in der Regel die erreichbaren Netzwerke und finden so auch dieses Systeme, die normale Anwender nie ansprechen. So kann ermittelt werden, wer solche Scans ausführt. Wenn dieses System sich dann noch als ein bestimmter Server ausgibt oder angeblich Dienste bereit stellt, kann auch noch weiter verfolgen, ob der "Scanner" dann auch versucht sich auf dem System einen Zugang zu verschaffen.

Position eines Honeypot

Grundsätzlich kann ein Honeypot an jeder Stelle eines Netzwerks eingesetzt werden. Das ist sogar sinnvoll, da Angreifer ja auch überall unterwegs sein können. Aus dem Internet sind Angriffe zwar häufig aber interne Angriffe sind sogar noch kritische, da hier meist keine Firewall dazwischen ist und mehr Bandbreite zur Verfügung steht.

Wenn Sie nun annehmen, dass solche Systeme nur im Internet sinnvoll sind, damit z.B. Provider befallene Systeme ihrer Kunden erkennen, irrt. Gerade im internen LAN sind solche Frühwarnsensoren wichtig um solche Versuche frühzeitig zu erkennen und einkreisen zu können. Es sind meistens nicht dir direkten Zugriffe aus dem Internet auf einen Service im Internet, sondern viel mehr die Trojaner und Viren, die sich ein Anwender einschleppt und dann intern an die vermeintlich von extern nie erreichbaren Systeme los geht.

Standort Beschreibung

Internet

Wenn die erste Firewall schon Angriffe abwehrt, dann sehen Sie ja gar nicht, was versucht wird. Daher könnten Sie einen Honeypot nach "draußen" stellen. Wobei ich diese Position bei klassischen Kunden ungerne nutze. Das ist eher die Aufgabe der Carrier und Hoster um durch solche Systeme mehr über Angreifer zu erfahren. Als Firma müssen Sie sich nämlich auch überlegen, wie Sie die Meldungen dann in ihr System bekommen. Und wenn der Honeypot "gekapert" wird, dann hat der Angreifer einen Sprunghost für weiter. Da draußen stehen aber in der Regel keine Systeme von ihnen. Also ist der Mehrwert eher theoretischer Natur.

DMZ

Interessanter wird es schon, wenn Sie Server veröffentlichen und diese in eine eigene Netzwerkzone stellen. Die klassische DMZ ist eigentlich schon überholt aber viele Firmen betreiben noch diese Konstruktion mit mehreren Servern in einer DMZ. Wenn dann einer der produktiven und natürlich von extern erreichbaren Server gekapert wird, dann sucht der Angreifer natürlich weiter. Ein Honeypot in der DMZ kann dann ein Ziel sein. Da der Server aber nur dazu da ist, sollten dann alle Alarmglocken schrillen.

Eine andere Variante ist natürlich ein Honeypot, der von extern über ausgewählte Ports erreichbar ist.

Intern

Es ist aus meiner Sicht gar nicht so ungewöhnlich einen Honeypot auch mal intern hin zu stellen. Wir gehen mal nicht von dem "bösen Anwender" aus, der von innen ihre Systeme angreift. Diese Wege können Sie durch Endpoint Security (802.1x Authentifizierung, Applocker u.a.) schon sehr erschweren. Aber es gibt natürlich Malware, die ein Anwender sich z.B. über ein Office-Makro oder andere Download einfängt und mit seinem Benutzernamen startet. Emotet und Crypto-Trojaner werden natürlich erst mal die "einfachen Ziele" suchen, die der Benutzer legitim erreichen kann und dort Daten verschlüsseln oder Mail senden.

Aber da diese Schädlinge auch Malware dynamisch nachlagen können, ist natürlich auch mal ein Netzwerkscan/Portscan o.ä. drin, um sich mal umzuschauen, wo der Angreifer gelandet ist. Auch hier kann ein Honeypot Alarm schlagen

Sie müssen sich schon überlegen, welche Aufgabe der Honeypot ausführen soll. Möchten Sie ein problemloses und "leises" System haben, was mit minimalen Ressourcen gar nicht auffällt und sofort bescheid sagt, wenn eine Verbindung darauf aufgebaut wird? Oder ist ihr Ziel eher die Analyse eines Angriffs, indem sie den Angreifer gewähren lassen und alle Aktionen protokollieren. Entsprechend müssen Sie Aufwand betreiben.

Honeypot Komplexität

Die nächste Unterscheidung mache ich mal bei der Ausführung des Honeypots. Hier stufe ich folgende Klassen ab:

Typ Beschreibung

Single Host: "Port Detection only"

Eine Software auf einem Server überwacht einfach, welche eingehenden Pakete auf dem System landen. Das kann klassisch schon die vorhandene Firewall loggen und dahinter muss gar nichts sein. So ein System ist schnell und einfach aufgesetzt und ist mangels Software kaum real angreifbar. Allerdings wird man den Angreifer auch nicht gut beobachten können, da er sich ja nichts an der Maschine abarbeitet.

Single Host: Service Simulation

Besser ist es daher ,wenn die interessanten Ports auch offen von von einem Service bedient werden, der dem Angreifer den Eindruck gibt, er könnte hier was finden. Ein Mailserver könnte ja Mails annehmen, so dass man die Muster erkennt. Auch ein TELNETD oder SSH-Service könnte z.B.: Anmeldeversuche einsammeln. Auch WebServer oder SQL-Server mit vielleicht "schwachen" Versionen können Angreifer neugierig machen. Allerdings sollte der Angreifer ihren Honeypot nicht als Basis für weitere Angriffe auf andere Host bieten. Die nächste Stufe ist eine umfangreichere Simulation, so dass der Angreifer glaubt sich anmelden zu können und auf dem "gehackten" Systemen weitere Aktionen durchführt.

Network Simulation: Service Simulation

Einen Schritt weiter geht dann ein komplettes Netzwerk von Honeypots mit simulierten Routern u.a. Das ist natürlich eine ganz andere Klasse und deutlich komplexer. Das Netzwerk muss ja ein Stück weit "individuell" erscheinen, damit auch ein Angreifer nicht sofort den Braten riecht.

Real Host

Natürlich können sie auch ein System "ungeschützt und ungepatched" aufstellen und einfach überwachen, was damit passiert. DAs ist aber schon ein Spiel mit dem Feuer und kann ganz schnell nach hinten los gehen. So ein System sollte dann in einem Subnetz stehen, aus dem es wirklich nicht ausbrechen können sollte und streng überwacht wird. Aber das wird ein Angreifer natürlich auch schnell durchschauen aber da er nun ja die Kontrolle über das System hat, kann er von dieser Basis aus aktiv ihre Schutzvorkehrungen angreifen.

Ich bin kein ausgewiesener Sicherheits-Fachmann. Ich beschränke mich daher darauf, meinen Kunden erst einmal den Sinn und den Aufwand zu erklären. Es muss ja nicht gleich der "Honeynet"-Simulator sein. Schon ein einfacher "versteckter" Host, der versuchte Verbindungen erfasst, ist einfach installiert und liefert erste Daten.

Honeypot und verwundbare Systeme suchen

Ein Honeypot stellt allerdings keinen Schutz für bestehende produktive Systeme dar und ein Angreifer mit einem Ziel wird sich vielleicht nicht durch einen "Scan" nach Diensten im LAN verraten, wenn er viel einfacher über DNS-Anfragen die Domain Controller und Exchange Dienste (Autodiscover) ermitteln und zielgerichtet erreichen kann. Aber sie glauben gar nicht, wie viele Endgeräte vergleichsweise schlecht oder gänzlich ungesichert in einem LAN betrieben werden.

Insofern kann es auch sinnvoll sein, selbst auf die Suche nach "offenen" Systemen oder Honeypots zu gehen. Zum einen wollen Sie ja auch prüfen, ob ihr Honeypot auch anschlägt, wenn er gescannt  wird. Zum anderen können Sie so vielleicht Schwachstellen finden, ehe Sie ein Angreifer findet. Ein erster Anfang ist ein Inventar des Netzwerks z.B. über die den Abruf der Endgeräte von Switches und Routern.

Eine zweite Option ist natürlich ein Scan des Subnetzes mit NMAP o.ä., bei dem jede IP-Adresse entsprechend analysiert wird. Es ist natürlich nur eine Moment-Aufnahme ihres Netzwerks und kein Sicherheitsscan geschweige denn eine eingehender Analyse mit passiver oder aktiver Suche auf Schwachstellen. Aber es ist manchmal schon interessant, welche Details so ein Programm in einem Netzwerk ermittelt. So ein Scan sollte durch einen Honeypot natürlich erkannt werden.

Der erste Schritt

Die Idee eines Honeypot ist nicht neu und so finden sich im Internet mehrere Programme und Frameworks, die einen "verletzlichen Host" vorgaukeln. Sie laufen natürlich auf einem Gast als Prozess unter Beobachtung oder müssen selbst so abgesichert sein, dass ein Angreifer nicht eine Lücke im Honeypot nutzt, um daraus auszubrechen. Das ist bei "simulierten" Webservern umso gefährlicher, je umfangreicher die Honeypot-Simulation ist. Es gibt bereits fertige Programme verschiedener Quellen, wobei meine Lise hier keine Empfehlung sein soll:

Einfachere Honeypots können z.B. auf einem Mini-Computer wie dem "Raspberry" laufen, welcher wenig Strom braucht und irgendwo "versteckt" werden kann. Als PERL oder PHP-Skript sind dem Einsatzbereich fast keine Grenzen gesetzt.

Honeypot für Exchange Administratoren

Es muss nicht immer der "große universelle Honeypot" sein. Als Exchange Administrator können Sie sich auf die Dienste SMTP, HTTP und eventuell auch POP/IMAP konzentrieren. Installieren Sie einfach einen Windows Server mit dem Windows SMTP-Service und einem IIS. Den Server tragen sie idealerweise gar nicht im DNS ein und addieren Sie ihn auch nicht in die Domäne. Damit ist die "Windows Firewall" auch ziemlich verschlossen. Mit einer IP-Adresse im Netzwerk steht er einfach in ihrem Netzwerk und dürfte von niemandem angesprochen werden und selbst auch nicht aktiv werden. Nur Windows Update und die Updates für den Virenscanner könnten den Server verraten.

Die Wahrscheinlichkeit ist aber hoch, dass der Server doch durch einen IP-Scan/Port-Scan eines ungebetenen Gastes gefunden wird. Der wird dann natürlich versuchen, sich darauf anzumelden. Und genau das hinterlässt Spuren, auf die wir reagieren können. Zuerst natürlich einfach mal als Information an eine verantwortliche Person.

Es muss aber gar kein eigener Server sein. Ein normaler Exchange Server vor in der Regel eben nicht per SMTP von Clients angesprochen. Sie nutzen bevorzugt doch Outlook über MAPI/RPC, MAPI/HTTP oder RPC/HTTP oder gleiche HTTP für OWA/ActiveSync. Schon der Versucht per Port 25 eine Verbindung von einem nicht bekannten System aufzubauen, könnte ein Hinweis auf eine Malware sein, die nach einem Mail-Relay sucht.

Honeypot für Skype for Business Administratoren

Es kniffliger ist es mit Skype for Business. Die WebDienste von Skype for Business sind noch einfache HTTP-Requests und können genauso wie bei Exchange bedient werden. Interessant ist hier natürlich das Protokoll "SIP", über den sich nicht nur Clients anmelden können sondern z.B. auch VoIP-Gateways angebunden sind. Wer schon mal einen Service auf Port 5060 im Internet angeboten hat wird sehr schnell erkennen, dass auch diese Ports intensiv geprüft werden. Wer ein VoIP-Gateway ohne Anmeldung auf 5060/5061 offen lässt, kann schön sehen wie Angreifer versuchen darüber zu telefonieren. Sie erhoffen sich damit kostenfreie Telefonate oder rufen Premium-Nummern an, an deren Erlösen sie beteiligt sind.

Detector mit Windows Firewall

Sie müssen aber gar nicht erst groß Software installieren. Schon die bordeigene Windows Firewall kann zumindest Verbindungsversuche und Erfolge protokollieren. Sie sehen damit zwar nicht, was "drin" passiert ist oder wie viele Pakete übertragen wurden aber sie erkennen eben die Verbindungen und Versuche. Sie müssen die Einstellung nur aktivieren denn per Default ist sie nicht aktiv. Wann fehlt nur noch eine "Auswertung", die versuchte Verbindungen auf für einen Angreifer interessante Ports erkennt

Honeypot mit PowerShell

Es gibt für Linux verschiedene fertige Honeypot-Systeme und mein Ziel ist es gar nicht, diese nachzubauen oder besser zu machen. Auch die Analyse von Angreifern durch eine möglichst perfekte Simulation ist nicht mein Ziel. Aber eine eine Verbindung angenommen wird und die ersten Interaktionen protokolliert, weiß man schon mehr über den Angreifer und seine Motive und dass es kein versehentlicher Connect auf einen Port ist. Den reinen Verbindungsversuch könnten sie auch per Windows Firewall Logs erfassen. Ich denke, dass sich folgende Protokolle recht schnell umsetzen lassen würden.

Protokoll Port Beschreibung und Nutzen

SMTP

25/TCP

Einen Mailserver vorzugaukeln ist recht einfach und nach dem HELO/EHLO muss der Client über MAIL FROM und RCPT TO zumindest offenbaren, wohin er senden will oder was er probt. Wenn Sie noch eine Authentifizierung anfordern, können Sie den vielleicht einen Benutzernamen und Kennwort mitschneiden. Sie kennen dann den Benutzer oder wissen, dass dessen Zugangsdaten kompromittiert sind.
Für die Analysen auf der XOORG und Exchange habe ich schon ein SMTP Blackhole gebaut, der sicher einfach zu erweitern ist.

POP3/IMAP4

110/143 TCP

Auch ein Abruf per POP/IMAP ist in den meisten Firmen nicht gewünscht, da Exchange und andere Systeme sehr viel leistungsfähigere Systeme haben. Ein Verbindungsversuch kann also ein Client sein, der nicht unter der Verwaltung der Firma steht. Dann wird der Angreifer vielleicht auch einen Benutzernamen mit Kennwort versuchen. Wenn die Zugangsdaten stimmen, dann kennen Sie den Angreifer oder wissen, dass seine Daten kompromittiert sind.

SIP

5060/5061

Es wäre gar nicht mal ungewöhnlich, wenn auch intern Schadsoftware oder Angreifer einen SIP-Server suchen und Anrufe versuchen. Gerade wenn es Session Border Controller oder Skype for Business in der Umgebung gibt.

TURN

3478

Auf der Seite End2End-UDP3478 habe ich einen Test geschrieben, um TURN-Verbindungen zu messen. Der Server ist dabei ein Edge-Server. Wenn ich mich selbst als "Edge-Server" ausgebe, der auf einen eingehende Anfrage entsprechend antwortet, könnte man auch solche "wilden" Clients einfangen.

HTTP/HTTPS

80/443/8080 u.a.

Noch immer sind Angriffe auf Webserver ein lohnendes Ziel. Gerade im internen Netzwerk gibt es vielleicht den ein oder anderen Webserver mit einem unsicheren Versionsstand oder schwacher Absicherung, über den ein Angreifer dann Code mit erhöhten Berechtigungen starten kann.

Sicher sind noch andere Protokolle (SQL, TerminalServices etc.) ebenso interessant. Die Frage ist einfach, wie aufwändig die entsprechende Emulation dahinter zu entwickeln ist. Schließlich muss der Code ja "Multi Threading" sein oder einfach damit umgehen können, dass mehrere Verbindungen gleichzeitig zu bedienen sind. Auf den Seiten Powershell und TCP und PS HTTPServer habe ich schon die Grundlagen beschrieben, wie man per PowerShell einen WebServer oder TCP-Server starten kann. Beide Codes sind aber "blockend", d.h. wenn auf Daten eines Prozesses gewartet wird, bleibt das Skript erst mal "stehen". Der Code muss also mit Jobs "parallelisiert" werden.

Der Honeypot kann sowohl im LAN als auch in der DMZ oder sogar im Internet gute Dienste leisten. Mein Einsatzzweck ist aber primär das interne LAN und vielleicht eine DMZ. Gegen Angriffe aus dem Internet ist eine Firewall der beste Schutz, die nur die wenigen erforderlichen Dienste erreichbar macht. Natürlich sollte so ein Honeypot auf eine Verbindung umgehend den Administrator informieren. Wenn sogar die Anmeldedaten korrekt sind könnte das Konto aktiv wegen Missbrauchsverdacht gesperrt werden.

Als ich SMTP Blackhole für die Analyse von XOORG und Exchange geschrieben habe, wollte ich am liebsten auch noch einen IMAP4, POP3, SIP, HTTP und TURN-Service schreiben. Leider geht sehr viel Zeit in so eine Entwicklung und ich bin einfach noch nicht dazu gekommen. Fürs erste denke ich eher an die Aktivierung uns Auswertung der Windows Firewall Logs. Ganz aufgegeben habe ich das Projekt aber noch nicht. SMTP Blackhole ist ja zumindest ein kleiner SMTP-Honeyport, auch wenn er noch nicht Alarm schlagen kann.

Weitere Links