 Im Vortrag des Tages 1 auf dem 35 C3, Sergey Gordaychik hat Sicherheitsvorschung in mehr als den letzten 14 Jahren betrieben und er arbeitet bei einem der größten IT-Security-Konferenz in Osteuropa gearbeitet und auch bei der Universität in Barcelona und in der SCADA Strangelove Industrial Security Research Team und er wird heute darüber reden wie wir software definierten Netzwerke absichern können und wie wir dabei unseren Kopf behalten können. Ein warmruhender Applaus für Sergey Gordaychik oder wie man auch immer ausspricht tut mir leid, ich habe das komplett vor uns. Hallo, einen wunderschönen guten Abend, wir werden damit anfangen ein paar Erinnerungen wieder aufzurufen. Ich bin sehr geehrt dafür im 35 C3 zu sprechen und ich bin Leiter des Strangelove Teams und ich mache eine kurze Einführung, vielen Dank für unseren, für unseren Host, der hat alles gesagt was hier schon auf der Folie zu sehen sein sollte, ich möchte noch kurz darüber reden, ich bin eine Russe, lebe in Abu Dhabi, aber ich mache nur Bitcoins, das uns über software definiertes Netzwerk reden, was ist das überhaupt so generell und was ist in diesem speziellen Fall. Nach Gärtner wird es die meisten Cisco und Juniper und Hawaii-Gräte ersetzen in den nächsten Jahren und es wird alle unsere Netzwerkprobleme lösen, weil es Artificial oder künstlich Intelligenz drin hat und es wird die meisten großen Netzwerkooperationen werden, es benutzen und es wird alles machen inklusive Sicherheit und weil es so sicher ist, es zu implementieren in großen Langstrecken-Netzwerken und auch die Sicherheit zu Sicherheit führen, aber was ist software definiertes Netzwerken in Wirklichkeit? Es ist so einfach, wie man es hier auf dem Beispielbild sieht, wenn ihr die Grundregel von Switches hat, es empfängt Pakete und sendet sie weiter nach Routing-Tables oder Software definiertes Netzwerk, es ist sehr anders und wenn wir versuchen es zu verstehen, war unsere erste Idee so, wir sind Hecker, wir wollen mit dem ganzen Zeug gar nichts zu tun haben, aber die einzige Herausforderung, die wir machen, erstellen müssen, bevor wir Hecken können, mussten wir erst mal aktivieren und verstehen, wie es im Internet funktioniert. Der Hauptunterschied zwischen traditionellem LAN und WAN ist, im LAN haben wir unterschiedliche Geräte, die unterschiedliche spezielle Aufgaben haben, Switches, Firewalls oder Loadbalancers. In SD1 Software-Netzwerken ist irgendein Linux auf irgendeiner Kiste und auf diesen Geräten, auf diesem Betriebssystem haben wir sehr spezifische Module, also CPEs, die spezifische Netzwerk-Funktionalitäten machen, es kann Firewalls oder Routing sein oder Netzwerkbalancing. Spezifische Geräte werden mit einem großen Server ersetzt und der macht wie mit Magie alles automatisch und in der Cloud und SD1 haben wir, wir haben ein Datenplan und da werden echt Pakete angeschaut und da werden wir übersehen, wie Firewalls funktionieren oder ob sie weitergeben. Wir haben einen Kontrollplan, der unterschiedliche Geräte managt. Wir haben ein Management-Schicht, die Regeln herausbringt und wir haben ein Orchestrationsschicht, die wir sehr einfach brauchen. In der technischen Schicht haben wir Hardware-Funktionsvirtualisierung und eine Schicht, die Netzwerk-Funktionsvirtualisierung-Schichten heißt. Was ist das? Das haben wir eine Schicht, in der unterschiedliche Netzwerk-Funktionen, also auf diesem spezifischen Gerät ausgeführt werden können. Also es ist sehr hilfreich für Netzwerkooperat-Betreibern, die einen spezifischen Kiste haben und wenn man eine spezielle Funktion, eine Web-Anwendung, eine Firewall oder eine Sandbox haben neu hinzugefügt werden soll, dann kann einfach eine weitere Virtualisierung hinzugefügt werden. Das kann ein KVM-Modul sein oder ein Docker-Modul sein und dann wird es da ausgeführt und man kann es einfach benutzen. In der Kiste haben wir alle Systeminfrastruktur, um von einer virtuellen Netzwerk-Funktion in die andere die Datenwand zu geben. Dies hilft uns dabei Sachen wie Serviceaufbau oder Kettenaufbau zu funktionieren. Man kann Sachen auf unterschiedlichen Level zum Beispiel auf den Geräten oder auch in der Cloud machen. Content, also Inhaltefiltern, was sehr viel Performance verbraucht oder kann verteilt werden. Zum Beispiel auf dem Branch-Schicht kann man einfach Sachen wie Antivirus laufen lassen, aber dann auf dem HQ Level kann man Sandboxen durchführen und wenn man ganz spezifische Regel haben möchte, weil dieser ist problematisch, dann wird das zum HQ weitergeleitet, wo ein spezielles VPN und weitere Anforderungen werden dort analysiert. Aber man kann auch es in der Cloud analysieren, wo einfache Funktionen wie Cloud Thread Intelligence, wo die SDN-Box ein MD5-Fesh in die Wolke in den Cloud sendet und überprüft oder man kann einfach alle Dateien in die Cloud weiterleiten, um noch mal sicher zu gehen. Das ist nicht schlecht und das ist eine der Gründe, weshalb Software-Defense Netzwerking beliebter wird und die Militär-Leute, die werden, haben das ausgewählt, weil es billiger ist und bessere Sicherheit hat und andere Vorteile. Sicherheit hört sich für uns sehr gut an und wir haben beschlossen es zu herkennen. Die meisten von euch haben irgendwelche Ahnung davon wie mein Netzwerk Geräte hackt, also muss irgendwelche komplexen Geräte haben, wie zum Beispiel einen Lötkolben oder einen JTAC-Immulator, um es zu debaggen, aber in diesem Situation brauchen wir das Ganze nicht, weil Software-Defense Netzwerking ist nicht ein Gerät, sondern eine virtuelle Maschine und das einzige, was uns zu hacken, müssen wir auf die Azure oder Amazon Cloud anmelden und dort für 10 Euro oder 10 Dollar im Monat das starten und dann müssen wir Ruth auf der Kiste bekommen. Das ist ein sehr schöner Vortrag auf verschiedenen Konferenzen wie zum Beispiel Zero Nights, wie eine virtuelle Maschine gehackt werden kann, wir haben eine Checkliste, die wir benutzen und wenn man eine virtuelle Applikation hat, dann haben wir schon Zugang zu dem System, wir können ein exzitiziges Arteilsystem mounten, bei anderen Applikationen kann man ist der JTC-Shader aufhinden, viele Hintertüren können gefunden werden, auch wenn man nur Stadtchanalyse machen kann, aber alles beginnt mit Google, zum Beispiel um ein Admin-Passwort für eine von diesen Applikationen zu haben, haben wir einfach GitHub gesucht und haben gefunden die meisten Skripte zur Automatisierung gefunden haben und dort wird der Benutzannahme Administrator und das Passwort Versa123 benutzt und es ist anscheinend, dass diese Benutzannahme und Passwort akkodiert in der Software, weil man kann es nicht einfach ändern. Der nächste Schritt um jetzt zu ruten ist einfach nach alten Vulnerabilities zu suchen, zum Beispiel in Serverpeak haben wir gefunden, dass die Leute dort eine Vulnerability im September gefixt haben, aber im März 2018 funktioniert es immer noch mehr als drei Jahre später und da hilft Google, weil der Google-Fu ist stark in diesem. Grab funktioniert auch sehr gut, um Strings zu finden und Grab und Passwort findet man sehr interessante Dateien wie zum Beispiel festgeschriebene Passworten in unterschiedlichen Orten und Konfigurationsdateien und Datenbankverbindungsstrings und Systemlogs und in vielen Sachen. Es sind virtuelle Applikationen und irgendjemand hat sie schon veröffentlicht gelaufen gehabt bevor wir sie verbinden. Das heißt in den Logs sind sehr viele interessante Informationen. In dem Shadow-Fall bei Linux haben wir dieses Passwort gefunden, dass mit des verschlüsselt wurde, was ein relativ unsicheres Verschlussverfahren ist. Wir können schon gewisse Forensik darauf laufen lassen, weil es ist schon mal gelaufen. Teilweise wird versucht man, dass das versteckt wird, weil in diesem Fall ein Scrub-WS-Shadow-Script daus laufen gelassen, das verschiedene Sachen entfernt. Das heißt, wenn man das recoveren kann, dann kann man noch weitere Informationen finden über Admin-Passworten usw. Und in diesem Passwort kann man dann das Hash finden und dann kann man es raten oder zu Bruteforcen. Weil Versa 1, 2, 3 häufig benutzt hat, habe ich jetzt auch mal ausprobiert und ja, wir haben es richtig geraten und das war gut, weil wenn man viel mit Sicherheit im Betriebsnetzwerken hat, gibt es da häufig übliche Passwörter. Manchmal ist es ein bisschen komplex, aber in der Regel, wenn man es nicht, das Rout-Passwort so einfach gefunden hat, dann ist es eine virtuelle Applikation. Das heißt, man kann es immer noch patchen oder eine virtuelle Maschine. Das heißt, man kann einfach den Hash in der HTC Shadow austauschen. Man kann einen BootScript hinzufügen, man kann den Management-Modus konfigurieren und man kann Management-Modus buten und dann kriegt man eine Routshell. Und dann kann man das Sicherheitsassessment durchführen. Ein Sicherheitsassess-Überprüfung beginnt damit, dass man einen nicht-wissenschaftlichen Weg, wir hacken einfach alles und später haben wir dann ein paar wissenschaftliche Methodiken darauf angewendet und wir haben ein Artikel oder ein Paper darüber geschrieben und wir zeigen die unterschiedlichen Sachen, wie man das hacken soll, um maximale Ergebnisse zu bekommen. Lass uns jetzt erstmal ein paar lustige Hacks und den wissenschaftlichen Ansatz benutzen. Von einem Systemadministratischen Ansicht hat an ASN, haben sie Hardware und ein Betriebssystem. Das ist in der Regel ein ganz normales Linux und verschiedene virtuelle Services. Lassen wir uns mal mit dem Betriebssystem anfangen, weil wieder alles, was wir im ganzen Rest des Vortrechts gesehen haben über Remote Management Interfaces funktioniert hier, außer es wurde von ihnen ausgeschaltet. Aber es ist sehr unwahrscheinlich. Ein Betriebssystem war sehr einfach analysiert. Wir haben den Patch-Level auf der Kiste angeschaut und wir können sehen, dass das Patch-Level sehr alt ist. Zum Beispiel der alteste Sache, die wir gefunden haben war ein Open-SSL-Bibliothek, die war im Mai 2006 veröffentlicht. Das ist für Netzwerkgeräte mit Sicherheit Funktionen. Aber wir vermuten, dass diese alte Version verwendet wurde, weil diese alte Version zu alt ist, um die ganzen Hard-Bleed-Angriffen angegriffen werden zu können. Die alteste Library in der kommarziellen Produkt war im Siemens Semantik. Das war eine Open-SSL-Version, die in 2007 veröffentlicht wurde. Also das ist eine echte alte Version. Eine andere Idee ist, ob im System Sudo ist und es wird überall verwendet, inklusive im Shells und Web-Interfaces und es ist in einer grausamen Art und Weise implementiert. Alle können alles ausführen, ohne Passwort und einiges Skriptik, können jeden Befehl als Sudo ausführen. Das heißt, wenn man irgendeinen kleinen Unsicherheit im Web-Interface hat, wie in dieser Situation, wo ein Kommando für Fehl-Injection hat, kann man ein Befehl als Rout ausführen. Das ist wie in den 90ern. Als nächstes nehmen wir das System. Also wir nehmen das System von dem Software-Design, sehr viele Open-Source-Komponenten fürs Routing, aber fürs Management verwenden wir HTTP mit PHP drumherum. Das ist jetzt HTTP für die Web-Management-Interfaces. Wir finden überall Node.js und JavaScript, weil das cool ist, aber unten drunter kann man ein hard-coded Mix von Perl, Java und PHP finden. Das ist über die letzten zehn Jahre entwickelt worden und bei dem Node.js verwechseln sie client-and-server. Es ist ziemlich hard zu verstehen, wenn Java script auf beiden Seiten ist und da gibt es also slow-HTTP-Denial-of-Service-Taken und dann geht das Web-Interface nicht mehr. Hier sind ein paar Beispiele. Was machen die hier alles auf der kleinen Seite? Überall gibt es JSON und die meisten Web-Interfaces schützen sich nicht gegen Cross-Site-Scripting. Und das ist kein Problem. Der eine Hersteller hat ein Product Manager und sagt, das ist gar kein Problem. Hier ist ein Beispiel von Cross-Site-Scripting. In dieser Appliance kann man Cross-Site-Queries verwenden, um ein neues Zertifikat hochzuladen, mit dem sich das Ding gegen das Control-Plane authentisiert. Und der Hersteller hat an dieser Stelle keine Antwort gegeben. Hier ist ein Beispiel von perfekter Authentisierung. Auf der kleinen Seite schickt das JavaScript die Frage zum Server und sagt danach geht es zur Request-Site. Ansonsten gehen wir wieder zurück zur User-Name-Password. Das ist alles kleinen Seiten. Hier ist das zweite Beispiel. Der hat versucht die Authentisierung von der Server-Site auf die kleinen Seite drüber zu ziehen. Es ist ja JavaScript, aber es funktioniert irgendwie nicht im Browser. Und jetzt hat er gefragt, ist der User-Name das und das Password jenes, dann setzt den Status richtig und dann geht es schon. Dann haben wir hier noch was Interessantes und Lustiges. Hier gibt es eine Privileg-Escalation-Probleme. Wenn ich es schaffe, Zugang zu einer kleinen Appliance zu kriegen, kann ich versuchen, auf eine andere kleine Appliance rüber zu hüpfen. Es gibt eine ganze Menge Open-Source-Komponenten. Hier zum Beispiel Shell in der Box, zu einem Web-Interface, Monin und Solar. Das sind System-Management-Tools. Es gibt keine Verbindung von der Außenseite mit diesem Ding aufbauen, aber wenn ich schon auf dem Log-Lost bin, dann kann ich auch mich mit dem Log-Lost verbinden. Und dann funktioniert auch diese Verbindung. Das funktioniert, weil ich auf dieser Appliance viele virtuelle Boxen fahre. Wenn ich also jetzt hier Docker fahre, dann haben diese ganzen Docker-Container eigene IP-Adressen. Von draußen sind das alles Connections zu Log-Lost. Wenn ich auf das Home gehe, dann komme ich an alle dran. Das zeigt uns viele interessante Wege auf, wie man Privilegien eskalieren kann. Jetzt seht ihr meinen Point hier. Wenn ich Zugang zu diesem Verkehrsprozessor, Traffic-Prozessor schaffe, dann kann ich versuchen, von dort mich zu Management Anwendung aufzuspringen. Und dann kann ich rüber springen zur nächsten, weil die sich gegenseitig vertrauen. Das heißt also, ich kann meine Privilegien horizontal zu den Nachbarn ausweiten. Oder ich kann runter zum Betriebssystem gehen und kann versuchen auf die Management Appliance draufzukommen. Aber es ist richtig langweilig, in so einem großen Mengecode Wunderbilistik zu finden. Und deswegen habe ich hier ein interaktives Code Analyse-System verwandt. Und der hat uns geholfen, alles möglich zu finden. Wir haben also hier eine Apache-Wulnerabilität gefunden. Das kommt aus 2017. So, beim Get haben sie es in Ordnung gebracht, aber beim Post funktioniert es immer noch. Hier ist ioda-Lehre, was ich hier mache. Ich laufe den Pfad drauf, wenn ich sage, ich hätte keine Folgen des fangen Anhangs und dann kriege ich das raus. Wir zeigen hier die Liste aller Probleme, die wir gefunden haben. Der nächste Schritt ist zu schauen, wo die Kryptografie falsch angewandt ist. Also das erste ist hier SSL und TLS. Die schützen die Management Interfaces zwischen den verschiedenen Boxen. Die haben also sehr viele Dinge unsicher konfiguriert. Die haben keine Forward Secrets eingeschaltet. Das heißt also, wenn ich das Zertifikat habe, dann kann ich mehr in der Mitte da drauf fahren. Dann ist es möglich, die alten Cypher-Sweets zu verwenden. Bei der IPv6-Anwendung haben wir häufig gefunden, dass die ganz komisch die Zertifikate auswählen. Oder dass sie einfach hart gekotet sind. Jetzt kommt etwas, was wir bald publizieren werden. Das kommt von Citrix Netscaler. Die nutzen einen Protokoll namens Master Control Node. Das hat einen Kontrollplan. Da gibt es Zertifikate drauf. Die wohnen hier in diesem Pfad, Hometalarius Zertifikate. Der benutzer BWW-Data kann voll auf diese Zertifikate zugreifen. Wir haben auf allen SD-Warn Appliances das gleiche Schlüsselpaar gefunden. Das heißt, alle in der Welt schützen ihre Kommunikation mit dem gleichen Schlüsselpaar. Wenn man das kennt, man kann es aus dem Fallsystem herausholen. Dann kann man den Treffink mitschneiden, dann kann man in der Mitte machen. Und wenn die irgendwelche Web-Anwendungsprobleme haben, dann kann man auch auf die zugreifen. Wir haben interessante Sachen gefunden. Wir haben Denial-of-Service-Attacken gefunden. Und zwar so Riccata, was in der SD1 Appliance genutzt wird. Und das ist verletzlich zu diesem Regular Expression Denial-of-Service. Wenn man da bestimmte Strings hinschickt, dann braucht es extrem lange. Das ist in so Riccata in Ordnung gebracht worden, aber leider nutzen die eine alte Version. Und wenn man jetzt Fuzzing macht, dann hat man auch viel Spaß. Das kann man hergehen und kann Reverse-Engineering machen. Wir haben also keine Lizenz dazu gehabt. Aber es scheint so, als ob die Ingenieure Star Wars mögen und Marvel hassen. So, jetzt ist hier mal eine Zusammenfassung von den Problemen, die wir hier alle gefunden haben. Grün ist für den Hersteller gut und für uns schlecht. Rot ist, wo wir es gefunden haben. Das Rote sind alte Komponenten oder falsche Benutzung. Also, wenn man irgendeine SD1 auswählt, dann... So, jetzt bieten die ja so an, dass es Zero Touch ausrollen. Wenn ich jetzt irgendwo eine Außenstelle habe, dann brauche ich nur dieses Gerät dahin. Ich muss die Kennung von dem Ding kennen und ich muss es dahin schicken. Das verbindet sich mit dem Cloud Server, mit dem Internet. Und hier ist das Citrix Beispiel. Wir haben es also in die Außenstelle geschickt. Und das hat mit den Nachbar Appliances eine Verbindung aufgebaut. Das geht zur Cloud, zeigt seine IT. Und ich kann jetzt also auf einem zentraler Stelle aus das managen. Aus der Sicherheitsperspektive sieht das furchtbar aus. Der Cloud Security Server, der sollte eigentlich freundlich sein, aber ein Angreifer ist es halt nicht. Wenn also da irgendwo Schwachstellen im Management Server sind, dann kann ich alle Geräte, die von diesem Server vertretet werden, kontrollieren. Wir haben uns den mal ein bisschen aus der Security Sicht angeschaut. Und die haben also genug Probleme. Hier sieht man da den Cloud Server, mit dem sich alle Netzwerkeräte verbinden. Die haben aber auch Probleme in den Distributions gefunden. Viele von diesen Dingen können als eine Cloud Appliance aktiviert werden. Und wir haben gefunden, dass die meisten Default Images alte Implementierungen sind, die bekannte Fehlerstellen haben, Vulnerabilities haben. Das erinnert mich an eine Geschichte. Ihr kennt Code Red und Kita, die Würmer. Und da hat man also Windows 2000 mit IIS installiert. Und wenn man den mit Internet verbindet, um die Patches runterzuladen, dann ist man schon infiziert. Und das hier sieht so ähnlich aus. Aber es ist viel schlimmer, weil es ein Sicherheitsnetzwerk Device ist, was man ganzes Netzwerk kontrollieren soll. Also hier sind meine Statistiken. Also keiner von den Herstellern hat aktuelle Version, entweder bei Amazon oder im Internet. Aber es ist auch sehr interessant, wenn wir uns die Geschichte aus Sicherheitsforschern und versuchen, wenn wir nach der Responsible Disclosure, also nach Responsible Disclosure veröffentlichen, haben einige, wenn da auch gefunden haben, dass es die Leute, die das einsetzen, auch kommuniziert bekommen, wenn da Sicherheitslücken kommen. Und sie müssen auch irgendeinen Incidents-Response-Team haben. Aber als wir versucht haben, unsere Unsicherheiten dort hinzuschicken zum Verkäufer, haben wir keine E-Mail-Adresse von diesem Incident-Response-Team gefunden. Das heißt, sie scheint nicht zu existieren. Wir haben versucht es bei Google zu finden, keinen Erfolg. Wir haben Leute gefunden, die ähnliche Forschung zuvor gemacht haben. Und wir haben einen super Weg gefunden, sendet eine E-Mail zum CEO der Firma, also technischen Leiter der Firma. Ich habe leider die E-Mail-Adresse von ihm nicht gefunden, aber ich habe die Tube auf LinkedIn gefunden. Und er hat innerhalb von ein paar Minuten geantwortet und hat mich in Kontakt hergestellt. Das heißt, wenn ihr SDN-Sicherheiten findet, schickt es am besten direkt an den CEO. Wir haben hier unterschiedliche Tabelle mit unterschiedlichen Arten, wie sie mit Wissenschaftler, Forschern kommunizieren. Cisco und Citrix waren nicht so schlecht, aber die ganzen anderen waren Anfänger. Das ist meine Lieblings-E-Mail. Von dem einen Verkäufer, der ihm gesendet frecht haben, fragen sie uns, warum wir diese E-Mail über Gmail senden. Haben wir eine offizielle Idee? Wollen sie einen Ausweis haben von uns? Die Frage ist, sie scheinen Angst haben, dass sie kein Internetzugang haben. Um zu verstehen, wie das funktioniert mit SDN haben wir eine Reihe von Skripten erstellt, die auf den unterschiedlichen Such-Enschen funktionieren. Wir haben N-Map versucht und Lua-Skripting benutzt, um verschiedene Software-Define-Networking-Solutions zu finden. Wir haben ein Paper veröffentlicht und haben aufgelistet, welche und wo sie existieren. Wir haben diese wunderschöne Karte generiert, wenn man auf dem Cost-Communication-Congress veröffentlichen kann. Was wir herausgefunden haben, sind gar nicht so viele SDN-Geräte im Internet. Wir haben 3.000 Management-Interfaces, die bekannte Vulnerabilities beinhalten, die man schnell und einfach finden kann. Außerdem haben wir ein paar Vulnerability-Assessment-Werkzeuge geschrieben, die uns dabei helfen, bekannte Vulnerabilities in Software-Define-Networking-Geräten zu finden, wie z.B. SSH-Patch-Level, wie bekannte Unsicherheiten von 2014 und 2016. Das ist alles open-source, ihr könnt es auf GitHub finden. Wir haben 2 Versionen, das eine ist die SDN-Harvester, das ist Erntar, der Google, Showdown und in Internet-Census benutzt, um über das gesamte Internet-Sache zu finden. Außerdem ist der SDN-Infiltrator eine Reihe von N-Maps-Scripts, das kann man im Penetrations-Test benutzen, das heißt, man muss gar nicht im Internet sein, man kann einfach in dem Netzwerk ausführen. Wenn wir diese Forschung durchgeführt haben, haben wir auch einen interessanten Artikel gefunden über das Dark Web-Markt, wo die schlechten Menschen Benutzernahme und Passwörter zu unterschiedlichen Netzwerker-Appliances verkaufen. Ein paar IP-Adressen, die wir unseres Assessments gefunden haben in dieser Liste. Wir vermuten, dass es keine Situation gibt wie Glück. Wir wissen jetzt, warum sie so einfach gehackt werden können und außerdem sind die Standard-Passwörter, die fest darin einprogrammiert sind und teilweise werden sie nie geändert und sie wurden hier benutzt. Wir haben versucht Verkäufer zu finden, Hersteller zu finden und gesagt, vielleicht ist das eine schlechte Idee, so Standard-Passwörter zu verwenden und öffentliche Sachen, die ein Leser schreibt, zu dem haben bei SNP. Aber die sagen, SNP ist aus, aber wenn wir kurz nachgeschaut haben über Shodan, gibt es mehr als 200 Software-Defined Networking-Geräte, die diesen Zugang geöffnet haben mit dem Standard-Passwort. Wir haben eine Reihe von Werkzeugen, die wir auf unserem Github veröffentlichen und wenn ihr was findet, könnt ihr das auch hinzufügen. Viele Sachen müssen noch gemacht werden. Wir brauchen neue Fingerprints, also Fingerabdrücke für neue Software-Defined Networking-Geräte und außerdem brauchen wir noch eine spezielle CCC-Veröffentlichung. Wir werden Metasploit-Module für SPNs veröffentlichen. Wir haben öffentliche Angriffsmethodik, Beschreibung und zum Schluss von mir aus, wie funktioniert das. Irgendjemand kann diese tolle Idee, lasst uns einen SDN schreiben, weil wir glauben, das wird super sein, künstliche Intelligenz in der Cloud auszuführen. Das heißt, wir laden viele Open Source Produkte herunter, packen sie zusammen und nach einer Zeit verkaufen. Das ist SDN. SDN ist eine Grande Zusammenung von Quellen auf den Geräten. Das ist gut, das ist nicht schlecht, aber man muss sich trotzdem darum kümmern. Man muss Patches installieren, man muss auch richtig konfigurieren, man muss es aufrechterhalten. Diese komplexen Produkte haben Probleme mit Patches, haben häufig viele Management-Interfaces, die Maschinen-Maschinen-Interfaces oder Mensch-Maschinen-Interfaces. Es gibt viele hart kodierte Passwörter und Zertifikate. Es gibt viele Probleme mit Patches und Sponsore mit der Cloud. Wenn ihr SDNs benutzen wollt, versucht es zu hacken. Oder ihr werdet einfach scheitern. Vielen Dank für eure Aufmerksamkeit. Ich möchte einen großen Applaus zu den ganzen Teams geben. Dennis, Maxim, Nikolai, Nikita, Alec und Anthony. Ich bin nur der Redler dieser Gruppe. Vielen Dank. Willst du was? Du machst die Antworten. Wir haben jetzt noch 14 Minuten für Antworten. Könnt ihr die Regeln? Bitte geht zu den Mikrofonen um die Fragen zu stellen. Es gibt irgendwelche Fragen. Neben Standardangriffen, die jeder Linus haben kann. Bei Web-Interfaces und SSH habt ihr spezielle Sicherheitsprobleme angeschaut. In Kapsulationen von Tunneln oder so was. Es gibt keine Technik und Technologie wie SD-Warn. Es werden Protokollen, die von verschiedenen Herstellern wieder genutzt. Aber in SD-Warn macht jeder das selbst. Das Citrix Management Protocol. Wir haben tatsächlich was gemacht. Das haben wir noch nicht publiziert. Wir haben die Virtualisierung angeschaut. Es ist sehr interessant. Wenn ich ein Problem in irgendeiner von den virtuellen Funktionen habe, dann kann ich damit auf die anderen Maschinen kommen. Aber das Problem ist, dass es keinen Standard gibt. Im unterschiedlichen Hersteller machen VNF in unterschiedlichen Arten. Ihr sagt, weil jeder seinen eigenen Code schreibt, wird es viele Baxeln. Ja, das sieht so aus. Es reicht nicht, der durchzuschicken, sondern man muss das schon hacken und anschauen. Eine Frage ist einfach, wie ist es mit Juniper, der im Software define Networking? Das wissen wir noch nicht. Ich freue mich, das näher anzuschauen, wenn da ein gutes Ergebnis kommt. Viele von den Geräten hatten ein härtetes Linux. Welches benutzen Sie und welchen Patch-Level haben Sie? Sind Sie immer noch 2,6 oder etwas Neueres? Nicht immer 2,6, das war das schlimmste Beispiel. Einige sind Neuer. Für die Netzwerkfunktionen Virtualisierung haben VNF runtergeladen und ein paar Skripte runtergeladen, bis die Konfiguration geändert hat, um das VNF zu nennen. Andere haben neuere Versionen verwandt. Und das Härten des Linnungskönnels, wie wurde das durchgeführt? In den meisten Fällen ist da nichts irgendwie gesichert worden. Noch eine Frage, habt ihr in Cisco Molaki euch näher angeschaut? Nein, lasst mich die Liste finden. Da haben wir Viptela bei Cisco angeschaut. Habt ihr die Frage aus den 90ern, dass die 90er ihrer fest einprogrammierten Passwörter wiederhaben wollen? Ja, ich weiß nicht genau. Wir haben noch ein paar Minuten übrig, aber wenn es keine Fragen mehr gibt, dann bitte ich hier einen Applaus für Sergey und sein Team.