 Hallo, ich begrüße euch hier so den Datenspiel im kleinen Saal. Gleich hören wir Simon und Cookie, die neue Werkzeuge für moderne Netzwerksicherheit sprechen werden. Ich bitte euch mal einen warmen Applaus. Ja, danke. Was wir heute ein bisschen machen wollen, ist, wir wollen euch beibringen und zeigen, was Paketfilter sind und sichere Netzwerk-Tunnel und das Ganze anhand von modernen Sachen, also von WireGuard und NF-Tables, das sind so die aktuellen Lösungen, die man nutzen sollte. Und dafür fangen wir erst ein bisschen an, gehen wir ein bisschen zu einem, was wollen wir eigentlich verteidigen? Dann erzähle ich was zur Paketfiltern und dann erzählt Cookie was zu den sicheren Netzwerk-Tunnel. Fangen wir gleich an. Erst einmal Einführung, was wollen wir eigentlich verteidigen? Es geht ja um Netzwerksicherheit und darum, was alles im Netzwerk als Bedrohung existiert. Also was können Angreifer mit unserem Netzwerk-Traffic machen, was können die an Informationen klaren, was können die mit unseren Paketen machen. Und da gibt es mittlerweile relativ viele Akteure, wenn man heute zum Beispiel irgendwie Anwendung hat, die in der Cloud laufen. Da hat man ja das Problem, da hat man zum einen halt den Cloud-Provider, den Internet-Service-Provider, der einem irgendwie das Kabel stellt und den Datenverkehr hinbuxiert. Und dann auf der Cloud läuft dann noch der Service-Provider, der den Service bereitstellt, den wir abrufen wollen. Und dazwischen hängen dann vielleicht noch irgendwie so Sachen wie Peeringknoten und so weiter. Das heißt, es sind sehr viele Akteure da im Netzwerk, die irgendwas mit dem Netzwerk-Traffic machen können. Und dann geht es darum, was kann man tun, um böswildige Akteure auszusperren. Genau, und jetzt zu den Schutzzielen. Was will man eigentlich erreichen? So die klassischen Schutzziele sind die CIA-Triade. Zu Deutsch, Vertraulichkeit, Integrität und Verfügbarkeit. Vertraulichkeit beschreibt das, dass man, wenn man Daten hat, möchte man nur, dass nur Personen zugreifen können oder Systeme, die auch autorisiert sind. Das heißt, wenn irgendjemand nicht autorisiert ist, soll der meine Daten nicht lesen können. Dann haben wir Integrität. Das bedeutet, dass die Daten nicht verändert werden können, ohne dass wir das mitkriegen. Wenn jetzt Daten im Netzwerk übertragen werden, dann kann irgendjemand hingehen und das Paket einfach umschreiben. Das kann man nie ganz verhindern, weil das Paket ist nicht mehr physisch bei uns und wir können das nicht mehr kontrollieren. Aber wir wollen es zumindest mitkriegen, dass sich das Paket verändert hat. Und dann gibt es auch die Verfügbarkeit von den All-of-Service-Angriffen, habt ihr vielleicht schon mal gehört. Das heißt, wenn ein System nicht verfügbar ist, weil jemand das angreift, weil jemand so viel Traffic hinschickt, dass man es nicht mehr benutzen kann, dann ist die Verfügbarkeit angegriffen. Und dann gibt es noch weitere Ziele, dass die Authentifizierung, da möchte man feststellen, welche Identität hat ein System. Das ist dahingehend wichtig, dass man quasi jeder behaupten kann, er ist ein bestimmter Dienst oder bestimmte Person. Und mit der Authentifizierung wollen wir feststellen, dass er wirklich auch diese Person ist. Das heißt, wir wollen seine Identität überprüfen. Und bei der Autorisierung geht es darum, dass wenn wir jetzt wissen, okay, das ist Person X, das haben wir überprüft, dass wir kontrollieren, okay, Person X darf auch wirklich auf diese Daten zugreifen, oder auf diesen Dienst oder auf dieses Netzwerk. Und das wollen wir damit sicherstellen, dass Autorisierung. Jetzt zum Angreifer. An sich sind Angreifer durch vier Dinge meistens definiert. Das sind Ressourcen, Zugriff, Verhalten und Vorhaben. Die Ressourcen sind Dinge so, was wie Zeit, Geld, Rechenpower. Dann haben wir den Zugriff, also auf welche Systeme hat der Angreifer Zugriff. Im Netzwerk ist das jetzt zum Beispiel, hat der Kontrolle über den ganzen Netzwerkfahrt zwischen zwei Systemen. Oder ist das nur ein Endpunkt, der nur selber Pakete schicken kann. Das heißt, hier hängt viel davon ab, an welcher Stelle der Angreifer sitzt und auf wie viele Teile des Systems der Angreifer zugreifen kann. Dann haben wir noch das Verhalten. Das kann entweder aktiv oder passiv sein. Wenn man zum Beispiel den BND-Nähmende am D-Kicks, den ganzen Datenverkehr mitliest, das ist ein passiver Angreifer, der verändert die Pakete jetzt erstmal nicht, der schreibt die sich nur alle auf. Aber man kann natürlich auch Pakete einfach verändern oder selber böswillige Anfragen stellen. Dann ist das natürlich ein aktiver Angriff. Und dann gibt es noch so was wie das Vorhaben. Was möchte der Angreifer denn eigentlich am Ende erreichen? Möchte er jetzt den Dienst sabotieren? Möchte er irgendwelche Daten klauen? Möchte er die Nutzer angreifen? Über diese vier Dinge kann man den Angreifer definieren. Dafür haben wir jetzt zwei Angreifertüpen für unseren Vortrag. Das eine ist der böswillige Kleint. Das ist einfach ein Endpunkt, der versucht, das Netzwerk auf einem System zuzugreifen und dort Daten zu klauen. Der gibt es im Internet relativ viele von. Und dann haben wir noch ein Man in the Middle-Angreifer, der sitzt zwischen zwei Systemen. Im Netzwerk-Kontext sieht das dann so aus, zum Beispiel der Internet-Service-Provider und als einen Peering-Noten, der zwischen zwei Systemen im Netzwerk steht und dort den ganzen Netzwerkverkehr mitlesen kann. Und durch seine Position im Netzwerk hat er viel mehr Zugriff als jetzt der bösartige Kleint. Und kann dann mit Datenpakete verändern, kann sie wegschmeißen, kann sie später zustellen, kann Datenpakete kopieren oder auch direkt lesen. Und durch seine Position hat er natürlich viel mehr, kann viel mehr angreifen. Und jetzt werde ich zuerst was zu Paketfiltern erzählen. Die benutzt man eher, um einen bösen Endpunkt abzufangen. Und für den Man in the Middle stellen wir euch gleich noch sichere Netzwerk-Tunnel vor. Und das erste Konzept, was man bei Paketfiltern kennen muss, ist, dass man, wenn man so ein Filter einsetzt, dann funktioniert das nur, wenn man sich zwischen zwei Systeme stellen kann. Das heißt, Paketfilter ist an sich dafür da, bösartige Pakete wegzuwerfen. Und das funktioniert nur dann, wenn man zwischen zwei Systemen stehen kann. Man kann auch, das heißt jetzt nicht, dass man unbedingt ein Netzwerk dazwischen braucht, es kann auch zum Beispiel sein, dass man selbst ein Paketfilter implementiert, um bevor die Pakete zugestellt werden, diese Pakete inspiziert und wegwerfen kann. Aber an sich hat man halt immer diese Zone-Einteilung, das was Netzwerkisolationen schreibt. Und dann kann man zwischen diesen Zonen regulieren, was für Netzwerkverkehr erlaubt ist und was nicht. Genau, jetzt zu Paketfiltern. An sich sind die super einfach. Wir haben eine Liste an Regeln, was erlaubt ist und was nicht. Jetzt die rechts, man kann es einfaches Beispiel, wir wollen jetzt keinen SSH-Traffic haben, also sperren wir Port 22, wir wollen nur aus einem bestimmten Netzwerk, also aus einem bestimmten Netzwerkbereich, Traffic bekommen und wir wollen auch, dass kein Port 21-Traffic kommt. Und damit können wir schon ganz einfach bestimmen, welche Pakete wegzuwerfen sind. Da gibt es zwei grundlegende Ansätze, das eine ist das Blacklisting. Das heißt, beim Blacklisting schreiben wir einfach auf, welche Pakete sind verboten. Hat den Vorteil, dass das erst mal relativ einfach ist und dass wenn ich meinen, ich nicht genau wissen muss, erst mal welcher Traffic normal durchfließt, sondern ich muss nur wissen, okay, ich will zum Beispiel für einen bestimmten Port keinen Traffic haben, dann kann ich ihn sperren. Beim Whitelisting ist genau andersrum. Anstatt zu definieren, was verboten ist, definieren wir was erlaubt ist. Das hat den Vorteil, dass wenn wir jetzt zum Beispiel vergessen haben, einen bestimmten Port zu sperren, den wir eigentlich sperren wollten oder wir haben irgendwelchen Traffic noch nie gesehen, der jetzt vom Angreifer kommt, ist er auch automatisch gesperrt. Ist aber ein bisschen unflex lieber, denn wenn wir jetzt einen Dienst betreiben oder halt unseren Heimrouter, müssen wir alle Verbindungen an sich kennen vorher, die wir erlauben wollen, weil wir müssen eine explizitere Regel schreiben, die diese Pakete erlaubt. Das sind so die zwei grundlegenden Ansätze. Whitelisting ist erstmal in der Regel ein bisschen sicherer, weil man halt auch Angriffe dabei hat, an die man nicht gedacht hat. Blacklisting ist dafür ein bisschen flexibler. Dann ein bisschen was zu den Regelsets. Das worüber ich jetzt erstmal geredet habe, ist, dass man Pakete daran anhand dessen, was sie enthalten, wegwerfen kann. Also wenn jetzt Port 22 drin ist, dann steht das auch im Paket. Aber man kann auch Stateful Filtering machen. Das bedeutet, dass man sich vorher aufgeschrieben hat, zum Beispiel, welche Verbindungen existieren bereits. Also wir können uns zwischen Systemen merken, wer redet mit wem und können dann daran filtern. Das heißt, wir schreiben uns ein Status auf, wir schreiben uns auf, wer mit wem reden darf. Das wird beim sogenannten Connection Tracking gemacht. Beim Connection Tracking haben wir jetzt hier links eine Kommunikationsbeziehung zwischen Akteuren. Zum Beispiel Alice und Bob reden miteinander. Und Alice versucht mit Sabine zu reden und Sabine mit Bob. Und dann schreiben wir uns dazu in einer großen Tabelle auf, wer mit wem reden kann. Und zwar auch die Richtung. Also, dass zum Beispiel Alice mit Bob redet und auch Bob mit Alice. Und zu jedem Status können wir, zu jeder Verbindung schreiben wir uns dann noch auf, in welchem Zustand die sind, wer zum Beispiel TCP kennt. Da gibt es ja auch verschiedene Zustände, in denen der Verbindung sein kann. Das wird damit aufgeschrieben. Und anhand dieser Zustände kann man dann auch am Ende filtern. Das heißt, ich kann am Ende eine Regel schreiben, die sagt, okay, wenn zum Beispiel Alice Sabine kontaktiert hat, dann darf Sabine auch antworten in dieser Verbindung. Aber Sabine darf jetzt keine neuen Verbindungen zu Alice aufbauen. Das heißt, man muss wissen, welche Pakete vorangegangen sind, um filtern zu können. Das führt dazu, dass man halt sehr viel State aufschreiben muss, also sehr viel Zustand. Was dazu führen kann, dass dieses Connection Tracking oft Performance-Bottleneck für Paketfilter wird. Wenn man nur statische Regeln hat, das ist meistens relativ einfach. Dann hat man nur seinen Regel-Set. Wenn das jetzt nicht zu groß wird, dann ist das noch in Ordnung. Aber halt bei diesem Dynamischen, wenn man sich merken muss, wer mit wem redet, kann der State relativ schnell sehr groß werden. Jetzt ein bisschen was zur Implementierung. In der Regel wird halt ein Paketfilter mit dem Netzwerk-Stack verbunden, weil wir möchten ja im Netzwerk-Stack irgendwie Pakete filtern. Früher hat man das so gemacht, dass man feste Implementierung pro Protokoll hatte. Also zum Beispiel eine Implementierung für das IP-Protokoll 4. Für ARB, für IP6 und so weiter. Heute macht man das ein bisschen anders. Heute ist man ein bisschen generischer unterwegs. Da hat man eine kleine In-Curnal-VM. Das ist eine kleine bürterische Maschine. Jetzt erzähle ich gleich noch was. Und die kann generisch filtern. Das Problem ist bei diesen alten Tools, ist, dass man halt für jedes Protokoll, das man filtern wollte, musste man auch im Kernel eine neue Implementierung haben für dieses Protokoll. Die waren meist relativ ähnlich, weil Pakete sind jetzt nicht so groß unterschiedlich. Allerdings, dadurch, dass man dann viele Implementierung hat, hat man einen hohen Aufwand, das alles zu warten und zu verändern. Heute macht man einen etwas generischen Ansatz. Und neben diesem Kernel-Modul hat man dann noch im User Space eine Utility, in der man dann seine Regelzeit eingibt. Und diese Utility übersetzt das Regel-Z und programmiert dieses Kernel-Modul damit. Bei der Kernel-VM sieht das dann etwa so aus. Wir haben halt eine ganz einfache Regel, zum Beispiel, dass das TCP-Port gleich 10 ist. Dann wollen wir akzeptieren. Und daraus wird dann heute richtiger Code erzeugt. Das heißt, an sich wird der Kernel dynamisch programmiert, allerdings in einer sehr eingeschränkten Art und Weise. In der Regel, dadurch, dass man dann im Kernel Code ausführt, ist das erstmal ein Sicherheitsproblem, wenn man nicht reguliert, was dieser Code machen kann. Bei den Paketfilter, vor allem ist das so, dass sie halt nicht beliebig viele Instruktionen haben dürfen. Es dürfen zum Beispiel keine Schleifen vorkommen. Und es sind auch nicht alle Kernel-Aufrufe erlaubt, um so zu verhindern, dass das Programm irgendetwas Bösartiges tun kann. Und es wird auch in einer bestimmten Zeit abgeschossen, wenn das so lang läuft. Und dadurch hat man halt einen sehr kleinen Computer quasi im Kernel, den man programmieren kann mit seinem Regel-Z. Da fällt dann halt so das assembly-artiges raus. Früher wird das interpretiert, und heute wird es dann auch direkt auf der CPU ausgeführt. Das ist ein sehr schnellen Filtermechanismus, der generisch ist, weil diese Art und Weise zu filtern, ist nicht an einem Protokoll gebunden, sondern kann beliebig erweitert werden. Man braucht nur eine User-Space-Utility, die für das entsprechende Protokoll den Bytecode erzeugt, und damit das Kernel-Modul programmiert. Genau. Jetzt, wo kann man eigentlich filtern? Im Netzwerk-Stick gibt es sogenannte Net-Filter-Hooks. Das sind Punkte, an denen man in den Netzwerk-Paket eingreifen kann, um ihn zu verändern. Ganz links, da haben wir das erste Mal, dass das Paket angekommen ist. Ingress ist ganz früh. Als es noch bevor das Paket komplett gepasst ist, da hat man auch noch nicht alle Informationen über das Paket. Das ist ein sehr früher Punkt. Der ist zum Beispiel dafür interessant, wenn man den Isle of Service-Angriff kriegt. Jemand schickt einem ganz viele Pakete, die man nicht möchte. Dann möchte man so früh wie möglich filtern und die Pakete wegschmeißen. Bei Pre-Routing, das ist der Punkt, bevor man eine Routing-Entscheidung getroffen hat für das Paket, und bevor das irgendwo zugestellt wird, dass der Punkt ist vor allem interessant, wenn man natten möchte. Dann kommt halt eine Routing-Entscheidung und dann wird erstmal entschieden, okay, muss das Paket jetzt an einen lokalen Prozess zugestellt werden oder wird es an anderen Computer weitergeleitet? Wenn es jetzt an einen lokalen Prozess geht, dann geht es in Input. Wenn es weitergestellt wird an irgendein anderen Computer und unser PC als Router fungiert, dann wird es gefordert. Und dann gibt es nach mal nach dem Routing-Prozess Output und Post-Routing. Output sind halt die Pakete, die von lokalen Prozessen kommen. Und Post-Routing sind dann alle Pakete, die schon geroutet wurden. Jetzt ein bisschen konkreter zu NF-Tables. Bei NF-Tables hat man im Vergleich zu früheren Paketfilter-Möglichkeiten wie IP-Tables eine sehr einfache Sintax. Also man kann das relativ gut lesen. Man kann halt generisch filtern, wie gerade schon angesprochen, dadurch, dass man eine VM hat. Mittlerweile kann man tatsächlich auch so Sachen machen wie diesen Paketfiltercode auf die Netzwerkerharte auslagern, das ist mittlerweile auch im Kernel. Dann hat man nativen Support für Maps. Das musste man früher bei IP-Tables immer nachladen. Maps sind Konstrukte, wo man ganz viele Regeln haben kann, die alle auf dasselbe matchen. Ich möchte jetzt nur die IP-Adresse kontrollieren. Dann habe ich ganz viele Regeln untereinander, die die IP-Adresse kontrollieren. Die kann man sehr effizient als Hash-Tables implementieren. Sie sind auch nativ in NF-Tables mit drin. Dann ein wichtiger Vorteil ist, dass man IPv4 und IPv6 zusammenfiltern kann. Was man bei IP-Tables, was so, wenn man jetzt sein Regelset für IPv4 geschrieben hat, was viele Leute gerne vergessen, ist, man muss das ganze Regelset auch noch mal für IPv6 schreiben. Denn IP-Tables macht nur v4. Bei NF-Tables kann ich einfach eine Tabelle anlegen, die beides filtert. Und dann werden die Regeln dementsprechend, ob es jetzt gerade nur v4 matched oder nur v6, oder ob es auf beides matchen kann. Und dann kann man ganz einfache Traffic-Shaping-Optionen machen. Wenn man zum Beispiel möchte, dass eine Verbindung gedrosselt wird oder dass man nur bestimmt viele Pakete erhält, dann kann man das auch mit NF-Tables mittlerweile nativ machen. Da braucht man auch vorher noch extra Programme für. Jetzt zur NF-Tables-Sabest. Die größte Einheit in NF-Tables ist eine Tabelle. Tabellen sind immer nach Protokoll-Familien sortiert. Also ich kann zum Beispiel eine für IPv4 haben, eine für v6, eine kombinierte Tabelle oder für ab. Und in der Tabelle gibt es dann sogenannte Chains. Chains sind an sich Listen an Regeln, die von oben nach unten abgearbeitet werden. Und wenn ich jetzt diese Chains mit einem dieser Punkte verbinde, also diesen NF-Hooks, dann wird das eine sogenannte Base Chain. Base Chains sind deswegen nochmal ein bisschen anders, dass wenn ich Pakete jetzt reinnehme in diese Chain, brauche ich immer eine Default-Regel. Also wenn ich Pakete habe und keine meiner Regeln matcht, also keine meiner Regeln sagt mir, wird das Paket jetzt weggeworfen oder behalten, dann muss die Chain am Ende noch eine Default-Regel haben, die sagt, okay, es wird jetzt behalten oder verworfen. Und halt in diesen Chains stehen dann Regeln, zu denen jetzt ein bisschen mehr. Regeln sind so aufgebaut, wir haben immer Expressions und Statements, Expressions beschreiben etwas, was das Paket sein soll. Zum Beispiel hier ist die erste Expression sagt, dass die Source-Adresse 127001 sein soll. Und die zweite Expression sagt, und das TCP, der TCP-Port, an den es gerichtet ist, das Paket soll die 22 sein. Und wenn beide dieser Expression zu stimmen und wahr sind, dann werden die Statements, die dahinter sind, ausgeführt. Bei Statements gibt es non-terminale Statements, die greifen nicht direkt in den Paketfluss ein, sondern die machen nur so etwas wie zum Beispiel aufschreiben, wie viele Pakete durchgegangen sind, zu loggen, zu markieren. Da kann man beliebig viele von diesen non-terminal Statements haben. Und dann am Ende gibt es immer noch einen terminal Statement, was sagt, was wird denn jetzt eigentlich mit dem Paket gemacht? Zum Beispiel, dass es verborfen wird hier wie in dieser Regel. Oder accepted. Oder man kann auch Pakete in andere Chains transportieren. Genau. Jetzt so eine Tabelle sieht so aus. Jetzt haben wir erstmal aus und rum die Table INET Filter. INET ist der Pakettyp für IPv4 und IPv6. Und die Filter ist halt einfach der Name, den wir den Tabelle gegeben haben. Dann haben wir da drin eine Chain, die heißt Input. Und das ist eine Basechain. Das sehen wir halt an diesem etwas längeren Konstrukt hier oben. Sagt nämlich am Anfang erstmal, was das für ein Typ ist für eine Chain. Die soll jetzt filtern, deswegen ist das eine Filterchain. Dann haben wir den Hook, an dem wir die verbunden haben. Das ist der Input-Hook. Und eine Priorität. Wir können mehrere Chains haben, die mit demselben Hook verbunden sind. Und die Priorität bestimmt dann am Ende, in welcher Reihenfolge die ausgeführt werden. Und dann haben wir am Ende noch die Default-Policy, was passiert. Wenn keine der Regeln zutrifft, in dem Fall akzeptieren wir einfach das Paket und leiten es weiter. Und dann haben wir da drunter eine Regel stehen. Die sagt jetzt einfach, dass wir, wenn wir ein TCP-Paket haben, das an Port 22 adressiert ist, dann möchten wir zuerst zählen, dass dieses Paket hier durchgekommen ist und danach möchten wir das Paket wegwerfen. Das heißt, an sich filtern wir an der Stelle SSH. Genau. Und Dominik, erzähl doch jetzt noch was zu sicheren Netzwerk-Tunneln. Kommen wir zum zweiten Teil zu den sicheren Netzwerk-Tunneln. Erst mal grob die Motivation. Und was geht es eigentlich? In diesem Falle, in unserem, also wir hatten ja vorhin zwei Angreifermodelle kennengelernt. Und in dem Fall konzentrieren wir uns auf den mehrenden Mittel. Das heißt, wir haben jemanden, der zwischen zwei Endpunkten, die wir, zwischen dem wir Daten austauschen wollen, irgendwo auf der Leitung sitzt und halt den Traffic mitlesen kann oder sogar verändern kann. Das heißt, unser konkretes Ziel für sichere Netzwerk-Tunneln ist eben eine Möglichkeit zu haben, eine sichere Übertragung oder der Schutz der Daten zu gewährleisten bei der Übertragung. Und wir konzentrieren uns darauf, dabei auf die vier Ziele, Vertraulichkeit, Integrität und Authentizität, was also heißt, nur meinen Empfänger darf lesen. Und ich muss überprüfen können oder erkennen können, ob eine Modifikation stattgefunden hat und Authentizität eben die Überprüfung der Identität, also dass ich sicherstellen kann, dass mein Gegenüber derjenige ist, der sich halt ausgibt zu sein. Genau, sichere Netzwerk-Tunnel, so vom Prinzip her funktioniert es meistens so, dass die einen Paket, was ich gerne irgendwo an das hin schicken möchte, neben es nochmal einpacken, ja, mit Verschlüsselung versehen, mit einer Prüfzumme versehen und dann eben dieses ganze Paket zu meinem Empfänger senden und der packt das dann wieder aus und überprüft es und so weiter. Er hat den Geheimen Schlüssel und über diese Zusammensetzung kann man eben dann einen sogenannten, also diesen Tunnel eben erstellen und die Idee zum Beispiel für VPNs, das ist ja so der gängigere Begriff, also die Virtual Private Networks, ist eben, dass man zum Beispiel zwei Netze miteinander verbindet, die zum Beispiel übers Internet geroutet werden. Das heißt, ich richte es so ein, dass in meiner einen LAN Area zum Beispiel ein Router steht, der versteht, dass wenn ich Pakete in ein anderes LAN schicke, was über das Internet verbunden ist, dass diese Pakete automatisch transparent verschlüsselt und mit einem Mac-Tag versehen werden und auf der anderen Seite werden die dann ausgepackt, überprüft und so weiter und so kann man dann transparent zwei Netze über einen unvertrauten Kanal miteinander verbinden. Genau, ich hatte jetzt die drei Schutzziele genannt, auch schon mit der Mac zum Beispiel und eben diese Incapsulation sieht so aus, also wenn wir in ein Paket senden, zwei Rechner, die miteinander kommunizieren wollen und der Kanal in der Mitte ist zum Beispiel ein ungeschützter Kanal und was die beiden dann machen, ist eben, sie etablieren einen geschützten Kanal miteinander, sind damit direkt miteinander verbunden und sie haben sowohl ihre Public IP, also die 172er in dem Falle, die öffentlich erreichbar ist, aber auch eine private IP, die es nur in diesem virtuellen Netzwerk gibt, also nur in diesem Tunnel gibt, die jeweils den beiden PS gehört und mit denen sie sich dann identifizieren und Pakete roten können und was die beiden jetzt machen würden, wenn sie also über diesen verschlüsselten Kanal miteinander kommunizieren möchten, ist eben, der Linke würde zum Beispiel ein Paket dann an die 192.168.02 schicken, der Kanal würde das verstehen, würde das Paket eben einpacken, also das wäre dann eben dieses innere Paket, das wäre verschlüsselt und zu der Verschlüsselung gehört dann noch eben dieser Mac-Tech, dann erzähle ich gleich noch mehr zu das Paket, was dann tatsächlich über den Kanal geht, was über das Internet geschickt wird, ist dann das Paket, was durch den äußeren Layer noch ergänzt wird und so haben wir das inkapsulierte Paket in der Mitte und das wird dann von der 172er an die 02 geschickt, zum Beispiel. Das heißt, der man in der Mitte auf der Connection sitzt, also in der Mitte das Paket sehen kann, der könnte sehen, der wird jetzt in ein Paket geschickt von der 172.01 zu der 02, aber er könnte nicht sehen, was drin ist, weil es nur verschlüsselte Daten sind. Genau, und wir hatten drei Ziele formuliert, also die Vertraulichkeit, die Integrität und die Authentizität, aber wie funktioniert das eigentlich? Also Verschlüsselung, wie funktioniert Verschlüsselung? Genau, wie funktioniert Verschlüsselung? Im Prinzip relativ simpel, wir haben also einen geheimen Schlüssel, und entschlüsseln wir. Und Sinn der ganzen Sache ist, dass es eben ein Algorithmus gibt, der beides unterstützt. Ich habe also einen Klartext auf der linken Seite, ich habe einen geheimen Schlüssel und gebe das in mein Algorithmus beides rein. In der Mitte kommt dann Ciphertext raus, also verschlüsselte Daten. Und wenn ich auf der anderen Seite das wieder in die Decryption Algorithmus reingebe, wieder mit dem Secret Key, kommt am Ende wieder der Klartext raus. Wichtig ist hierbei, wenn man gehaltet, sollte man sich immer daran orientieren, dass das Verfahren bekannt sein muss, also dass der Algorithmus öffentlich sein muss, öffentlich einsehbar sein muss, aber dass alleine die Geheimhaltung des Schlüssel ausreicht, um die Sicherheit der Verschlüsselung eben zu garantieren. Also wenn ihr irgendeinen Algorithmus findet, der sagt, der verschlüsselt und der funktioniert, weil er geheim gehalten wird, dann sollte man den nicht ganz so ernst nehmen. Genau, und zur Verschlüsselung gehören grundlegende Unterscheidungen, also zum Schlüsseltyp, zwei Unterscheidungen. Benutzten wir einmal symmetrische Schlüssel für AES, zum Beispiel, ist ein relativ bekanntes symmetrisches Schlüsselverfahren. Da gibt es nur einen geteilten Schlüssel, das heißt, alle Teilnehmer, die Textverschlüsselung und Entschlüsselung wollen, die haben einen einzigen Schlüssel und der Schlüssel wird sowohl für Verschlüsselung als auch für Entschlüsselung benutzt. Oder wir benutzen asymmetrische Schlüssel, das ist zum Beispiel im RSA-Verfahren, mit Key Exchange oder also ganz praktisch bei PGP, ist das ja genauso, da habt ihr so ein Public Key und Private Key und der funktioniert eben so, dass wenn jemand an jemand anderen etwas schicken möchte, dann kann er den Public Key dieses Teilnehmer eben nehmen mit diesem Public Key die Inhalte verschlüsseln, aber es ist nur möglich mit dem Secret Key, den nur der Empfänger hat, die Inhalte auch wieder zur Entschlüsselung. Zum zweiten Punkt, der Integrität, die MACs schon genannt, also MAC steht für Message Authentication Code, das funktioniert so, dass wir hatten vorhin diese vier Pakete gesehen, wir hatten in der Mitte die zwei, die verschlüsselt waren, also der Teil, der verschlüsselt war und den sogenannten MAC-Tact, der wird im Klartext übertragen und der setzt sich daraus zusammen, dass der Sender in der Nachricht aus der Nachricht und aus dem geheimen Schlüssel diesen Wert berechnet, also den Inhalt, also die Nachricht verschlüsselt und die Klartext MAC dazu zusammenpackt, das zusammen überträgt und auf der anderen Seite kann nach der Entschlüsselung der Nachricht eben das Gleiche wieder auf der anderen Seite gemacht werden und am Ende müssten dann beide MACs übereinstimmen, sonst könnte man sehen, dass zum Beispiel Inhalte modifiziert sind, dass zum Beispiel der MAC-Tact modifiziert wurde und dass der geschlüsselten Payload irgendwas gemacht wurde. Dadurch kann man also Integrität feststellen, ob Daten verändert wurden, aber man kann gleichzeitig auch dadurch, dass auf beiden Seiten mit dem geheimen Schlüssel gearbeitet wird, feststellen, dass die Daten, die von dem MAC-Tact signiert wurden, auch von der Person unterschrieben wurden, die gesagt hat, also von der wir ausgehen, dass es ist, weil sie muss ja genauso den geheimen Schlüssel gehabt haben, um die MAC zu berechnen. Dritter Punkt, Authentizität, ist bei asymmetrischen Schlüssel ein bisschen schwierig. Sehr viel einfacher bei asymmetrischen Schlüsselpaaren, weil wir dort den Public Key das gegenüber benutzen können, um eine Signatur zu überprüfen, die derjenige oder diejenige mit dem Secret Key an zum Beispiel einen Datensatz geengt hat. Also wenn ich ein signiertes signierten Datenblock bekomme, kann ich halt überprüfen, ob der diejenige, die es mir geschickt hat. Die Person ist von der ich denke, dass sie ist, indem ich den Public Key den bekannten Public Key benutze, um das eben zu überprüfen. Genau, sind wir durch die Theorie durch, kommen wir auch hier zu der praktischen Umsetzung in WireGuard. WireGuard ist ein relativ neues Projekt, erst seit 2015 in Entwicklung, hat aber extrem schnell Fahrt aufgenommen, weil die grundsätzlichen Ziele eine einfache Codebase und eine sehr einfache State Machine nennt man das, also einen sehr einfachen Ablauf der Algorithmen zu implementieren, sich sehr schnell, sehr weit verbreitet hat, also einen sehr großen Anklang gefunden hat. Der Auto spricht von ungefähr 4.000 Zellen Code, was im Vergleich zu mehreren 100.000 Zellen Code in anderen Protokollen ein betrachtlicher, beträchtlicher Unterschied ist. WireGuard benutzt asymmetrische Schlüsselpaare. Allerdings hat es kein integriertes Schlüsselmanagement, das heißt, man muss irgendwie einen anderen Kanal finden, um die Public Keys von seinen Piers zu kriegen, aber kann dann eben die Schlüsselpaare benutzen, um die vorangegangenen Punkte damit zu implementieren. Und vor allem die Geschwindigkeit die WireGuard erreicht bei der Übertragung von Paketen, die wird dadurch gewährleistet, dass es direkt von vornherein als Kernelmodule implementiert wurde. Ist also direkt am Netzwerkstack dran, muss nicht viel overhead durch Wechsel von Kontexten zwischen User Space und Kernel Space hinter sich lassen. Und WireGuard konzentriert sich auf den IP-Layer, macht also Encapsulation nur via UDP, packt also IP-Pakete, IPv4, IPv6-Pakete ein, verschickt die über UDP und packt sie auf der anderen Seite wieder raus. Genau. Zum Protokoll mal ein paar Stichworte benutzt Elliptic Curve, die vier Helmen für den Key Exchange um den Session Key um den Session Key zu etablieren. Implementiert Dinge wie Perfect Forward Secrecy, die ja eigentlich heute von Algorithmen selbstverständlich angenommen werden sollten und kann optional sogenannte Pre-Shared Symmetric Keys auch noch dazu benutzen, die davon ausgehen, dass wenn zum Beispiel jemand den Traffic mit schneidet und in ein paar Jahren oder hoffentlich längeren Jahren durch zum Beispiel, also bessere Computing Power den Traffic entschlüsseln könnte, dass der innerhalb der Session nochmal mit einem anderen Key nochmal verschlüsselt worden wäre und so man vor den nächsten Hürde stände, als wenn man direkt den Klartext erhält. Und ansonsten konzentriert sich WireGuard darauf, die neuesten oder die im Moment am aktuellsten gesehenen Cypher zu benutzen, also in dem Falle die Symmetischen Charger H20 Algorithmus zur Verschlüsselung und den Poli 1305 für die MAC Berechnung und Black2S für den Hashing Algorithmus. Also es sind alles sehr moderne sehr aktuelle Algorithmen von dem man denkt, dass sie im Moment halt die sichersten sind und die etabliertesten. Genau nochmal ein kurzer Blick in die Topologie. Ich hatte das vorhin mit dem Paket dargestellt, wie das funktioniert und mit dem virtuellen Interface. Ganz praktisch sieht es also so aus, wenn wir auf der linken Seite einen Rechner haben, auf der rechten Seite einen Rechner und in der Mitte sitzt unser mangelter Mittel auf dem Router. Dann wird das so funktionieren, dass die beiden haben jetzt hier ein physisches Interface, die es verbunden ist mit dem öffentlichen Netzwerk und jeder, also die beiden Piers, stellen jeder dann über WireGuard virtuelle Interfaces, die ich vorhin angesprochen hatte, diese zweite interne IP an. Wenn ich dann eine Applikation habe, die Daten über diesen verschlüsselten Tunnel senden möchte, dann schicke ich die jetzt zum Beispiel von hier aus an die 10.0010 und zu der 10.010 würde der jetzt hier den Public Key von den Piers kennen, würde dieses Paket verschlüsseln, den Tag dranhängen, würde das dann mit der Ziel-IP 192.168.110 eben auf dieses Interface geben, das würde geschickt, über UDP wäre eingepackt, würde auf der anderen Seite ausgepackt und so wäre dann die sichere Kommunikation zustande hergestellt, zwischen dem meine Applikation. Und einen großen Vorteil, den WireGuard auch hat, ist, dass der Autor WireGuard nicht nur im Kernel integriert hat, sondern auch in der IP im IP-Toolset. Also wenn ich zum Beispiel meine IP-Adresse aufnimmt, ich habe gleich noch ein Codebeispiel, dann kann ich das noch mal zeigen. Genau. Noch ein wichtiger Punkt, wenn man WireGuard benutzt, es gibt eben kein integriertes Schlüsselmanagement, das heißt ähnlich wie bei SSH, wenn ich mit jemandem über das Netz kommunizieren muss, ich kontrolliere aber den Endpunkt nicht, also ich kann das Interface nicht kontrollieren, dann brauche ich von der gegenüber liegenden Person den Public Key, muss mir jemand dann schicken zum Beispiel und ich füge ihn oder sie dann eben als Pier hinzu in meine Liste und erst dann kann ich dem gegenüber in die Kommunikation treten. Und der Austausch des Cyphers bei WireGuard bedeutet, dass man gezwungen ist, ein Versionsupgrade zu machen. Also wenn ich eine spezifische WireGuard-Version benutze, bin ich darauf festgelegt, eine gewisse Suite von Algorithmen zu benutzen und sollte später mal eine dieser Algorithmen ausgetauscht werden, muss man die Software upgradeen. Das ist bei anderen Software anders, wo man so Negotiation macht, man handelt beim Handshake also beim Anfang der Verbindung aus, welchen Algorithmen man benutzen möchte und so. Da sind sehr viele Dinge auch bei anderen Protokollen schon sehr schief gegangen und deswegen hat der Autor gesagt, das will er gar nicht erst einführen und hat sich darauf versteift, dass eben eine Version immer die gleichen Algorithmen benutzt. Und noch ein Feature an WireGuard ist das sogenannte Crypto Key Routing. Was bedeutet, dass die Zuordnung von IPs zu den Public Keys immer überprüft wird von WireGuard selbst. Das bedeutet, sobald ein Paket aus dem virtuellen Interface rauskommt ist sichergestellt, dass das Paket von dem oder der Absenderin geschickt wurde, von der man ausgeht, dass es die Person ist. Also die Zuordnung ist eben prognographisch nochmal gesichert und das kann man dann zum Beispiel nutzen, um gewisse Voraussetzungen oder gewisse Annahmen zu treffen, und dann Firewalling zum Beispiel darauf baut. Genau. Jetzt habe ich nochmal zwei Folien mit Code, damit ihr einfach mal ein Gefühl kriegt, was es bedeutet, WireGuard zu benutzen. Es ist durch die Integration in IP einfach total simpel einen WireGuard-Interface, ein virtuelles Interface anzulegen. Ich sage IP Link Add Type WireGuard. Da habe ich ein neues Interface. Ich sage, welche Adresse ich darauf haben möchte. Das ist dann diese Internet IP-Adresse. Wenn ich mir das dann angucke, dann sieht das so aus. Ich habe dann hier mein Loopback-Device. Ich habe mein öffentliches Ethernet, also Ether0 und eben das neue Interface mit der IP-Adresse. Und wenn ich das dann noch weiter konfiguriere, sage ich dann, habe ich dann ein Config File zum Beispiel und wenn ich dann WG Show mache für das Interface, habe ich mein Public, mein Private Key, mein Listening Port auf dem neue Verbindung reinkommen können zum Beispiel eine Liste von Piers. Also ich habe jetzt in dem Falle zwei Piers. Der eine Pier, der XTIB zum Beispiel, der kann jetzt von diesen IP-Adressen Pakete senden und der andere Pier könnte von der 230 zum Beispiel Pakete senden und bei dem ist zum Beispiel auch bekannt welchen Endpoints er hat. Also zu dem könnten wir uns zum Beispiel auch verbinden und ein Tunnel aufbauen, was bei dem anderen nicht möglich wäre, weil der von dem ausgegangen wird, dass er sich mit uns verbindet. Genau, wenn ich das Interface dann absetzen, so wie man es gängigerweise macht, dann ist das eben ab, kann Pakete empfangen und wenn ich dann meine die internal IP-Pinge von meinem Gegenüber, dann erreiche ich den über Ping. Genau, zusammengefasst, WireGuard hat sowohl Vorteile als auch Nachteile. Also Vorteile sind durch die Implementierung im Kernel. Das ist das ganze Ding einfach extrem schnell. Also es hat einen sehr hohen Durchsatz vor allen Dingen und man kann sicher sein, dass wenn man die neueste Version benutzt, dann sind auch da die Algorithmen, die Cyphers drin, die im Moment State of the Art sind, die man benutzen sollte, die kryptografisch am sichersten sind. Und durch die kleine Codebase ist die Verifikation, also die Überprüfbarkeit der Codebase sehr gut gegeben, was bei anderen dann eher schwierig ist. Und was die Nachteile angeht, es ist in größeren Setups ein bisschen schwierig, was die Skalierung angeht, weil wenn ich die PIR-Liste pflegen muss, dann kann ich zum Beispiel niemanden in meine PIR-Liste aufnehmen, von dem ich den Public Key nicht habe. Und es ist schwierig, also ich habe es in der Größenordnung von 10.000 Pirs noch nicht ausprobiert, aber ich stelle es mir relativ schwierig vor, da die Liste konstant aktuell zu halten, wenn ich ständig das Netzwerk halt dynamisch vor allen Dingen verwalten möchte, weiß man nicht genau, wie das skaliert. Und eine Problem, die die Hard-Codierung der Algorithmen mit sich bringt, ist, wenn zwei Rechner miteinander kommunizieren, die unterschiedliche Versionen haben, die zum Beispiel unterschiedliche Algorithmen benutzen, können die nicht miteinander kommunizieren, weil sie keine Möglichkeit haben, irgendwie was anderes auszuhandeln, irgendwie einen Kompromiss zu finden oder so. Also da, es sind wahrscheinlich gerade Legacy-Systeme, die zum Beispiel auf irgendeine Versionen gepinnt sind, so ein bisschen außen vor, muss man dann gucken, wie man damit umgeht. Genau. Endpages. Ja. Jetzt sind auf unsere Quellen mit drauf. Wir würden jetzt im Anschluss noch ein Workshop geben. Da haben wir ein paar Aufgaben dabei. Braucht nur ein Gerät, was sich SSH'n kann, damit ihr auf unsere Infrastruktur kommt. Und dann kann man da einfach ein bisschen mit WireGuard und NF-Tables rumspielen. Es gibt ein paar kleine Aufgaben, was zu konfigurieren und einfach mal Hands-on zu lernen, wie das Ganze funktioniert. Wenn jetzt noch Fragen sind, können wir Sie jetzt erstmal beantworten. Wir haben noch fünf Minuten. Genau, fünf Minuten für Fragen. Hi. Ich hätte eine Frage zur Kompatibilität von NF-Tables zu Docker. Ich habe mich mal versucht vor ein paar Wochen auf DBN10, was ja NF-Tables bei default mittlerweile ausrollt. So ein kleines Kubernetes aufzuziehen und da hatte ich Schwierigkeiten, dass man Docker-Container konnte nicht rausfunken. Jetzt weiß ich gerade nicht, ob es einfach nur an meiner eigenen Dummheit lag. Also quasi ein Layer-Aid-Problem. Oder ob es grundsätzlich eine Inkompatibilität ist, weil Docker ja ziemlich viel mit IP-Tables schmug macht. Also unser Workshop-Test setup läuft mit Containern, insofern das funktioniert. Ich weiß nicht genau, was bei dir kaputt ist. Es kann sein, Docker konfiguriert ja auch immer selbst noch IP-Tables-Kram. Es kann sein, dass man die Regeln noch mit drin standen, die dich zurückhalten. Also grundsätzlich sollte laufen. Grundsätzlich sollte laufen, ja. Sehr gut, danke. Ich benutze einer weilischen Viagart und auch in einem Privacy-orientierten VPN-Setting und da bin ich jetzt in letzter Zeit so ein bisschen ins Grübeln gekommen, weil es halt doch Probleme gibt. Erstmal, dass man eben keine Zertifikate hat, nur statische IPs. Keine Authentifizierung des Servers mir gegenüber und wegen statischer IPs hat man halt auch das Problem, wenn der Server nicht login möchte, funktioniert das nicht, weil der muss ja trotzdem immer deine IP kennen. Also, wie seht ihr das? Wird sich dabei Viagart noch was tun in der Richtung, dass man Viagart so Privacy-orientiert nutzen kann, ohne besonders Filometer-Daten anzuhäufen von abraten? Also, dass du die Identität des Servers nicht kennst ist eigentlich nicht möglich, weil das Crypto-Key-Routing ja darauf basiert, dass du einträgst, dass du den anderen kennst. Ja, ja, aber wenn jetzt zum Beispiel in meinem Mittel irgendwie die F4-Lesse des Servers benutzt, um selber so zu tun, als wäre er mein Viagart-Server. Also der Server muss sich mir gegenüber nicht in irgendeinem Zertifikat oder irgendetwas anderen authentifizieren. Aber mit dem Public Key, also du kriegst du den Public Key, den nur eintragen musst, oder? Anders geht es nicht, also du brauchst den Public Key vom Server und über den wird der Server auch authentifiziert, also das... Ich dachte, das wäre nur anders rum, dass der Server meine Identität... Nein, es geht in beide Richtungen, es gibt keinen Server, keinen Client in dem Sinne, sondern das sind beide Endpunkte von dem Tunnel und beide werden authentifiziert. Und an sich brauchst du nur die Entpunkte, also wenn der Server eine staatliche IP hat, der muss tatsächlich die IP von dem anderen Endpunkt nicht kennen, solange der andere Endpunkt die staatliche IP kennt und dann die Verbindung aufbaut. Das heißt, nur eine Seite muss eine staatliche IP haben. Aber ist nicht mein Private Key mit meiner IP-Adresse verknüpft, war das nicht so? Das kannst du im PIR eine IP-Adresse eintragen, es muss aber die IP-Adresse tatsächlich optional, es braucht nur eine Seite, muss die IP kennen, um hin jetzt die Verbindung aufzubauen. Die Authentifizierung passiert dann nur über den Public Key und der ist ja da. Ich komme da später noch auf euch zu. Es könnte ganz kurze Anmerkung, wenn das Mikro übergeben wird, es könnte auch sein, wenn du ein Anbieter benutzt, der dir eine Software gibt, dass sie das Werk abstrahliert für dich. Aber das ist drunter halt genauso funktioniert. Schöne Vortrag, ich hätte eine Vorstellung und eine Frage. Wenn ihr hier das öffentliche WLAN-ZWP benutzt, geht euer IPV-Vortreffekt auch schon über WireGuard zu so einem schwedischen VPN-Dienstleister wegen der Störerhaftung in Deutschland. Das rohmt auch super. Ich habe vorgestern Abend während hier die Veranstaltung in Rosensaal lief, habe ich den WireGuard-Tunnel auf einem anderen Internetanschluss gelegt und es gab keine Sekunde Down Time. Und ihr halt in den NF-Tables erwähnt, dass das das WLAN-Vortreffekt ist. Geht es dann noch um die Paketmarkierung, wie man das auch mit IP-Tables macht oder ersetzt es auch das TC-Tool? Ich weiß tatsächlich nicht, ob man alle Optionen, die TC hat, umsetzen kann. Man kann aber ganz grundlegend sagen, ich würde jetzt gerne für die Vermittlung nur 10 MB diese Kunde erlauben. Sehr cool. Weil das TC ist schlecht bedienbar. Ja, wie IP-Tables. Das WireGuard, habt ihr gesagt, bettet sich in den Kernel als jeder Update von dem Kernel wird dazu führen, dass man wahrscheinlich nicht mehr mit dem anderen Kernel reden kann. Oder sehe ich das falsch? Wenn die Cyphers ausgetauscht werden. Also im Moment hat die WireGuard-Version, die es relativ am Anfang gab, immer noch die gleichen Cyphers wie die, die jetzt benutzt werden. Also das geht halt davon aus, dass der Auto sagt, wenn er ein Algorithmus benutzt, von dem man weiß, dass er gebrochen ist, ich will, dass Leute dann mit Listen rumlaufen, die vielleicht noch den alten Algorithmus mit drauf haben, der dann irgendwie ausgehandelt wird. Er möchte, dass jemand, der seine Software aktuell hält, automatisch weiß, dass die neusten, ungebrochenen Cyphers benutzt werden. Dein Szenario würde ja bedeuten, dass mit jedem Kernel upgrade die Cyphers, also die Algorithmen ausgetauscht werden, das ist praktisch nicht der Fall im Moment. So, vielen Dank für euren Vortrag. Vielen Dank für eure Aufmerksamkeit. Bitte nimmt mir raus, gehen eure Flaschen mit. Viel Spaß beim Workshop. Und sonst folgt hier im Anschluss dann der Vortrag Pathio Passwords, ein Plädoyer für einen digitalmündigen Bürger.