 Und ich muss einen Announcement machen, dieser Gespräch ist nur ein Honipot. Sie können nicht, sie glauben mir nicht, siehst du? Okay, wer von den Leuten in die Publikum betreibt einen Honipot? Auf die Audienz, bitte, damit ich etwas sehen kann. Danke. Ein paar Leute melden sich. Glaubt ihr, dass sie sicher sind? Glaubt ihr, dass man die nicht gegen euch verwenden kann? Denkt lieber noch mal drüber nach. Die in Süßmann und Itamashere werden euch jetzt zeigen, wie man einen Honipot übernehmen und gegen euch verwenden kann. Also einen warmen Applaus, bitte. Ja, hallo zusammen. Leider. Und kann Gaddi heute nicht hier sein, also müssen wir es ohne ihn machen. Er ist eigentlich ein wichtiger Sprecher in jedem Talk. Es wäre schön, wenn er heute hier sein könnte, aber leider geht's nicht. Okay, worüber wollen wir reden? Was wir machen werden, ist, wir werden euch zeigen, wie ein Honipot zu eurem Vorteil genutzt werden kann, aber auch wie es in der Vergangenheit benutzt wurde, wie wir das verbessern können. Okay, so, erst mal ein kleiner Disclaimer. Es ist ein technischer Talk, also wir werden eine Menge technische Sachen auf den Folien haben. Aber wie ihr seht, und das ist vielleicht überraschend für einige, man braucht sehr wenig Vorwissen, um viele der Sicherheitsmaßnahmen von beliebten Honipots zu überwinden. Das heißt also, diese Geschichten werden dann doch recht grundsätzliche Sachen sein. Und das hier so ein bisschen über uns, also wir arbeiten alle zusammen bei Symmetria. Wir haben das schon seit einigen Jahren hier gemacht, und das ist ein großer Teil unserer Leben und ein großer Teil der Community. Also als allererstes möchte ich mal reden darüber, was ist Cyber Deception? Das ist so ein komisches Buzzword, und man könnte sich vorstellen, als ein Anwalt sowas verwendet, ohne richtig zu wissen, was das überhaupt ist. Wir würden gerne in der Lage sein, das Verhalten eines Angreifers zu benutzen und seine Methoden zu benutzen und zu beeinflussen. Denn wenn wir das machen können, dann gewinnen wir dadurch die Fähigkeit, sowas zu erkennen und Angriffe vielleicht zu verhindern. Und wir haben eine ganze Reihe von interessanten Sachen, die wir machen können, sobald wir den Entscheidungsprozess der Angreifer manipulieren können. Viele Leute haben in diesem Feld schon Forschung betrieben. Es sind sehr viele Deutsche auch dabei. Das Deception Toolkit von Fred Cohen war eines der ersten. Lance Spitzner, das Handynet Project, die haben sehr großartige Arbeit geleistet und haben dieses Forschungsfeld in den letzten Jahrzehnten wirklich weitergebracht. Und worüber wir reden möchten, ist, dass die meisten Leute meinen, was Handy Pots für einen machen können, ist doch großer Unterschied zu dem, was Handy Pots wirklich machen. Also was ist der Unterschied jetzt zunächst mal zwischen einem Angriff und einem Angreifer? Eine Angriff ist etwas, was sich dynamisch verändert, was man schwer abfangen kann. Es gibt verschiedene Werkzeuge, die herausfinden sollen, wenn man attackiert wird. Und es gibt natürlich solche Mechanismen, haben immer auch ein paar false positives und das ist also ein Problem. Die Angreifer selber haben aber immer eine sehr spezielle Methode, wie sie arbeiten, wie sie sich in ihrem Netzwerk bewegen, wie sie vielleicht irgendwelche Authentifizierungscredentials in ihrem Netzwerk bekommen können. Und das sind solche Sachen, die man sehr schwer auf eine andere Art und Weise machen kann. Und hier sehen wir ungefähr, wie sich ein Angreifer fühlen muss, wenn er sich in eurem Netzwerk befindet. Es gibt also hier diesen, diesen, diesen Pfad. Ich habe also ein Netzwerk infiltriert und ich will irgendwie zu den Informationen kommen, die mich interessieren. Und das ist eine der Vorteile, den der Verteidiger gegenüber dem Angreifer hat. Der Verteidiger kennt sein Netzwerk sehr viel besser als der Angreifer. Also warum nutzen wir diesen Vorteil nicht aus? Und wenn man das ganze mal von Gesichtspunkt der Strategie so betrachtet, in der US-Armee und in der US-Luftwaffe, haben sie hier diese Methodik entwickelt, die sich UDAR nennt. UDAR bedeutet Observe, also Beobachten, Orient, Orientieren, Design Act, also einen Entschluss fassen und ausführen. Und das ist das, was ist ein taktisches Prinzip. Und wenn man beeinflussen kann, was in der Zeit passiert, wo die Observation, also die Beobachtung stattfindet, dann kann man damit alle weiteren Phasen beeinflussen. Also was wir im Grunde machen wollen, ist das hier. Das ist vielleicht ein bisschen schlechter Metapher, denn Wiley Coyote verliert ja normalerweise gegen den Roadrunner, aber im Grunde ist das also, was wir machen wollen. Wir wollen den Angreifer auf eine falsche Pferde leiten. Und wenn wir in der Lage sind, den Angreifer auf diese Art und Weise fehl zu leiten, dann könnte das eine große Veränderung herbeiführen. Es ist etwas, was nicht sehr teuer ist zu machen, aber für den Angreifer kann das sehr teuer werden. Und heute machen wir sowas noch nicht. Und wenn wir die einzelnen Elemente uns anschauen, wie wir einen Angreifer auf die falsche Pferde leiten, dann bricht man das auf sehr wenige einzelne Einheiten im digitalen Netzwerkrunde. Per Definition sollte ja niemand in der Lage sein, über diese Verwirrungsstrategien irgendwas zu wissen. Ein Angreifer oder irgendjemand sonst, der sich im Netzwerk herumschaut und und Sachen machte ja nicht tun sollte, kann also erkannt werden. Und das gibt einem gewisses Wissen über Sachen, die im Netzwerk vor sich gehen. Und wenn man zum Beispiel feststellt, dass irgendwelcher neuer Code ausgeführt wird auf einem bestimmten Rechner, dann weiß man genau, das handelt sich dabei um Angriffskode. Und jetzt schauen wir mal die populärsten Honeypots an und reden ein bisschen darüber, wofür sie nützlich sind. Und dazu gehören solche Sachen wie das Scannen nach Botnetzen. Aber im Grunde sind ihre Fähigkeiten irgendwie ein bisschen begrenzt. Und der Grund dafür ist, dass diese Honeypots eigentlich nur Sachen emulieren. Also sie machen keine wirklichen Sachen, sondern sie simulieren nur. Und wenn ein Angreifer die dann erreicht, dann besteht ein Risiko für denjenigen, der versucht zu verteidigen. Nämlich, es besteht im Grunde darin, dass derjenige, der verteidigt, nicht in der Lage ist, den Angreifer vollkommen dafür zu überzeugen, dass es sich hier um ein echtes System handelt. Wenn also der Angreifer weiß, wo sich der Honeypot im Netzwerk befindet, dann wird der Angreifer es vermeiden, diesen Rechner gezielt anzugreifen, denn die Warnmeldung, die dann kommen würden, würden ihn ja verraten. Okay, und dann gibt es noch einen Unterschied zwischen sogenannten Low- und High-Interaction-Honeypots. Low-Interaction bezieht sich im Grunde nur auf ein Protokoll, während High-Interaction sich auf die ganze Maschine bezieht, die ein Angreifer eben angreifen kann. Und um die Thermologie klarzumachen, die Lage, ein Fingerprint eines Honeypots zu erstellen, ist das alleine schon eine Schwäche? Es ist sehr interessant, dann nehmen wir zum Beispiel mal Tor. Es gibt eine ganze Reihe von Schwächen über die Codesführung möglich ist, aber woran wir in Tor hauptsächlich interessiert sind, jemand, der das Tor Netzwerk angreift, ist die Identität eines Endbenutzers. Wenn man also die IP-Adresse eines Torbenutzers rausfinden könnte, ist das dann eine Schwäche, also meiner Meinung nach ja. Es ist so ein bisschen ein grauer Bereich. Bei Low-Interaction-Honeypots geht es einfach um Simulationen von Netzwerktiezen. Zum Beispiel SMB, SMTP, DNS, so populäres Zeug halt, das Hacker finden wollen. Es ist ziemlich einfach, also Leute schreiben da halt den wie ein Skript, dass dieses Protokoll, das Verhalten des Protokolls implementiert und dann schärft man sich an, wer mit einem spricht und dann sieht man da, was halt da reinkommt. High Interaction-Honeypots sind halt die Systeme selbst. Also wenn ich jetzt zum Beispiel an SMTP-Server zeigen will, dann muss ich ja auch einen echten SMTP-Server haben. Es ist halt natürlich viel schwieriger zu überwachen. Wenn ich jetzt einfach mal zum Beispiel Windows rechenehm und den SMB-Traffic überwachen will, also das Wahnsinn. Es ist unglaublich viel Rauschen gibt auch und dann sind wir wieder zurück im normalen Problem mit ja, false positives und wie finde ich raus, was da tatsächlich das Interessante ist an den Messdaten. Also wir wollten dann halt herausfinden, hat das sonst jemand probiert, Honeypots zu identifizieren? Also show dann hat dieser interessante Website hier, die heißt HoneyScore. Also ja, man gibt da eine IP-Adresse ein und sagt dann, ist es ein Honeypot oder nicht? Also wir, ja, wir haben da ein bisschen rumgespielt. Wir haben es allerdings nicht geschafft, dass es einem anzeigt, dass sein Honeypot ist. Wir haben auch selber Honeypots aufgesetzt und haben das dann nachgeschaut und es hat einem nie gesagt, dass sein Honeypot ist. Ja, dann haben wir weitergesucht und haben Konpot gefunden. So ein skadermäßiges Honeypot-Thing. Also es sieht aus, als wäre es eine Skadermaschine und da implementiert aber nur ein ganz kleiner Teil des Protocols. Und einer der Showdown-Leute hat halt das untersucht und hat gemerkt, dass jede Konpot-Implementation den gleichen Namen hat, das nämlich Mouser Factory. Und, na ja, da hat halt jemand gemerkt, dass es einfach jetzt die Standard-Einstellung und es wurde dann so angerichtet, dass man das ändern kann und das nächste war dann, ja, das ist halt überall die gleiche Seriennummer und wenn man jetzt nach dieser Nummer sucht, dann findet man genau diese Honeypots. Ja, die sind alle Konpot. Ja, dann haben wir mal so eine IP-Adresse hier eingetragen und dann, ja, tatsächlich zeigt es an, dass es ein Honeypot ist. Also ja, leider funktioniert die Suchmaschine halt nur für ganz, ganz bestimmte Dinge, aber für das meiste nicht. Also jemand im Publikum bittet mich, langsamer zu sprechen, also gut. Ja, wir werden jetzt mal einige Projekte anschauen. Also werden schauen Sie mal die populären Honeypot-Projekte an, ja, von den einfachsten bis zu den kompliziertesten und ich zeige euch, wie jedes von denen eine weitere Schicht Tarnung eingibt. Also fangen wir mal mit Artillerie an, Artillerie. Das ist ein sehr cooles Projekt, das ist sehr, sehr verbreitet. Man führt das einfach aus und es öffnet halt alle Pots, die so aussehen, also werden sie interessant für Angreif, also DNS, HTTP und so weiter. Und jedes Mal, wenn man ein Port in Zugriff gibt, dann gibt es eine einfach zufällige Information raus. Ja, so für all diese Pots, die Artillerie konfiguriert. Und dann wird man blockiert durch eine Regel, die in IP-Tables eingetragen wird. Also wenn ich jetzt halt Artillerie laufen lasse auf meine Maschine und wenn jemand da jetzt nach SMTP-Server sucht in mein Metz, dann wird natürlich dieser Honeypot getroffen und Artillerie blockiert an diesen Endpunkt, diese IP-Adresse. Ja, das sieht jetzt halt nicht wahnsinnig täuschend echt aus. Ja, das sieht ja offensichtlich nicht wie SMTP-Traffic aus. Ja, es gibt einfach zufällige Daten, also es geht nicht darum, dass sich ein echter Dienst nachmacht. Ja, das ist ziemlich gefährlich. Das Problem ist halt, wenn in diesem Netzwerk kein Schutz vor Spoofing ist, kann man jede IP spoofen und dann wird Artillerie diese IP-Adresse blockieren. Also das heißt, man kann Artillerie dazu bringen, beliebig IP-Adressen zu blocken, indem man einfach zwei Pakete Daten schickt. Das geht natürlich auch für die Gateway-Adresse in diesem Netzwerk. Also das heißt, man kann machen, dass es komplett aus dem Netzwerk fällt. Ja, was lernen wir jetzt davon? Wenn es ein Port gibt, den niemand anfassen sollte, dann ist das ein Hinweis auf einen möglichen Angriff. So, jetzt setzen wir es mal in den Standpunkt des Angreifers. Also das heißt, jeder Ort, an dem ich mich jetzt hinverbinden könnte, könnte eine Falle sein. Wie gehe ich damit um? Bairtrap, das nächste Projekt. Bairtrap implementiert tatsächlich gewisse dieser Dienste. Das größte, das da drin ist, ist FDP. Wenn man jetzt mit Bairtrap spricht, dann kommt dieses Banner. Ja, also wenn man jetzt weiß, dass Bairtrap ein Honeypot ist, dann ist es im Prinzip, wenn man das da sieht, ist es so, als wenn man sich selber in den Fuß schießt. Also Bairtrap sagt einem im Prinzip, hallo, ich bin ein Honeypot. Aber man kann das natürlich auch konfigurieren. Das heißt, man kann da jeden x beliebigen Text reinschreiben. Aber das ist die Standard-Einstellung. Und das ist eigentlich nicht wirklich geeignet dazu, einen Angreifer zu täuschen. Eine weitere Sache, die wir herausgefunden haben, die auch nicht konfigurierbar ist, ist, im Grunde gibt man dem ganzen Ding nur ein, also jeder FDP-Befilm, den man hinschickt, man bekommt das Antwort immer, fehler 530 zurück. Und das ergibt eigentlich im Zusammenhang mit dem FDP-Protokoll keinen Sinn. Also kein anderer echter FDP-Server würde sich so verhalten. Das Protokoll ist so definiert, dass wenn man einen Nutzerbefehl hinschickt, dann soll es einen bestimmten Antwort zurückliefern. Und einfach 530 zurückzuliefern, dann gibt es keinen Sinn. Denn das ist keine spezifische Antwort auf den Befehl, der man hinschickt hat. Das heißt also, da ist es auch sehr leicht möglich, Bairtrap effektiv zu erkennen. Wenn wir uns andere FDP-Server anschauen, wie zum Beispiel WS-FTP, was da passiert, wenn man mit verschiedenen Befehlen arbeitet, dann sieht man hier, dass da wirklich auch spezifische Antworten zurückkommen. Bairtrap leidet außerdem unter denselben Problemen, was IP-Spoofing angeht, wie Artillery. Also es macht da im Grunde genau das Gleiche. Sobald es sieht, dass sich jemand verbindet, dann fragt es noch nach dem Bundesrat Nahmen und Passwort. Und sobald das angegeben wurde, dann wird eine IP-Tables-Regel erstellt, die dann ausgehend die Ursprungs-IP blockiert. Und auf diese Art und Weise kann man auch hier die XP-Libby-Maschine einfach aus dem Netz schmeißen. Also was haben wir da gelernt, wenn wir einen Service implementieren, dann ist das schon besser, was die Täuschung eines Angreifers angeht. Aber wenn wir das Ganze aus der Perspektive des Angreifers betrachten, dann ist es natürlich klar, als Angreifer werde ich jetzt gezielt nach Sachen gucken, an denen ich ganz eindeutig erkennen kann, dass es sich hier um einen Honeypot handelt. Und im Falle vom Beartrap ist das eben diese default Welcome Message. HoneyDee ist einer der bekanntesten Honeypots. Es ist eigentlich mehr eine Plattform als ein einzelner Honeypot. Es ist eigentlich eine ganz coole Sache, denn es erlaubt es euch, verschiedene Sachen an HoneyDee reinzuschreiben und zu erweitern. Also man kann verschiedene Arten von Netzwerkservice erstellen und für jeden dieser Netzwerkservices kann man ein Skript hinterlegen, dass dieses Protokoll implementiert. Das Problem dabei ist allerdings, dass HoneyDee mit einer ganzen Reihe von Standardskripten ausgeliefert wird, die jeder benutzt, denn im Grunde will man ja nicht das Rad zweimal erfinden und ein Protokoll wie FTP oder SMTP, was bereits vorhandenes nochmal schreiben müssen. Und in diesen Protokollen, das erlaubt dann natürlich auf sehr einfache Weise diesen HoneyDee ein Fingerprint erstellen und zu erkennen. Also wenn man HoneyDee für etwas benutzt, wenn man will zum Beispiel einen IIS-Server emulieren, dann gibt es hier oben den Befehl, den wir hier oben auf der Folie sehen, und HoneyDee versucht diesen Befehl zu implementieren. Denn das ist halt was, was viele automatischen Scanner Tools benutzen, um von einem IIS-Server eine Verzeichnisliste abzuholen. Und was dann passiert ist, genau die gleiche Antwort wird jedes Mal von jedem HoneyDee-Server zurückgeschickt. Und wenn wir uns die Datum und Zeit anschauen, wann die Dateien zuletzt verendet wurden, dann müssen wir feststellen, in den letzten 15 Jahren hat irgendjemand diese Dateien angefasst. Und das ist nicht sehr glaubwürdig, und es erlaubt auch einem Angreifer sehr einfach zu erkennen, dass er es hier mit HoneyDee zu tun hat. Wenn wir uns die anderen Protokolle anschauen, es gibt noch eine Reihe weiterer Möglichkeiten, um HoneyDee zu erkennen. FTP, beispielsweise, unterstützt nicht den Deletbefehl, der einem normalerweise Dateien löschen lässt. Ich nehme an, das ist Absicht so, denn es ist natürlich ein bisschen gefährlich, einem Angreifer zu erlauben, Dateien in meinem Honeyport zu löschen, denn ja, damit könnte er im Grunde Sachen auf eurem System beschädigen. Das SSH-Script macht eigentlich gar nichts. Es öffnet einen Port und schickt keine Antworten zurück. Also es ist ein weiterer Weg, wie man das erkennen kann. Und wie man es auch macht, für den Angreifer wird es sehr bald offensichtlich sein, dass er es hier mit HoneyDee zu tun hat. Ein möglicher Korrektur für AIS könnte zum Beispiel einfach eine leere Verzeichnisliste zurückliefern. Denn die Liste, die zurückliefert wird, enthält ein Haufen Zeug, und man muss das schon glaubwürdig machen. Man sollte verschiedene Sachen natürlich auch regelmäßig durch Zufallswerte ersetzen, wie z.B. Beidgrößen ähnliches, und was wir daraus lernen können, ist, wenn wir einen Service implementieren, dann sollten wir keine ganz offensichtlichen Hinweise auf uns zurückliefern. Im Grunde ist das auch wieder nur, als ob HoneyDee schreiben würde, Hallo, ich bin ein Honeyport, und wiederum aus der Perspektive eines Angreifers. Jeder Service, mit dem wir reden, da sollten wir eigentlich schauen, ob er es zum Teil nur implementiert ist und manche Sachen einfach fehlen. Nächste Haltestelle, Nova. Nova ist ziemlich cool. Was es tut, ist benutzt HoneyDee auf eine Art und Weise, die mehr aus der Perspektive einer Gesamtlösung zu sehen ist. Das heißt, man hat hier eigentlich ein ziemlich cooles User-Interface. Wir können Maschinen erzeugen, wir können uns die Logs anschauen, und wir haben da eine Reihe von Konfigurationen. Also einen Stadt, das man einfach nur an bestimmten Ports, bestimmten Skrips hängt, oder was auch immer, und das sieht dann wirklich so aus, wie eine Maschine in diesem Netzwerk. Das Problem ist, wenn wir eine Windows-Maschine erzeugen, die Standard-Windows-Konfiguration hat keinen Netbios-Service-Crypt. Netbios ist allerdings ein sehr altes Protokoll, das auf jeder Windows-Maschine existiert, und es wird ganz, ganz oft in den Netzwerken benutzt, wo Windows-Maschinen sich drin befinden. Die benutzen Netbios beispielsweise um andere Maschinen im Netzwerk zu finden. Also was dann passiert? In seiner Standard-Konfiguration ist erzeugt einen offenen Port für Netbios und erlaubt auch Verbindungen dahin, aber es implementiert den Service überhaupt nicht. Das heißt, da ist ein offener Port, man kann damit reden, aber man bekommt nie eine Antwort zurück. Das ist eine Situation, die einer echten Windows-Maschine nie passieren würde. Die einzigen beiden Optionen, die man also hat, also entweder ist es durch eine Firewall gesperrt, aber dann würde ja der Port als geschlossener Schein, also im Grunde man sieht sofort, dass es sich hierbei um eine Nova-Windows-Maschine handelt. Ein möglicher Fix wäre vielleicht die neueste Version von Honey, die mitzuliefern, denn das hat ein Netbioscript oder aber einfach den Port 139 zulassen. Was können wir davon lernen? Wir sollten einen Service vollständig implementieren. Und aus der Perspektive eines Angreifers, wir sollten die Services anschauen, die eine Maschine uns anbietet, aber eben vollständig. Wenn es aussieht wie eine komplette Maschine, dann müssen wir feststellen, ob das wirklich alles Sinn ergibt. So, jetzt zu Kippo. Kippo ist ziemlich cool. Es ist ein Medium-Interaction-Honeypot für SSH. Das bedeutet also, man bekommt eine SSH-Shell, die man auch benutzen kann, aber die ist nur halb implementiert, denn auf die Art und Weise, wie das eben gemacht ist, wird halt eben alles mitgeschnitten. Also es gab jede Menge Forschung, die man kennen kann. Und einer der möglichen Wege ist, über die die Leute geredet haben, viele der Befehle, die man normalerweise absetzen könnte, sind nicht implementiert. Aber einer, der existiert, ist Weget. Und der Grund, warum Weget implementiert ist, ist, wenn ein Angreifer diesen SSH-Honeypot angreift, dann soll er ja in der Lage sein, seine Tools, seine Mailware von anderen Seiten runterzuladen. Das heißt, man erlaubt, ihm Weget zu nutzen. Und das ist eigentlich eine ziemlich große Angriffsfläche. Man könnte das benutzen, zum Beispiel, um einen DDoS-Angriff auf andere Maschinen durch solche Honeypots auszuführen. Man könnte auch einen Portscanner auf das Netzwerk durchführen. Im Grunde bietet man damit seinen eigenen Relay in seinem eigenen Netzwerk, den der Angreifer für alles Mögliche nutzen kann. Und das ist ein Riesenproblem. Eine weitere Sache, was Leute gemacht haben, sie schauen, wie Kippo die SSH-Otentifizierung durchführt. Und wie sich herausstellt, das hier ist ein Teil des Kippo-Quelltexts. Es ist ein Fingerprinting-Problem, was bereits korrigiert ist. Aber was dieses Stück Code tut, wenn man das fragt, welches Protokoll möchtest du benutzen, dann sagt es einfach, ich unterstütze alles. Und das ist einfach nicht so, wie die meisten oder wie alle echten SSH-Server funktionieren. Da sollte normalerweise ein Schlüssel-Austausch-Mechanismus implementiert sein. Und das ist also auch ein sichere Weg, Kippo zu identifizieren. Und nach all diesen Fixes waren wir auch daran interessiert, ob wir immer noch in der Lage sein würden, Kippo zu identifizieren. Und was wir gefunden haben, ist zum einen, wenn man den Befehl U-Name ausführt, dann kommt immer die gleiche Antwort zurück. Der einzige Unterschied ist, er ändert den Namen der Maschine und da kann man da sowas in der Konfiguration einstellen. Es ist eigentlich ziemlich cool, denn es verrät einem die Compile-Zeit des Kernels und es ist ein ziemlich eindeutiger String, an dem man eine Maschine identifizieren kann. Das heißt, wenn man diesen String in Google eingibt, dann findet man Seiten von vielen Leuten, die entweder Admin sind oder sich zu ihrem Netzwerk verbinden sollten und sagen, hey, das ist eine SSH-Maschine in meinem Netzwerk, aber die verhält sich ganz komisch. Ich weiß nicht genau, was das für eine Maschine ist. Hier ist der U-Name, vielleicht kann einer von euch mir sagen, was hier verkehrt ist. Und das ist schon eigentlich ein bisschen witzig. Ein möglicher Fix dafür ist, entweder sollte man den tatsächlichen Timestamp des Kernels der Maschine zurückliefern, auf der Kippo läuft, oder einfach einen Zufallswert. Was können wir daraus lernen? Der Honeypot gibt einem jetzt nicht nur einen Indikator für den Angreifer, sondern er sammelt auch Informationen über ihn und das ist ziemlich cool, denn je mehr Informationen wir von einem Angreifer bekommen, umso sicherer können wir sagen, das ist der Werkzeugkasten, den der Angreifer jetzt benutzt und wir können Abwehrmechanismen dagegen erstellen. Also wir können zum Beispiel, wenn er auf die SSH-Maschine, zum Beispiel, wenn er ein Sample runterlädt auf die Kippo-Maschine, dann können wir das gezielt blockieren. Und wenn wir aus der Perspektive das alles ans Angreifers schauen, wir laufen jetzt nicht nur Gefahr, erkannt zu werden oder überhaupt gefangen zu werden, sondern das Netzwerk wird es gegen uns benutzt. Das nächste Projekt ist Dionea. Das ist ein ziemlich beeindruckendes Projekt. Also ja, die Absicht von Dionea ist es, Malware einzufangen, die Dienste außennetzt, insbesondere die Dienste, die übers Netzwerk angeboten werden und das Ziel ist es, eine Kopie dieser Malware zu erhalten. Also ja, das Ziel von diesem Metrie von Honeypots ist, dass man die Malware erhält, die der Angreifer verwendet. Und das ist eigentlich, am Ende ist das ein wichtiger Schritt, um solche Angriffe ins Leere laufen zu lassen. Also früher konnte man Dionea sehr leicht finden, wenn man das nämlich mit M-Map gescannt hat. Dann hat man nämlich ein SQL Server gefunden und da war der Name drin, Dionea SQL Server. Also ja, wieder hat ein Problem der Konfiguration dieses Dienstes. Es wurde jetzt natürlich gefixt, das passiert heute nicht mehr, aber es gibt noch etwas sehr Interessantes, das wir gefunden haben bei unseren Untersuchungen. Wir haben mit dem Markus gesprochen, der Mentena dieses Projekts, die machen viele tolle Dinge. Was Markus gesagt habe ist, wenn ich mit deinem Hier arbeite, dann gibt es ein Haufen Zeug, dass sich nicht so verhält wie normale Dinge, die ich erwarten würde, dass sich so verhalten, hinter dem Honeypot. Also ja, so kann man halt herausfinden, dass es ein Honeypot ist. Am Ende hier sagt er uns, ja, ich meine, mir ist schon klar, was du meinst, aber das ist halt nur die Spitze des Eisbergs und da gibt es einfach sehr wenig, was ich tun kann. Ja, also, ihr müsst halt wissen, alle von euch, die ein Honeypot betreiben, ihr werdet nie einen vorgeschrittenen Angreifer täuschen können. Also, man wird immer das detektieren können, dass es ein Honeypot ist. Ja, so mein Beispiel zu nennen, wenn man ein HTTPS-Server laufen lässt auf Diania, dann ist das ZVK zigniert von Diania, also von der URL, von Diania. Ja, also es ist nicht sehr gute Täuschung. Dann, als nächstes, wenn man den FTP-Server braucht, dann kann man mit jedem benutzen und Passwort sich einloggen. Ja, ich habe das noch nie sonst gesehen, dass man für einen Benutzer mehrere Passwörter verwenden kann. Und ja, weiter, genau, der FTP-Server unterstützt Dili nicht, dieses Kommando. Was können Diania lernen? Ja, so, die versuchen, ihre Services so zu bauen, dass sie angreifbar sind für bekannte Exploits, also wie z.B. Blaster bei MSSQL Server und so weiter. Und sobald Diania feststellt, dass so ein Angriff gefahren wird, dann wird Diania zeichnet dann auch, was für Code ausgeführt wird. Also jetzt auf der Sicht des Angreifers, wie gehe ich damit um? Also, wenn ich also eine Maschine im Netzwerk anschaue, wenn ich jetzt z.B. diesen x86-Config-Exploit verwende, das heißt jetzt für mich, wenn ich das ausführe, kann es sein, dass ich meine Malware verliere, weil die da aufgezeichnet wird. Das nächste Projekt ist Glastop. Das ist eine Web-Anwendung. Also, Glastop sieht aus wie eine Web-Anwendung und untersucht Web-Angriffe. Also, wenn man Glastop installiert, dann ist das die default Website. Man kann sehr viel Zeug einstellen bei Glastop und man kann praktisch jedes Fallsystem oder Web-Applikationen da reinladen. Aber in der Standard-Einstellung sieht es eine sehr, sehr komische Page. Also, viele davon ändern das ja jetzt auch. Wenn man da jetzt hier unten die Website anschaut, ein großer Teil des Textes ist zufällig, aber diese Signatur hier unten bleibt immer gleich. Also, dieser Futter der Website, dieser Kommentar hier, das ist ein sehr guter Eintrag. Das wird nicht verändert. Also, ich habe einfach mal diesen String genommen und danach ge-googled. Und ja, da habe ich ein paar sehr interessante Webseite gefunden, aber eine der Top 500 Webseiten hatte das in einer Subdomain. Also, wenn jetzt zu einer Subdomain von sehr berühmter Website.com geht, dann findet ihr das da unten im Futter. Also, offensichtlich verwenden die da Honipods, aber nicht auf eine schlaue Art. Also, denen ist offensichtlich nicht bewusst, dass wenn die das so einsetzen, dann ist das eine sehr schlechte Täuschung. Ja, und was macht jetzt GlassTof? Wenn man damit irgendwie interagiert, wird das aufgezeichnet. Und wenn man da irgendwas auf dem Fallsystem macht, also es gibt da zum Beispiel so ein directory traversal exploit. Also, ja, wenn man jetzt da zum Beispiel die Adresse slash punk punk slash punk punk slash etc shadow macht, dann gibt es ein Fall zurück. Also, das kann man auch einstellen. Und ja, das hier ist zum Beispiel das Default-File und das ist ein guter Weg, GlassTof zu Fingerprinten. Ja, das heißt, leider gibt es hier die Möglichkeit, dass man das Fingerprinten kann und der Benutzer kann da nichts konfigurieren. Also, wenn man jetzt da etc shadow anschaut, dann sollte man auch, ja, wenn man auf das zugreifen kann, sollte man auch auf slash punk zugreifen können. Und wenn man jetzt aber auf slash punk zugreifen kann, also ja, das ist ein Fall, sehr schwer zu simulieren, die die Honipods konfigurieren, heißt das, naja, erstens mal muss man da der Inhalt des Fallsystems füllen, also damit da eine Antwort kommt und dann, ja, halt sobald man dann weiß, naja, wenn jetzt da tatsächlich irgendwie die richtige Antwort gibt, dann kann man da natürlich GlassTof finden weil das ja auf dieser Maschine läuft, oder? Also ja, das heißt, wenn ich mir jetzt das da anschaue und auf GlassTofs Speicher zugreifen kann, kann ich halt daraus finden, ob das korreliert ist mit was auf der Webseite läuft. Also ich zum Beispiel nämlich dann mehr hdb requests mache und so, also egal wie das da eingestellt ist, wenn so lange das da irgendwie simuliert ist, kann ich rausfinden, dass das nicht echt ist, wenn da in slash punk keine echten Daten drin sind. Ja, ich würde das folgendermaßen reparieren. Also man gibt einfach permission denied zurück. Aber ja, das macht halt nicht so viel Sinn in einer Linux-Umgebung, das ist nicht wirklich ein guter Fix. Was lernen für GlassTofs Arbeit? Also das ist das erste Framework, wo man das Filesystem anschauen kann. Es geht nicht nur darum, auf Netzwerkdiensten zu täuschen, sondern auch auf dem Filesystem der Maschine. Also bei dem Angreifer geht es darum, dass man zugeordnet werden kann. Also wenn man jetzt da Zeug ins Filesystem hintut oder sich da umschaut, dann vereint man natürlich etwas über sich, je nachdem, was man da anschaut. Ein weiteres ist KF Sensor, das ist recht interessant. Denn das ist ein Honeypot für Windows. Es ist nicht Open Source, also es kostet Geld. Das gibt's schon seit, glaube ich, über zehn Jahren. Also wenn man auf die Webseite geht, dann sieht sie aus wie die AOL-Webseite im Jahr 2000. Aber es scheint eine Reihe von Leuten zu geben, die das auch wirklich kaufen und benutzen. Und es funktioniert wohl auch hartwegs gut. Man bekommt hier diesen sehr großen, dieses sehr große grafische Interface, was man benutzen kann. Und man kann fast jeden einzelnen Service, den eine Windows-Maschine bietet, konfigurieren. Was ein bisschen komisch ist, also wenn man die Standardkonfiguration benutzt, dann bekommt man Warnungen über Broadcast Request. Und das ist nicht wirklich gut, denn es bedeutet ja, dass man ständig irgendwelche Warnungen bekommt, sobald man diese Maschine ins Netzwerk hängt. Und die Standardkonfiguration für diese Software macht auch einen Sirenen-Sound, sobald eine Warnung auftritt. Das heißt, wann immer wir das damit gearbeitet haben und damit Forschung betrieben haben, dann haben wir das, die Maschine ins Netzwerk gehängt und es gab sofort die Sirenen-Sound. Das war grauenvoll. Ja, also es gab uns viele humorous Momente. Es gab ein paar interessante Momente in unsere Forschungsarbeit gebracht. Also wie identifizieren wir das jetzt? Wenn wir den HTTP-Server aufsetzen, dann bekommen wir eine Standard-Webseite, die man einfach den Inhalt dieser Standard-Webseite nehmen, man kann ihn googeln und findet dann eine ganze Reihe von verschiedenen KF-Sensor-Installationen, denn ja, niemand macht sich die Mühe, diese Standard-Webseite zu ändern. Wenn man HTTPS anschaltet, dann geht der Port auf, aber der Service ist nicht implementiert. Und das haben wir in den vorigen Beispielen auch schon ein paar Mal gesehen. Es gibt auch eine konfigurierbare Anzahl von Verbindungen, bevor jemand blockiert wird. Und in dem Sinne ist es auch verletzlich genauso wie BearTrap und andere. Das heißt, es schützt einen nicht davor, dass der Angreifer eine Adresse spuft. Und auf diese Art und Weise kann man einfach Adressen aus dem Netzwerk schmeißen. Also was haben wir von KF-Sensor gelernt? Auch außerhalb des Open-Source-Ökosystems existieren genau die gleichen Probleme. Es ist nicht irgendwie etwas, was die Projekte haben, weil sie Open-Source sind, aber es gibt eigentlich solche oder ähnliche Probleme. So, nachdem wir jetzt diese ganzen verschiedenen Arten des Deployments uns angeschaut haben und wie man Honey Pots erkennen kann, haben wir einfach mal gesagt, schauen wir mal auf der ganzen Welt herum, wo Honey Pots alle stehen. Das könnte ganz interessant werden. Und was wir dann gemacht haben, wir haben den CMAP-Projekt benutzt. Das ist also ein Weg, wie man einen großen Adressbereich und natürliche Scans nach HTTPS-Zertifikatsinformationen gemacht. Das haben wir einen Tag lang gemacht. Das war am 14. Juli 2015. Und wir haben mal so geschaut, wer hat dieses Dioneer-Zertifikat, was dieses Dioneer.carnivor.irgendwas ist. Und jede Webseite, die dieses Zertifikat hat, ist per Definition eben ein Dioneer-Honeypot. Und das hier ist das Ergebnis. Es ist leider, man kann es nicht so gut erkennen, aber es ist sehr offensichtlich, dass die meisten Honey Pots an diesem Tag, die wir gefunden haben, mit Dioneer in Taiwan stehen, zweiter Platz die Vereinigten Staaten und die ganzen anderen Länder liegen irgendwo weit drunter, sind viel weniger signifikant. Das hier ist die vollständige Lüste der Länder mit Anzahl der Deployments. Und so wie wir herausgefunden haben, welches Land zu welcher IP-Adresse gehört, ist einfach dieses ganz normale Geo-IP-Location. Also wir haben diese Dinger validiert und haben ein paar interessante Sachen hier rausgefunden. Also beispielsweise können wir sehen, dass, also wir hatten keine Honey Pots in Tanzania beispielsweise erwartet. Wir haben zum Beispiel mehr Honey Pots als Russland, also mein eigenes Heimatland Israel, hätte man meinen sollen, taucht hier auf der Liste auf, tut es aber nicht. Also es sind, dann wiederum ist Iran drauf, ganz interessant. Wir kommen darauf gleich noch zurück. Dann wollten wir herausfinden, welche Organisationen diese Honey Pots installiert haben. Die größte davon war ein teilvanesischer Internet Provider, der einen riesen Anzahl von Honey Pots hatte und anscheinend der eine Kerl, der dafür zuständig ist, der liebt Dioneer, sagt wahrscheinlich, alle der Traffic, der verdächtig vorkommt, wird zu einer Dianiermaschine umgeleitet. Es gibt wohl noch einen zweiten Kerl, der genauso denkt in den Vereinigten Staaten. Ich würde mich gerne mal mit diesen beiden Kerln unterhalten. Das wird bestimmt interessant. Ein weiterer an einer Universität in Taiwan, einer der größten Cloud Provider, hatte 80 Honey Pots in seinem Netzwerk. Aber was interessant ist, sie veröffentlichen in welchen IP-Bereichen die Cloud ist. Und dann gibt es noch ein anderer IP-Bereich, der zu der Organisation gehört, aber nicht zu der Cloud selber. Und was Interessante ist, dass die Honey Pots nicht in dem Bereich der Cloud waren. Also entweder verstecken sie diese Informationen, was die echte Bereich der Cloud ist, oder aber sie haben diese Honey Pots nur in ihrem Firmennetzwerk. Ein paar interessante Organisationen, die wir noch gefunden haben. Wir haben es ein bisschen anonymisiert. Es war so ein Verteidigungsministerium eines europäischen Landes, eine sehr große Wirtschaftsorganisation, eine Finanzdienstleister in Südafrika und eine Behörde in den USA. Weitere Organisationen, ein taiwanesischer Computerhersteller, ein japanisches Projekt, wo es um Infrastruktur arbeiten geht, aus Cambodia eine Regierungsorganisation und ein Research-Blog, der sich mit Malware befasst. Das war ganz interessant. Wir sind auf diesen Blog draufgegangen und der Name ist MX0.Name des Blogs ist ein Dynier-Rechner. Das heißt also, der MX0-Record zeigt auf dem Dynier-Rechner und der Blogs selber. Auf diesem Blog spricht der Besitzer, wie er Malware Weispiele bekommen hat, indem er seine Honey Pots aufgestellt hat. Also es ist ein bisschen witzig. Ich wollte mal für eine Weile darüber nachgedacht, etwas zu machen, dann drüber zu blocken, aber ich wollte nicht so richtig in diesen Black Hat Bereich reingehen. Und die einzige Organisation im Iran ist die iranische Ölgesellschaft, die National Iranian Oil Company, hat Dynier eingesetzt. Eine der Unterdomains auf oil.ir, also der, wer auch immer diese Firma betreibt, der kennt sich wohl richtig gut mit Cyber Security aus und hat eben diesen Honey Pot auf einer seiner Subdomains eingerichtet. Also ich sah, dass diese oil, diese iranische Ölseite, diesen Honey Pot hat, wollte ich mir auch HTTPS und HTTPS anschauen und wollte mir anschauen, was da so alles passiert und das ist das, was ich zurückbekommen habe. Das ist also die Default-Website von Glastop und dann sagte ich, Moment, wir haben Dynier auf HTTPS, das hat Glastop auf HTTPS, vielleicht gibt es da so eine Art, eine Rechne, wo viele Honey Pots gemeinsam installiert sind und das hat mich dann auf die Spur des Modern Honey Network gebracht. Das ist also ein Projekt, was im Grunde mehrere dieser Honey Pots und Scripts zusammenpackt zu einer großen Maschine, die man einfach installieren kann und man klickt dann auf die Ploy Honey Pots und man bekommt dann jede Menge Honey Pots in ihrer Standardkonfiguration ausgeliefert. Also, welche Lektionen haben wir gelernt? Diese Probleme sind sehr leicht zu finden und ein Low Interaction Honey Pot kann solche Probleme auch nie wirklich vermeiden, denn das steckt denen im Design. Wenn ein Angreifer sich bewusst ist, dass er getäuscht werden soll, dann findet er diese Honey Pots auch und kann sie erkennen und kann sie gegen den Verteidiger einsetzen. Was können wir also tun, um das Ganze besser zu machen? Was wäre ein guter Weg, diese Täuschung durchzuführen? Gehen wir mal durch diese einzelnen Schichten, die wir getan haben und schauen uns mal an, was der Grund für die Probleme war. Also, als Allererstes müssen wir die Services anbieten. Also, dann müssen wir die Services vollständig implementieren. Dann müssen wir die Services, die wir anbieten, halbwegs sinnvoll für die emulierte Maschine erscheinen lassen. Dann müssen wir diese Services auch angreifbar machen für eine Reihe von bekannten Exploits, damit der Angreifer auch eben versucht ist, eine Malgäu zu installieren. Und was wir dann auch machen wollen, ist, wir wollen auch diese Services für bekannte Exploits angreifbar machen. Das Problem damit ist allerdings, wenn du nicht weißt, wie ein Zero der Angriffe funktioniert, wie soll man dann simulieren, wie eine exploitete Maschine sich verhalten würde. Und eine, was wir in der Zukunft gerne hätten, ist, wenn diese Maschine eine echte Maschine wäre. Aber das stellt immer die Frage, wie können wir dann alles beobachten, wie können wir alles locken, wie können wir wissen, dass der Angreifer da drin ist. Und das stellt, wie das aussehen könnte. Also diese ganzen Sachen, diese ganzen Schichten, die wir implementieren müssen. Wenn wir den theoretisch besten Honeypot, die beste Täuschung implementieren wollten. Wir werden unseren Code Release veröffentlichen. Wir müssen da noch einige Problemchen drin beseitigen. Und wir wollen vor allem auch Danke sagen den ganzen verschiedenen Leuten, die es in diesem Gebiet beforst haben. Man bekommt sehr viel Informationen, indem man solche Dienste laufen lässt. Und dieser Talk heute sollte euch einfach mal so ein bisschen nahebringen, wie das helfen kann gegen solche Low-Level-Attacken. Aber die High-Level-Angriffe, die werden sich durch so was nicht täuschen lassen, sondern man kann das eben auch gegen euch anwenden. Und das wollten wir eigentlich darüber bringen. Wir haben uns hier geholfen bei unserer Forschung. Und wir möchten Ihnen sehr, sehr danken. Ich werde jetzt die Namen nicht alle vorlesen. Die Liste ist dafür einfach zu lang. Und das war's. Hallo, danke für den Talk. Ganz, ganz einfache Idee ist mir eingefallen. Ich dachte, ich könnte einige dieser Wähler kopieren aus den Honipods in meine echten Systeme kopieren. Und dann diese Mischung würde ich dem Attacker präsentieren. Man sollte vielleicht anmerken, manche dieser Honipod-Projekte hatten eigentlich eine ziemlich ordentliche Täuschtaktik, aber wenn man einfach die Standardkonfiguration benutzt und nicht weiter drüber nachdenkt und einfach der Meinung ist, ich bin sicher, dann ist das keine gute Idee. Also man muss wirklich drüber nachdenken über die Konsequenzen, wenn man einen Honipod sich einrichtet. Das ist mir eine Bemerkung, wenn man die Standard-Einstellung verwendet, ist es eigentlich nicht wirklich ein Problem der Software. Also wenn du zu faul bist, einfach den Banner-Text zu ändern und das Dot-Tie-System zu ändern und einfach die Standard-Einstellung überall verwendet, dann können wir die Leute anhand von dem Intro identifizieren. Und wenn man aber nicht diese Default-Einstellung anpasst, dann wird der Honipod immidualisiert und dann funktioniert's. Ja, das ist natürlich wahr für alle Projekte, die wir uns bei unserer Forschung angeschaut haben. Also wir haben für alle einen Weg gefunden, sie zu erkennen, ganz egal welche Konfiguration wir benutzt haben. Der Grund, warum wir diese Standard-Einstellungen erwähnt haben, wir haben halt einfach so viele verschiedene Leute gesehen, die einfach die Standardkonfiguration benutzt haben. Das heißt, man will natürlich irgendwo, dass diese Standard-Einstellungen nicht ganz so leicht erkennbar sind. Aber natürlich sollte man, man sollte es auf jeden Fall ändern und soll das Individualisieren, das ist auf jeden Fall wichtig. Es ist nicht eine gute Idee einfach, einen aktiven VSFTPD zu verwenden und dann ein Modul zu schreiben und das falseste Inhalt zu emulieren. Ja, es ist irgendwo so ein bisschen ein Kompromiss, wenn man also Emulationen macht, dann hat man natürlich selber die Gefahr identifiziert zu werden. Definitionsgemäß, wenn man etwas emuliert, dann funktionieren zum Beispiel solche Zero-Day-Explods nicht. Also man kann das immer identifizieren. Wenn man die echte Maschine allerdings hinstellt, dann ist das Problem, wie kann man das Ganze rauschen und ist das normale Zeug, was im Netzwerk passiert, dadurch unterscheiden, was ein Angreifer machen würde. Und wenn man sieht, wie der Angreifer mit dem System interagiert, müsste man ja jedes eines alles mitschneiden. Also zum Beispiel für einen SSH Schlüsselaustausch, wenn wir nicht mehr in der Lage rausfinden, was, ob das, was er gemacht hat, jetzt irgendwie bösartig war. Denn man weiß jetzt nicht, war das jetzt in der Aktion eines Angreifers oder war es zum Beispiel irgendein Programm, das einfach nur ein Netzwerk abscannt? Was ist, wenn ich das Ganze umdrehe? Also was ist, wenn ich meine echten Dienste so hinbiege, dass sie aussehen wie Honipods? Ja, das ist eine coole Idee. Wir haben ein Freund von uns, der hat ein Startup-Unternehmen, der macht genau das. Also er lässt echte Maschinen wie Honipods aussehen und versucht auf diese Art, Angreifer davon abzubringen, sie anzugreifen. Microphone 1, please. Ich habe nicht ganz verstanden, wie ich einen Attacker dazu bringen, meinen Honipod anzugreifen und nicht meine echte Webseite. Was Honipods versuchen zu lösen, wenn ein Angreifer eine Maschine angreift, man kann ihn erkennen und man kann ihn stückweit kontrollieren. Aber wir reden hier über ein großes Problem, eine Ebene drunter. Also wie bekommen wir den Angreifer dazu, sich dem Honipod zu widmen? Man muss es also schon so aussehen lassen, als ob da was Interessantes zu holen wäre. Ein Beispiel, was wir gegeben haben, ist dieses Blog, dieses Mailware-Forschers. Er hat da ein interessantes Subdomain unter seine Hauptdomain eingerichtet und hat das so aussehen lassen, als ob es ein Mail-Server wäre. Aber das ist eigentlich ein ganz anderes Problem, was man auch lösen muss und nicht nur eben die Täuschung selber. Habt ihr einen Honipod kaputt gemacht, die neue Forschungsarbeiten? Ja, wir haben jetzt nicht wirklich gesucht nach irgendwelchen Schwachstellen, die uns das ausführen von Code ermöglicht hätten. Denn man bekommt da nicht wirklich irgendwelchen Gegenwert raus. Das ist mehr so ein Problem, also wir haben es einfach nicht versucht. Von daher wissen wir nicht, ob das möglich ist. Wie kann man denn rausfinden, ob es ein Angreif ist oder nicht? Also, was ich mir da angeschaut habe, war, man benutzt tatsächliches SSH, aber nicht so viel, wie man das ausführen kann. Also, wenn man das ausführen kann, dann ist es so, tatsächliches SSH, aber man nimmt dann ein PAM-Modul, dass so die Top 10.000 Passwort anschaut, die Leute Brut forschen. Also, da kann man dann nicht die Merlwerk klauen oder so, aber wenn man das im Netzwerk hat, dann sieht man, wenn sich da jemand auf einem SSH-Server einloggen will, dann weiß man, dass es ein schlechter Target, weil da jemand in deinem Netzwerk ist. Also, so weiß man, dass es ein Angriff ist. Also, ja, es ist dann ja offensichtlich nicht jemand, der einfach sein Passwort vertippt hat. Ja, das ist wahr. Das ist einer der grundlegenden Methoden. Ja, coole Sache. Anymore questions? Yes, the internet has some more questions. Just one short one. So, would it be a good configuration to take one more... Es ist eine gute Konfiguration, wenn man ein Default-Honeypot nimmt und eine handvoll angepasste Honeypots, um damit der Angreifer das Gefühl hat, dass die Individualisierten echter sind? Ja, die Sache mit der Täuschung ist immer, es gibt so viele verschiedene Wege, das zu tun und verschiedene Wege darüber nachzudenken, welche Wege der Angreifer benutzt. Also, es gibt viele Sachen, die man machen kann. Eine der grundlegenden Sachen, die man aber berücksichtigen muss, wenn man über Täuschung redet und es gibt verschiedene Ebenen der Täuschung. Wenn man einfach nur mit diesen Script-Kitties ist zu tun hat, dann muss man da nicht diese High-Transaction-Honeypots installieren und ähnliches, sondern man kann dann einfach ganz normale Honeypots, über die wir geredet haben, einstellen, vielleicht nicht gerade mit der Standardkonfiguration, denn die ist ja ganz offensichtlich kaputt. Do you have another question from the internet? No. Any other questions from the room? No, I close the talk now. Es gibt keine weiteren Fragen mehr aus dem Publikum und ...