 Sachsen. In Land Sachsen gibt es einen riesigen Glasfasering zwischen den großen drei Städten Dresden, Leipzig und Chemnitz. Der Ring ist quasi der Kern des extremen Verwaltungsnetzes. Der wird dann noch erweitert durch die Städte Kamens und Bautzen. Das ist der sogenannte Ostring, ist auch ein kleiner Glasfasering. Und auf der anderen Seite durch ein Glasfasering durch Blauen, Zwickau und Chemnitz. Und an diese Glasfaserstruktur sind alle möglichen Ämterbehörden, Ressorts und alles, was zur sächsischen Landesverwaltung gehört, angeschlossen. Das ist ein gigantisches Netzwerk. Das sind Rechne im Bereich von 10.000, also ich glaube 30.000 noch etwas ist da die aktuelle richtige Größenordnung. Und die haben natürlich mit einer ganzen Reihe von Sicherheitsproblemen zu kämpfen. Was genau das Thema des Forschungsprojektes ist. Die IT-Sicherheit in so einer Netz wird durch verschiedene Sachen beeinflusst. Also typische Bedrohungen dafür sind natürlich Schadsoftware, Mailware, das klassisch wirren, Trojaner, alles, was man sich irgendwie im Internet oder durch E-Mail oder dergleichen einfangen kann. Die andere Variante ist natürlich, dass irgendjemand von außen in dieses Netz eindringt, indem er irgendein zentralen Server ist. Das ist im einfachsten Fall im adresen.de, was ein Web-Server ist, der natürlich in diesem Netz steht und der möglicherweise angegriffen werden kann. Was dann dazu führt, dass sich irgendwann ein Angreifer im Netz befindet. Und das nächste große Thema ist der sogenannte Insider Thread. Damit bezeichnet man Mitarbeiter, die irgendwie gegen ihre Weisungen handeln und auf Ressourcen zu greifen, auf die sie eigentlich keinen Zugriff haben. Zum Beispiel irgendein Mitarbeiter, der dem gedroht wird, rauszuschmeißen, dass er rausfliegt. Und der zahlt zur Rache, dann versucht er irgendwas kaputt zu machen. Und auch das ist eben was, was man versuchen muss, dem man irgendwie begegnen muss. Um solche Sachen irgendwie bekämpfen zu können, gibt es wieder eine Reihe von Lösungen. Ganz typisch natürlich Antivierend Software, das man auf jedem Rechner oder an einer zentralen Stelle einen Virenscanner installiert. Dort alle möglichen Binarys, die durchs Netz gehen, scannt und eben die Schlimmen dann rausschmeißt. Es gibt die Variante Firewalls einzusetzen, was natürlich auch schon in großem Maß gemacht wird. Firewalls lesen den Datenverkehr mit, also zumindest welches Paket, wohin geschickt werden soll. Und anhand von einem fixen Regelsatz entscheiden sie dann, ob ein Paket entsprechend versendet werden darf oder nicht. Etwas fortgeschrittene Lösungen sind dann sogenannte Intrusion Detection Systeme und Intrusion Prevention Systeme. Die lesen ebenfalls ähnlich wie Firewalls den Datenverkehr mit, allerdings in der Regel auch den Datenteil. Und entscheiden dann anhand der Daten, die wirklich versendet werden, ob möglicherweise hier ein Angriff stattfindet und versuchen das entweder zu blockieren oder aber zumindest die Administratoren, die für dieses Netz divers zuständig sind, darauf hinzuweisen, so dass man dann da irgendwas machen kann. Ein weiterer Ansatz, der schon über 20 Jahre alt ist, aber der jetzt erst in den letzten paar Jahren so ein bisschen mehr Aufmerksamkeit bekommen hat, sind sogenannte Honeypots. Das war lange Zeit einfach ein Forschungsthema. Inzwischen ist sowohl die Industrie als auch Behörden auf den Zug ein bisschen aufgesprungen und hat da jetzt Interesse für entwickelt und das hat dann auch zu diesem Forschungsprojekt geführt. Deswegen werde ich jetzt erst mal erklären, was Honeypots eigentlich sind, was man damit machen kann und dann wieder zurückkommen zur Frage, was hat das eigentlich mit dem Verwaltungsnetz zu tun. Honeypots, den Begriff selbst hat Lens Spitzner mal definiert, das ist so die Definition, die man überall in der Regel liest, die im Wesentlichen sagt, dass ein Honeypot eine genauestens überwachte Netzwerkressource ist, also im einfachsten Fall einfach ein Rechner, den ich in dieses Netz stelle und die aber halt perfekt überwacht wird, also wo ich weiß, was drauf stattfindet, wo ich alle Systemaufrufe, jegliche Netzwerkverkehr und all das mitlesen kann und die nach außen hin so aussehen soll, dass sie für einen Angreifer möglichst ein interessantes Ziel darstellt. Also zum Beispiel, indem ich darauf Dienste laufen lasse, die bekannterweise Sicherheitslücken haben und dann eben herausfinde, wer greift das Ding an, wie greift er es an und vielleicht auch warum greift er es an. Und dann ist es natürlich das Ziel, dass das entsprechend dann auch attackiert und auch kompromittiert wird, um einfach was darüber lernen zu können, was die Angreifer machen wollen. Das Ziel von solchen Honeypots ist im Wesentlichen Daten natürlich zu gewinnen, wer greift es an und warum tut er es, aber auch um Angreifer abzudenken. Also im Idealfall habe ich in so einem Netzen den Rechner stehen, der so interessant aussieht und so viel interessanter als alle anderen Geräte, die da sind, dass er zuallererst dieses Gerät angreift und alle anderen dann in Folge erstmal in Ruhe lässt, man dadurch natürlich einen Zeitvorsprung hat und dann rechtzeitig reagieren kann, bevor er wirklich Schaden irgendwie anrichten kann. Es ist möglich mit Honeypots sogenannte Zero-Day-Angriffe zu erkennen. Damit bezeichnet man im Prinzip Angriffe oder einen Angriff auf irgendeine Lücke, der zum Zeitpunkt des Angriffs noch nicht bekannt war. Also auf Heise und so liest man da relativ oft davon, dass ein Flasch und Co. sowas auftritt. Und ein Honeypot hat zumindest eine theoretische Möglichkeit, so einen Angriff trotzdem zu erkennen, weil ein Honeypot immer nach der Prämisse arbeitet, dass ein Gerät, was ich einfach ins Netzwerk stelle und was nichts tut und von sich aus kein Datenverkehr verursacht, auch niemals Datenverkehr bekommen sollte. Wenn dort jemand irgendetwas hinsendet, dann löst sofort eine Warnung aus und muss sofort geschaut werden, warum sind jetzt hier Daten angekommen, obwohl dieses Gerät eigentlich nichts tun sollte. Also per Definition ist alles, was da ankommt, ein Alarm und erfordert, dass irgendjemand sich das genauer anschaut, was da jetzt passiert ist. Und zuletzt ist es theoretisch, dass es dann auch mehr Forschungsfeld möglich mit Honeypots automatisch auf dem Angriff zu reagieren, indem man so einen Angriff registriert und anhand dieses Angriff sofort eine Signatur generieren kann, die ein Intrusion Detection System, was ich vorher schon erwähnt habe, um in Zukunft genau diese Art von Angriff wieder zu verhindern. Ein kurzes Beispiel dazu, nehmen wir an, das ist ein ganz normales Netzwerk. Also da gibt es ein paar Laptops, ein paar Desktops, eine Verbindungseinrichtung, das kann jetzt ein WLAN switch oder sonst was sein und es gibt natürlich einen zentralen Internetzugang auf der anderen Seite. Und in dieses Netzwerk stellen wir jetzt ein Honeypot rein. Das sieht dann einfach so aus, dass dort zusätzlich noch ein Gerät mit auftaucht. Was dieser Honeypot ist, ist im einfachsten Fall ein Rechner, der einfach wartet, was passiert und wo ich weiß, was er macht und was auf dem alles passiert und das alles mit Aufzeichnen. Und jetzt passiert das, was so häufig passiert. Irgendwie schafft es halt jemand, seinen Laptop zu infizieren, indem er irgendwas mit Netz macht, zum Beispiel eine E-Mail öffnet mit einem verseuchten Anhang. Der Rechner ist in dem Moment infiziert. Und zu irgendeinem späteren Zeitpunkt wird die Mailwerfer versuchen sich irgendwie weiter auszubreiten im Netzwerk und wird entweder anfangen zu scannen oder wird sofort anfangen, andere Hosts anzugreifen. Wahlweise, wahllos gibt es ja verschiedene Möglichkeiten, wie Sie davorgehen. Und natürlich gibt es dann einfach die gewisse Chance, dass dieser Angriff auch bei dem Honeypot ankommt und dass ich das in diesem Moment registriere und dann entsprechend darauf reagieren kann. Das ist die Grundidee. Es gibt ein prominentes Beispiel, wo das zurzeit wirklich schon eingesetzt wird und das ist in der Deutschen Telekom. Die hat ein System aufgesetzt, das nennt sich Sicherheiztacho, das ist eine Website, sicherheiztacho.eu. Da kann man jederzeit an sich anschauen und weltweit haben die kleine Honeypots stehen. Da kann man quasi Sensoren angucken, was an ihnen für einen Datenverkehr ankommt. Und dann sieht man hier auf so einer schönen animierten Karte immer so Linien, die hier von links nach rechts gehen und wo man dann genau weiß, ok, jetzt hat eben China wieder die USA angegriffen. Das wird hier drüben dann alles in tollen Statistiken dann verwirkt. Und das ist so das prominente Beispiel, wo man sagen kann, da werden Honeypots auch wirklich mal in der Praxis eingesetzt. Es ist aber eben mehr so ein Demo-Ding. Und in unserem Fall geht es quasi mehr darum, nicht weltweit jetzt zu gucken, was passiert da so, sondern konkret einen Netzwerk zu nehmen und vor allem zu schauen, was im Inneren des Netzwerks passiert und nicht wie es von außen angegriffen wird. Denn dass man von außen permanent angegriffen wird, das wissen die Leute und dafür braucht man jetzt nicht zwingend noch mehr Geräte, die das irgendwie herausfinden. Es gibt noch ein paar Herausforderungen, die der Einsatz von Honeypots mit sich bringt. Das ist selbstverständlich, dass wenn ich ein Gerät ins Netz stelle, das angegriffen werden soll, dass es natürlich auch eine gewisse Chance gibt, dass es am Ende kompromittiert ist und dass das Gerät selber Quelle neuen übelt wird und anfängt, andere Geräte anzugreifen. Was dann einfach so aussehe, dass jetzt der Honeypot selber infiziert ist und einfach alle anderen Geräte auch angreift. Das ist natürlich nicht Sinn der Sache. Deswegen ist es sehr wichtig, dass man sogenannte Containment-Maßnahmen ergreift, also Maßnahmen, die verhindern, dass genauso was passiert. Es gibt viele Varianten von, zum Beispiel eine transparente Firewall, die dazwischen steht und versucht den Traffic, den der Honeypot selbst wieder verursacht zu reduzieren oder indem man das Ding sofort abschaltet, sobald irgendwas Verdächtiges passiert und so weiter. Es gibt eine ganze Reihe von Ansätzen, auf die ich jetzt aber nicht alle einzelne eingehen möchte. Das Nächste ist, dass ein Honeypot, so wie ich ihn jetzt erklärt habe, allein nicht sehr viel Sicherheitsgewinn bringt. Das heißt, wenn ich jetzt meinen Netzwerk nehme und da einfach nur ein Honeypot reinstelle und sage, jetzt ist es sicher, dann funktioniert es nicht. Es ist eine Ergänzungslösung. Es ist eine Ergänzungslösung, die besonders in Zusammenspiel mit anderen Technologien, also vor allem den, den ich gerade schon alle genannt habe, gut funktioniert und erst dann wirklich gut funktioniert. Das heißt, ich habe im Mediarfall überall zum Beispiel den Virenschutz drauf, auch wenn das jetzt wieder ein umstrittenes Thema ist, wie sinnvoll heutzutage noch ein Virenschutz ist. Das wäre wohl irgendwie an einer oder mehreren Stellen, um diesen eingehenden Verkehr schon mal vorfiltern zu können. Und ich habe im Mediarfall ein Intrusion Detection System, was den kompletten Netzwerkverkehr mitliest und auch da schon aktiv wird. Und dann kann ich anfangen, entsprechend den Honeypot da mit reinzustellen und vor allem im Zusammenspiel mit dem Intrusion Detection System ist es dann wirklich ein nützliches Gerät. Zurück zum sächsischen Verwaltungsnetz. Der sächsische Beauftragte für Informationssicherheit hat einen Interesse daran ausgedrückt, Honeypots im Verwaltungsnetz zu haben und hat schon längere Zeit versucht, über Firmen und so was da irgendeine Lösung fürzufinden, hat da aber Dinge irgendwas gefunden und ist dann irgendwann auf die TU zugekommen und hat quasi gefragt, ob es da irgendeine Möglichkeit gibt, also forschungsmäßig mal irgendwas zu bauen. Und das hat dann letztendlich dazu geführt, dass ich eine Diplomarbeit geschrieben habe, genau zu diesem Thema, quasi auch in Kooperation mit dem damals noch einen Hysterium und die Anforderung war es, ein System zu entwickeln, um in so ein großes Netzwerk irgendwie Honeypots reinzubekommen, das aber natürlich möglichst kostengünstig, weil, wenn man Zehntausende von Hoists hat und sowas da drin haben möchte, dann will man da nicht jedes mal einen kompletten Server in jedes Netz stellen, das ist einfach nicht bezahlbar. Das Ding soll benutzerfreundlich sein, denn die ganzen Administratoren, die dort schon drin sind, die sollen auch da drin bleiben und möglichst nicht mehr werden, das heißt, es ist kein Geld da, In der Regel auch keine Vorbildungen, wenn es speziell um Sicherheitsprobleme geht. Also von IT-Sicherheit haben die wenig bis keine Ahnung. Deswegen muss es irgendein System sein, was die auch alle leicht bedienen können. Und das ganze Ding soll natürlich möglichst wartungsarm sein. Also die Grundidee war, irgendein System einzubauen, was mit der kompletten restlichen Infrastruktur nicht viel macht, daran auch nicht viel geändert werden muss, sondern man kann das einfach einstellen, es läuft und das war's. Was natürlich immer nur begrenzt wirklich so möglich ist, wie die sich das vorstellen. Aus der Diplomarbeit ist dann Forschungsprojekt geworden und daraus entwickeln wir jetzt quasi im Moment dran. Wenn man jetzt also sich dieses Netz nimmt und das versucht möglichst abstrakt darzustellen, dann könnte man das so machen. Das heißt, man hat hier ein Netzwerk, was aus ganz vielen kleineren Netzen besteht. Es sind natürlich viel mehr als drei in dem Fall. Und es gibt an zentraler Stelle irgendwie ein Segment, wo die ganzen Server drin stehen. Server im Verwaltungsnetz, das heißt, das sind vor allen Dingen Dienste, die für allen Beamten irgendwie genutzt werden müssen. Da müssen zentralen Datenbanken mit die ganzen Leute registriert sind und so weiter, die natürlich auch für sich wieder gefährdet sind. Und es gibt natürlich einen zentralen Internetzugang. Und jetzt schon im sächsischen Verwaltungsnetz steht natürlich zwischen all diesen Netzen, stehen kleine Firewalls, die natürlich verhindern sollen, dass da gegenseitig schon Zugriffen sind. Diese Firewalls sind auch extrem restriktiv ausgelegt. Das heißt, es ist im Prinzip nicht möglich, von so einem Netz in so ein Netz Daten zu schicken. Und es ist im Prinzip auch nicht möglich, von diesem, dass so ein Server einfach mal so hier irgendeinen Rechner kontaktiert, denn es geht immer nur andersrum. Man kann aus den Netzen raus nach oben, man kann aus den Netzen raus natürlich ins Internet, aber man kann nichts in die andere Richtung. Was es nicht so einfach macht, oder einfach mal irgendeine Architektur reinzustellen und zu sagen, jetzt machen wir hier ganz tolle Sicherheit. Was wir gemacht haben, ist zunächst so genannte Sensoren zu bewerfen. Sensoren sind kleine Geräte, die wir nutzen, die eben möglichst kostengünstig sein sollen, die gehen letztendlich Handysportdienste laufen. Also Handysports müssen nicht Geräte sein, das kann doch einfach ein Programm sein, was diese Aufgabe irgendwelche Angreifer anzuziehen, quasi von selbst erfüllt. Und wir stellen in diese ganzen kleinen Netze sogenannte Sensoren rein, auf denen letztendlich die Handysportdienste laufen. Und wir stellen die auch da oben zu den Servern mit rein. Und dann haben wir den zentralen Server, der auch oben natürlich mit in diesem Serversegment steht. Und alle Ereignisse, die an diesen Handysports registriert werden, sprich alle Daten, die ich hinschicke, alle Verbindungsversuche, die ich damit versuche, aufzubauen, die werden da oben an diesem Server letztendlich registriert. Und der Trick ist natürlich, dass wir irgendwie einen Weg schaffen müssen. Und weil es nicht möglich ist, von diesem Server aus diese einzelnen Geräte zu kontaktieren, müssen diese Geräte in regelmäßigen Abständen quasi in Polling machen und quasi alle X-Minuten sich immer wieder beim Server melden, fragen, gibt es irgendwelche Neuigkeiten, gibt es eine neue Softwareversion, hat sich meine Konfiguration geändert und müssen sich selbstständig aktualisieren. Und gleichzeitig können sie natürlich diesen Server auch erreichen. Und letztendlich gibt es das Hindernis, dass nach draußen wirklich nur HTTP und HTTPS, also die klassischen Protokolle im Web, frei sind und es jetzt nicht möglich ist, beliebige Pots oder Protokolle dafür zu verwenden. Deswegen nutzt das System ausschließlich diese Protokolle. Und auch für so seltene oder ungewöhnlichere Sachen, wie Zeitsynchronisationen, muss quasi auf HTTP zurückgegriffen werden. Was relativ einfach ist, weil jeder Web-Server mit jedem Request immer seine aktuelle Serverzeit ausliefert und man damit einfach sich synchronisieren kann, das zwingende NTP oder dergleichen zu benötigen. Ja, der nächste Grund, warum wir natürlich, also man könnte sagen, die Frage kam letztens auf, man kann die Firewalls ja einfach alle umkonfigurieren. Kann man nicht, es sind sehr viele, jede Behörde ist im Verwaltungsnetz für sich selbst verantwortlich. Das heißt, wenn die Polizei gefragt wird, konfiguriert ihr das bitte um, dann sagen die Nein und dann geht das halt nicht. Deswegen muss man irgendwie mit dem leben, was man da hat. Gut, also nächstes möchte ich ein bisschen auf die Architektur, das Ding ist eingehen, also es gibt halt sowohl die einen Seite die Sensoren mit den Honeypots drauf, auf der anderen Seite den Server. Und die werde ich jetzt beide mal ein bisschen technischer erklären. Ich hoffe nicht zu technisch. Das ist quasi ganz abstrakt gesehen das Server. Der besteht im Wesentlichen aus vier Komponenten. Das ist natürlich ein Web-Server, der drauf läuft. Wir verwenden wie gesagt, TTP als Protokoll. Darunter läuft irgendwie eine Datenbank. Es gibt einen sogenannten Job-Server, der ein paar Aufgaben erfüllt und es gibt diese Ausführungs-Ingebung, also die Basis, auf der das Ganze letztendlich läuft. Das ist das nächste zum Web-Teil. So wie auch viele moderne Web-Anwendungen nutzen wir eine sogenannte RESTful API. Das ist im Prinzip ein Paradigma, wie man TTP nutzen kann, um Anwendungen zu entwickeln. Also, TTP, das Protokoll, mit dem man zum Beispiel eine Website einfach abfragt, bietet verschiedene Methoden an. Die Klassische ist immer diese Get-Methode, mit der man quasi get.google.de einen Web-Server dazu beauftragt, einfach die Website zurückzuliefern. Aber es gibt noch andere Methoden, die gedacht sind, Daten zum Server zu senden, wie eben dieses Put, Post und Delete. Und dieses Paradigma so zu programmieren, sagt, dass man diese Methoden verwendet, um am Ende quasi eine Anwendung zu entwickeln und auf Ressourcen zu arbeiten. Der Server bietet mit der Werdenbank, in der natürlich alle Daten mehr gespeichert sind und diesen Web-Server dann so eine Schnittstelle an und sowohl die Sensoren kommunizieren mit dieser Schnittstelle als auch die Administratoren und müssen sich natürlich entsprechend darüber authentifizieren, damit sie auch Daten hinsenden können und so weiter. Das Resultat ist dann am Ende eine Web-Wendung, die alle möglichen oder denkbaren Verwaltungsaufgaben beinhaltet, die man für so ein Netzwerk braucht. Also das sind natürlich die Verwaltungen von Sensoren. Ich muss welche entfernen hinzufügen, ich muss ihre Konfiguration ändern. Ich habe ja hoffenweise Ereignisse, die durch die Sensoren generiert werden. Die möchte ich schön in der Liste sehen. Ich kann auch automatisch benachrichtigt werden, sobald quasi ein besonders kritisches Ereignis registriert wird, können automatisch E-Mail-Adressen hinterlegt werden, die dann in die Mail bekommen. Die Firma ist im Prinzip das Betriebssystem, das auf den Sensoren läuft. Und das natürlich auch aktualisiert werden muss, weil es jetzt endlich freie Software ist, die da drunter läuft, die ständig irgendwie in eine neuen Version rauskommt und das muss ja irgendwann mal modernisiert werden, gerade im Fall von Heartbleed und sonstigen SSL-Problem. Und es gibt eine Benutzerngruppenverwaltung. Das war eine besondere Anforderung vom Amt. Denn im Amt hat man die ganzen einzelnen Netze und Ressorts, zum Beispiel die Polizei wieder. Und die möchte auf keinen Fall, dass irgendein anderes Ressort, zum Beispiel die Talschbahnverwaltung, sieht, was die Polizei für Probleme in ihrem Netz hat, weil das sofort heißt, da kommt irgendwie ein böse Bericht und die Polizei ist ganz schlecht und so weiter und das verkauft sich politisch alles nicht sehr gut. Deswegen ist es wichtig, das alles strikt zu trennen, aber eben nicht für jedes einzelne Ressort dort einen eigenen Server hinzustellen, sondern es soll möglichst ein Server oder möglichst wenige für das komplette Netz sein. Der Job-Server, das ist in dem Fall Beanstalk, ist ein kleines Projekt, was man auch freies Projekt und da kann man quasi einfach Aufgaben hinschicken, langenhaltende Aufgaben, die dann einfach irgendwann ausgeführt werden, sobald die Ressourcen dazu da sind. Und das wird hier für ein paar zeitintensiver Aufgaben genutzt. Die sogenannte Firmware, die auf den Sensoren läuft, die muss teilweise umkonvertiert werden in verschiedene Formate. Das kann fünf bis zehn Minuten dauern und wird deswegen quasi in die Nachhinten verschoben, indem so ein Prozess dafür genutzt wird. Und das letzte, was noch recht interessant ist, ist die Ausführungsumgebung. Wir haben nicht einfach einen Linux-Server, auf dem das dann läuft, sondern wir nutzen Docker. Das war so ein bisschen so ein Hype-Thema des letzten Jahres gewesen. Da geht es darum, dass man Anwendungen in ein Container verpackt und die Anwendung quasi zusammen mit all ihren Abhängigkeiten damit reinpackt. Das heißt, ich kann ein Container bauen, in dem nicht nur die Anwendung selbst enthalten ist, sondern da ist ein komplettes Basis-Betriebssystem, also ein kleines Linux drin, mit all den Diensten, also der Web-Server, der Job-Server, der die Datenbank und alles, was ich brauche. Und dann habe ich das verpackt in einer Datei und kann das auf einem Server, der dieses Docker-System unterstützt, und dann läuft das für sich. Und wenn es da irgendwo Updates gibt, dann kann ich diesen Container auch gleichzeitig wieder komplett aktualisieren und einfach eine neuen Container quasi nebenbei, wo alles aktualisiert wurde, und dann läuft das System unbeeinträchtigt weiter. Was wahnsinnig praktisch ist, um eben Anwendungen schnell auf Hosts hin- und herschieben zu können. Das nächste ist der Sensor, den ich noch erklären möchte. Das sind dann die kleinen Geräte, die überall in die Netzen stehen, und die haben natürlich ein paar sogenannte Handysportdienste, die am Ende wirklich die Interaktion ist, das ist ein Gerät, das hängt irgendwo im Netz und hat eine IP-Adresse, und darauf laufen diese Dienste, die am Ende für den Angreifer quasi interessant sind. Darauf sind eine Reihe von Diensten, die zum Management des Sensors wichtig sind, und natürlich hat das auch wieder eine Ausführungsungebung, das ist in dem Fall das Gerät, wo das am Ende einfach drauf läuft. Handysport-Services sind 3 Stück aktuell, das ist einmal Kippo, das ist ein kleines, freies Python-Projekt, das den SSH-Server simuliert. Weil man kann sich mit diesem Server natürlich verbinden, man kann da benutzernah einen Passwort eingeben, man kann, aber wenn man die richtige Kombination eingibt, dann auch dort eine emulierte Shell bekommen. Man kann auf dieser Shell auch Befehle ausführen, und man kann auch, wie ich meine, wegen mit Weget dort seine eigene Mailware nachladen, um dann weiter ein Exploit nachzuziehen, um das Gerät wirklich zu übernehmen, aber in der Stelle geht es nicht mehr weiter, weil es eben keine echte Shell ist, sondern es ist nur simuliert. Aber das Schöne ist alles, wenn man diesen Kippo-Handysport tätigt, alles wird aufgezeichnet, alles kann ich später dann auch wieder nachlesen und kann wirklich rausfinden, was wollte der Angreifer eigentlich machen und warum. Das nächste ist Dionair, das ist ein Projekt, was aktuell seit 2 Wochen nicht mehr irgendwie online ist, zum Glück habe ich die Quellen noch, und das bietet eine sehr große Auswahl in Protokollen an, und die sind alle unterschiedlich gut unterstützt, also unterschiedlich gut simuliert für einen Angreifer. Am interessantesten ist das SMB-Protokoll, das ist quasi Samba, also Windows-Datei-Freigaben, und das simuliert das Samba-Protokoll in einer sehr, sehr alten Version, sodass da haufenweise Sicherheitslücken potenzielle drin sind, die man auch versuchen kann, wirklich auszunutzen und versuchen kann, diesem Server dann da irgendeine verseuchte Binary unterzuschieben, und der speichert die dann einfach weg und schließt wieder die Verbindung, weil das natürlich alles nur ein simuliertes Protokoll ist, also man kann diese Freigabe nicht nutzen, um irgendwelche Dateien darauf zu speichern, man kann wirklich nur versuchen, bekannte Schwachstellen auszunutzen. Der beantwortet quasi alle sonstigen Anfragen, die da ankommen, die jetzt nicht an den SSH-Dienst oder an die Samba-Freigabe gehen und versucht, das erste Datenpaket, das ein Angreifer dahin schickt, einfach einzusammeln. Das heißt, wenn ich dort ein UDP- oder TCP-Paket hinschicke, dann wird im Fall von UDP, das ist sehr technisch, einfach der Inhalt aufgezeichnet, der in dem Paket drin steht und im Fall von TCP wird erst eine Verbindung aufgebaut, dafür braucht man den obligatorischen TCP-Handshake, dann wird das erste Datenpaket eingesammelt und quasi aufgezeichnet und die Verbindung wieder geschlossen. Das könnte natürlich ausgenutzt werden, wenn ich jetzt einen Portscann mache, dann hätte ich da 65.000 auf eine Ports, wo ich über Verbindungen aufbauen kann, das heißt, das würde recht viel Last verursachen, deswegen ist da noch ein entsprechender Schutz drin, sodass ab einer gewissen Menge quasi da einfach Schluss ist und die restlichen Ports dann da offiziell zu sind und es ist auch entsprechende Portscann-Erkennung dabei, sodass ich, wenn ich jetzt mit quasi einen Portscann durchführe, dort nicht 65.000 Ereignisse in meinem Backend am Ende sehe, sondern nur eins, das ist halt ein Scan-Vorgang gewesen. Das sind die Dienste, die dienen im Wesentlichen zur Installation und zur Konfiguration. Ich kann mir mit dem Server im Prinzip für jeden Sensor eine Konfiguration generieren. Ich kann die auf diesen Sensor kopieren und sie dann dort entsprechend installieren lassen. Genauso sind die Skripte dabei, die dieses regelmäßige Polling durchführen und kontrollier den Server quasi immer nach Neuigkeiten fragen. Und es ist ein relativ umfangreiches Skripte dabei für eine Update-Prozedur, sodass sich der Sensor auch selbstständig updaten kann. Genauso wie der Server natürlich, Sicherheitsupdates und dergleichen braucht, und das ist ja auch mit berücksichtigt. Als Ausführungsumgebung nutzen wir den Beaglebond Black. Das ist ein kleines, armbassierter Sport, ähnlich wie der Raspberry Pi. Wer den kennt, mit so einem 8-Kern, ein halben Gigabyte RAM, ein paar Gigabyte internen Speicher, das ist dann der Unterschied zu einem Raspberry Pi und einer MicroSD-Karte, also man hat quasi zwei Festplatten, wenn man es so sagen möchte. Und das Ding ist natürlich sehr praktisch, weil es wenig Strom braucht und vor allem, weil es für um die 40 Euro zu haben ist dann als Sensor-Firmware nutzen wir also als Betriebssysteme einfach einen Debian Linux. Und eine Besonderheit, was relativ viel Arbeit jetzt mit den Dingern gemacht hat, ist dort eine komplett vollständige Update-Prozedur zu implementieren. Also es ist quasi möglich, auf dem Server eine neue Firmware zu hinterlegen, die enthält so ein komplettes Debian-System für so einen Sensor. Der Sensor lädt sich das Ding runter, schreibt das auf seinen externen Speicher, startet davon wieder und schreibt es quasi zurück auf den internen und dann können alle Komponenten des Systems aktualisiert werden, ohne dass man dort inkrementelle Updates macht, die dann häufig irgendwann mal Nutzerinteraktion brauchen, was bei so einem Gerät und der Bildschirm meist nicht so einfach ist oder wo man eben Annahmen nicht einfach so treffen kann oder wo dann einfach was kaputt geht bei einem inkrementellen Update, wo man keine gerechnet hat. Deswegen ist es meist einfacher, einfach das Ding komplett zu zu überschreiben. Und jetzt neu im Rahmen des Forschungsprojekts haben wir auch Debian-Pakete erzeugt. Und damit quasi das auf allen beliebigen Rechnern laufen lassen. Es gab eine Anfrage von der Firma, das System zu nutzen, die hatten irgendwelche alten Server umstehen und haben gefragt, ob sie die nutzen können. Die sind damit natürlich jetzt ziemlich gelangweilt, aber die könnte man theoretisch auch für sowas dann einsetzen. Natürlich ist es da dann wichtig, dass die Administratoren selbstständig den Rest administrieren. Also dieses komplexe Update Ding, was jetzt die Biegel bei uns machen, das geht dann eben nicht mehr, sondern dass es aktuell hält. Aktuell beziehungsweise ab jetzt kann man sagen, sind die wichtigsten Features da implementiert. Die gewünscht wurden seitens des Amtes und die noch irgendwie interessant waren. Es gibt immer noch offene Bereiche, die irgendwie ein bisschen geforscht werden soll, was da noch so möglich ist. Aber im Wesentlichen gehen wir jetzt in den Testbetrieb über und das versuchen wir auch seit 6 Monaten, sprich seit Beginn des Projekts. Es ist bisher einfach daran gescheitert, dass es sehr schwierig ist, und deswegen einfach mal mit drauf laufen lassen kann. Und wir haben hoffen, um bis Ende des Jahres das irgendwann mal noch zu bekommen. Das ist einfach eine Vm, die quasi genehmigt ist. Und sobald das passiert, können wir anfangen, in interessierten Behörden und Ressorts solche Geräte einzustellen, einfach mal zu gucken, was da überhaupt an Daten anfällt. Wie gut das überhaupt skaliert. Wir wissen nicht, wie gut, wie viele 100 Sensoren man verwenden kann, bevor der Server überlastet ist zum Beispiel. Das wollen wir einfach mal rausfinden aber halt nur mit ein paar wenigen Geräten, wo man einfach prinzipiell mal schauen kann, funktioniert das eigentlich. Das war es dann auch schon wieder von meiner Seite. Also wenn irgendwie Interesse besteht, darüber zu reden, einfach mal vorbeikommen oder eine E-Mail schreiben. Ich habe noch eine kleine Demo mit, aber das ist jetzt hier nicht so günstig, einfach mal persönlich auf mich zukommen, wenn da irgendwie Interesse besteht und dann kann man sich das Webinterface mal anschauen. Ansonsten, danke schön. Fragen, natürlich. Mikro. Das klang alles ziemlich nett, aber habt ihr schon so richtig Erfolge damit mal gehabt? Also so richtig, alles Ding festgemacht, nicht nur so ein dumm Virus oder Trojaner, sondern auch mal richtig ein Angreifer? Na ja, die Wahrscheinlichkeit, wie oft kommt es quasi vor, dass so was passiert. Wir haben im Vorfeld, bevor das quasi alles erstmal so entstanden ist, Tests gemacht, indem wir genau solche Beaglebohns im Verwaltungsnetz verteilt hatten, es war viel einfacher, als ein Server dazu zu haben und haben einfach mal aufgezeichnet, was jetzt direkt bei dem Gerät ankommt und da waren in einem Zeitraum von 2 Wochen schon 2 Sachen dabei, die ausgesprochen kritisch waren. Also das waren eben so nachts um 5 irgendwelche Anfragen an Sachen, die da eigentlich nicht sein sollten, wo man dann auch ein bisschen nachgeguckt hat und ja, so was schon, aber ich kann leider oder darf auch nicht sagen, was da dann am Ende bei rausgekommen ist. Was passiert denn, wenn die Sensoren kompromiert werden und nicht mehr auf den Server zu greifen können? Kann das sein, dass die Server darauf reagiert, dass es bemerkt, wenn Sensoren seit lange nicht mehr gemeldet haben? Genau das macht er. Also da ist im Prinzip, wenn standetmäßig beispielsweise eingestellt ist, dass alle 20 Minuten die Sensoren sich beim Server melden sollen, dann merkt ihr natürlich, ab der Minute 21, dass das Ding nicht mehr gemacht hat und zeigt es dann auch entsprechend an. Das kann sein, weil er einfach ausgeschalten wurde, das kann sein, weil er entsprechend kompromittiert ist. Aber an der Stelle ist es quasi Aufgabe des Admin's, dort zu schauen, was ist mit dem Gerät los. Es ist allerdings für die Sensoren nicht möglich, irgendwas an dem Server zu verändern. Also alles, was die machen dürfen, ist quasi ein Ereignis hinschicken, was aufgetreten ist. Aber sie haben jetzt keine sonstigen Rechte oder irgendeine Shell oder sowas und damit solltet das Ausmaß des Schadens relativ gering sein. Noch weitere Fragen. Das sieht nicht so aus. Hier ist noch einer. Ja, SD-Karten und dieser interne Speicher, das sind ja diese zwei Komponenten auf diesem Beagle bauen, SD-Karten gelten ja als nicht so besonders zuverlässig. Also die können schon mal abbrauchen. Wie ist denn da die Zuverlässigkeit von dem System, wenn dieses Update gefahren wird und eine andere Frage, die ich dazu noch hatte, wird das System zuerst auf der SD-Karte gespeichert und überschreibt den internen Speicher oder wie läuft das? Aktuell ist es tatsächlich so. Leider laufen die Systeme derzeit und der internen Speicher nur als Cash beim Update. Es ist natürlich Quatsch und sollte dann längerfristig mal sich drehen, so dass wenn die SD-Karte nur noch beim Update benutzt wird, was wie oft vorkommt, also sehr selten, dann sollte es nicht so ein Problem sein. Also der internen Speicher des Beagle-Bones ist nicht einfach nur eine aufgelötete SD-Karte, sondern das ist irgendwas Besseres zumindest, wo die selber sagen, das ist total toll haltbar. Ich habe es zumindest bisher noch nicht erlebt, dass dieser internen Speicher irgendwelche Probleme gemacht hat. Eine weitere Frage? Ja, meine Frage wäre noch, ob der Honeypot wirklich jeglichen Netzwerkverkehr mitkriegt. Also sprich, in welchem Modus der Betrieb ist und was der eigentlich hört dann. Also ein Promisk. Bei Netzwerkgeräten kommen im Prinzip drei Arten von Daten an. Das ist natürlich einmal direkt an das Gerät gerichtete Sachen, also quasi an die IP-Adresser adressiert. Das wird natürlich sofort aufgezeichnet, also im Fall von Broadcast und Broadcast, also im Fall von Broadcast einfach ein Paket, das an alle Teilnehmer des Netzes geschickt wird und theoretisch könnte man das aufzeichnen. Jetzt hier im konkreten Fall ist es allerdings nicht gewünscht, weil im Amt es möglich wäre, über solche Daten dann quasi was über die Topologie des Netzwerkes zu erfahren oder auch noch irgendwelche anderen Sachen und deswegen war es quasi eine explizite Anforderung, dass solche Sachen nicht aufgezeichnet werden sollen. Weil es aber auch andere Interessenten gab, die das System irgendwann nutzen wollen, schon geplant, mit einfach einem Schalter zu sagen, okay, ich möchte sowas aufzeichnen oder nicht und dann können irgendwelche Firmen oder so, die das nutzen wollen oder wenn man das privat machen möchte, kann man das natürlich auch einfach an und ausschalten, wie man das haben möchte. Hier gibt es noch eine Frage. Weil du gerade gesagt hast, mit privat das machen ist es möglich auf die Software irgendwie zuzugreifen, dass selber irgendwie so ein Testspielsystem aufzubauen oder ist das angedacht oder wie wird das verteilt, lizenziert, verkauft? Das ist eine sehr spannende Frage. Wir versuchen gerade selber zu beantworten. Ich weiß es leider nicht. Ich habe schon mit der Frage gerechnet, wird es denn Open Source oder ist das Open Source aktuell? Ist das nicht? Es ist gut möglich, dass es das irgendwann mal wird. Aber zurzeit müssen wir quasi erstmal diesen Schritt gehen, das im Amt zu testen und das quasi irgendwie im Amt zu etablieren und mal gucken, was dann danach kommt. Also leider zurzeit noch nicht. Es gibt ein paar Firmen, die da Interesse dran hatten, aber auch da war quasi erstmal so dieses Vertrösten. Und dann müssen wir mal schauen. Also leider zurzeit noch nicht nutzbar, vielleicht in einem Jahr. Wobei ihr ja aus diesem HoneyNet-Projekt jede Menge Zeug benutzt und das ist ja frei. Man könnte sich ja das relativ einfach nachbauen, zumindest den Teil, der da den Sensor hat. Ja klar, also Daniel, und gut, das ist jetzt offline, aber da gibt es auf GitHub auch ein paar Repos, die das noch geklont haben und das Keyboard kann man natürlich selber nutzen. Was mich noch interessiert, macht ihr da auch das, was die HoneyNet Leute dann gemacht haben, weil diese HoneyNet-Leute, die haben ja dann damals da, das fing ja mit diesem Nepentis an, das Dioneer ist da ja nur dann quasi der Rewrite gewesen, dass die halt gecaptured haben, was da für Melwerk kam und dann das Zeug quasi mit LibEmu ausgeführt haben und dann da versucht haben, automatisch irgendwelche Signaturen für irgendwelche Intrusion Detection Systeme zu generieren. Macht ihr sowas auch oder seid ihr da noch eher am Anfang? Nee, nee, das Dioneer, also dieser Dioneer-Dienst ist ein direkter Nachfolger von Nepentis. Das heißt, diese Features sind da quasi mit drin und wir nutzen die einfach, also das macht das nach wie vor. Also sprich, wenn man quasi über die Windows-Freigabe, über das Summer Protocol, irgendein Angriff fährt, dann wird genau das alles gemacht, aber es werden natürlich keine Signaturen generiert, sondern das dient im Prinzip dann nur dazu, dass der Admin im Backend relativ ausführlich sieht, was da irgendwie versucht wurde, welche Melwer der hochgeladen wurde und so ein Kram, aber drauf reagiert wird automatisch nicht, wie reagieren darf, sondern das müssen die Admin per Definition bei im Amtfeld machen. Aber prinzipiell schon, ja. Aber jetzt für die ganzen anderen Anfragen aktuell nicht. Also wir haben es nicht selber so was noch mal implementiert. Nach Fragen. Ich muss vielleicht abschließen nochmal dazu sagen, also die Besonderheit des Projekts, es gibt noch ein anderes Projekt, was sowas Ähnliches macht, das ist komplett frei, das ist ein Name, das ich gerade vergessen habe. Die Firma heißt Threadstream und die haben auch so ein freies Sensor-Netzwerk quasi zur Verfügung gestellt, also hier war es eben ganz wichtig, dass man da ein hübsches Bundes-Web-Interface hat, dass das alles toll managebar ist und alles von selbst gut funktioniert, während dieses Threadstream-System das halt nicht so toll macht. Also da muss man ganz, ganz viel von Hand noch ein bisschen nacharbeiten. Und das Zweite ist, dass hier der Fokus vor allem darauf liegt, dass man wirklich quasi Innentäter findet, also versäuchte Rechner im Inneren, Angreifer aufs Inneren, man sollte so ein Sensor nicht direkt ans Netz hängen, weil es einfach dazu führt, dass so viele Ereignisse registriert werden, das hatten bei Implikationen mit sich gebracht, was das System hier von anderen Systemen so ein bisschen unterscheidet.