 Has any of you ever been using formal methods or automated proof softwares? Oh, many of you. I found this topic super interesting, because when I first read of it, I was like, oh my god, now I'm going to prove the security of everything I've written so far. Then I realized it takes a lot of time, and it's very difficult, and most of this stuff doesn't have at all any kind of documentation. But I mean, Cornelius works on formal methods for security network management, so I believe he will be able to tell me more about this. And in particular, for this talk of today, he will be telling us about verifying properties of a table's firewall rules. So please give him a big round of applause. Yeah, then hello and herzlich willkommen aus der Übersetzerkabine. Ihr hört die deutsche Übersetzung des Vortrags Verified Firewall Ruleset Verification auf dem 32. Chaos Communication Congress. Ja, herzlichen Dank. Schön, dass ihr früh aufgestanden seid. Und dieser Talk heißt Verified Firewall Ruleset Verification, also wie wir Firewall Regeln überprüfen können. Hier ist ein Firewall Regel Set und das habe ich auf einem NAS gefunden. Das ist eine Linux Gisste. Und da schauen wir jetzt einfach durch, was das macht. Also wenn wir uns zum Beispiel anschauen, wir haben ein Paket, das geht an die Input Chain und die Box läuft jetzt durch diese Regeln durch, bis es eine Treffende findet und dann wissen wir, was wir machen. Also nehmen wir mal ein Beispiel, damit wir alle wissen, was Firewalls machen. Das ist die erste Regel, die Box schaut sich die an. Auf der rechten Seite sehen wir die sogenannte Match Condition, also die Bedingung. Das heißt, wenn das zutrefft, dann in dem Fall alle Protokolle, alle Source IPs, alle Ziel IPs. Also alle und dann führt es diese Regel aus, DOS Protect, also wir springen in die benutzer definierte Regel DOS Protect, die da unten ist. Und da machen wir weiter und schauen uns in der ersten Regel die Bedingung erst an. Es schaut erst nur ICMP Protokoll an, alle Quellen, alle Ziel IPs, ICMP Type 8, also Echo Request. Und wenn ein entsprechendes Limit nicht erfüllt ist, dann gehen wir zurück, wo wir herkommen. Ansonsten schauen wir uns die nächste Regel an. Die schaut sich auch wieder ICMP Echo Request an und wirft es dann weg. Das heißt, diese zwei Regeln implementieren Rate Limiting. Und wenn das nicht ist, dann gehen wir einfach wieder raus. Und ansonsten sehen wir hier dasselbe Muster für TCP Pakete, also offensichtlich die Reset Flag und wird auch wieder weggeworfen, wenn ein entsprechendes Limit überschritten wird. Und sagen wir mal, wir gehen dadurch, ohne dass wir weggeworfen werden, dann landen wir in der nächsten Regel oben, wo alle Pakete, die zu einer bestehenden Verbindung angenommen werden. Das wird es üblicherweise als gute Verfahren angenommen. Und die interessante Frage ist, wie kriegen wir jetzt eine Verbindung in diesen Established State? Und das sind die meisten Regeln, worum es geht. Wie kommen wir da rein in dieser Fireball? Naja, in dem Fall nicht für SSH Pakete, die werden blockiert. Auch viele andere, also TCP Ports werden blockiert. Auch viele UDP Ports. Und am Ende akzeptiert die Firewall alle Pakete in diesem lokalen 192 68er Netz und wirft alles andere weg. Okay, dann hoffe ich, wir haben jetzt die unser Wissen über Firewalls bisschen aufgefrischt. Was ist jetzt das Problem mit Firewalls? Na gut, also jeder liebt in diesem Raum, denke ich mal, Open Source Lösungen. Wir müssen uns also über Backdoors keine Sorgen machen. Und wir lachen natürlich auch über Security Mate in Deutschland. Die Linux und BSC Firewalls sind relativ gut. Was ist das Hauptproblem? Naja, es gab eine Studie, die hat dann echte Enterprise Regeln angeguckt und das stellt sich raus. Es gibt keine guten Regelsets mit hoher Komplexität. Das heißt, die Administratoren reichten diese Regeln ein. Und einige von euch werden vielleicht lachen, dass da vorne war ein relativ einfaches Regelset. Aber stellt euch mal vor, die werden jetzt schwieriger. Und eine Studie hat dasselbe rausgefunden nach ein paar Jahren später und es stellt sich immer noch raus. Diese Firewalls sind schlecht konfiguriert. Es ist also alles um das Regelset. Und wenn die Regelsets kompliziert werden, dann machen wir Fehler. Und ich will jetzt nicht sagen, dass Administratoren inkompetent sind. Nein, nein, lieben Dank an alle, die unser Netzwerk am Laufen halten. Danke an Snogg. Danke, dass ihr uns hier nicht feier wollt, damit wir mehr Spaß haben können. Es geht alles um die Konfigurationen der Firewall, also. Also schauen wir, überlegen wir uns einfach, wir machen ein paar Tools, die unsere Rulesets uns angucken und dann entscheiden, ob das gut ist oder nicht. Und wir haben uns diese echten Tools mal angeschaut mit echten Regeln. Und es gibt im Wesentlichen keinen Tool, das die echten Firewalls versteht. Denn habt ihr euch mal angeschaut, die Manpage von IP Tables, da sind extrem komplizierte Sachen mit drin. Und selbst wenn wir so ein Tool hätten, würden wir dem Tool vertrauen? Also, wahrscheinlich nicht. Also, fangen wir da an, wo andere fehlgeschlagen haben und lasst uns mal versuchen, ein Tool zu schreiben, was Firewall Rulesets überprüfen kann. Und die Tools, die wir bislang angeschaut haben, die verstehen unsere Rulesets nicht, also reden wir erst mal über die Spezifikation und über die Implementierung. Und wenn wir Implementierung reden, dann meinen wir normalerweise den Code, also unser Tool oder low-level Veränderungen, die die Performance verbessern, alles, was hier auf der rechten Seite steht. Und das ist das Zeug, was man üblicherweise dem Benutzer nicht zeigt. Dem Benutzer zeigt man normalerweise nur die Spezifikation oder die Dokumentation. Also, was macht das Tool eigentlich? Und um so ein Tool zu schreiben, müssen wir die Frage beantworten, was ist denn überhaupt ein korrektes Regelzett? Und zum Beispiel hier werden wir jetzt spoofing Schutz, über spoofing Schutz reden. Das heißt, das Ziel ist, unsere Firewall soll spoofing Schutz haben. Wir haben nur 30 Minuten, also halten wir uns nur da dran. Und bevor wir das machen, müssen wir uns zuerst überlegen, was ist denn eine Firewall eigentlich? Also, dafür brauchen wir ein Modell vor das Paketfilterung von IP-Tables. Und das sollte also wirklich ausdrucksstark sein, so dass wir an dem Modell ablesen können. Das hat wirklich was mit der Realität zu tun. Und wir können alle die spannenden Sachen, die wir brauchen für IP-Tables-Erweiterungen in diesem Modell. Das heißt, damit wir auch tatsächlich nachgucken können, hier, wenn das jetzt ist, dann haben wir spoofing Schutz. Und wir wollen den Isabell-Beweishelfer benutzen. Wieso? Naja, wir gucken uns die Dokumentation für eine Bibliothek an und dann schauen wir uns die Implementierung an. Und dann stellen wir fest, die Spezifikation ist im Regelfall nur eine Lüge, denn in Wirklichkeit haben die miteinander nichts zu tun. Das heißt, wir wollen jetzt beweisen, dass die Spezifikation wirklich was mit der Implementierung zu tun hat. Damit wir am Ende beweisen können, dass der Code wirklich das tut, was er tun soll. Und das Wichtigste ist also jetzt hier erst mal zu spezifizieren, was es tun soll. Also, um das mal zusammenzufassen, wir schreiben so einen Überprüfungstool und dann überprüfen wir das Überprüfungstool selbst. Also, fangen wir an. Wir brauchen ein Modell für IP-Tables, bevor wir überhaupt irgendwas spezifizieren können. Also, wir brauchen jetzt Ausdrücke, die wir für Bedingungen, die wir am Anfang gesehen haben. Und die Frage ist, wie schreiben wir das jetzt auf? Also, wir wollen Datentyp definieren, der heißt MatchExpressen, also diese Bedingungen. Und das soll Polymorph sein über den Typ A, den wir jetzt hier Strich A nennen wollen. Und das sind die elementaren Bestandteile, auf die wir Bedingungen formulieren können. Wie können wir so eine Expression also zusammenbauen? Wir können also so einen Strich A benutzen. Wir können irgendwas benutzen, was einfach alles überprüft. Oder wir über invertieren eine Bedingung. Oder wir kombinieren zwei Bedingungen, zum Beispiel hier unten. Also, wir kombinieren zwei Bedingungen mit diesem Match-End und in den Primitiven, das sind die einfachen Dinge, also, die wir beliebig auswählen wollen. Also, hier in dem Fall auf eine Ziel-IP und das Protokoll-TCP. Und das sind komplett generische Ausdrücke. Also, so können wir das hinschreiben. Und die Frage ist, was bedeutet das jetzt? Also, jetzt über Semantik. Also, was bedeuten diese Bedinger? Und wir wollen jetzt uns Pakete anschauen. Das heißt, wir können die Semantik nicht angucken, ohne über Pakete zu reden. Hier gucken wir uns also so ein bisschen eine Formel an. Das sieht jetzt erst mal bei Einschüchtern aus. Aber was haben wir? Der erste Parameter ist eine Funktion, die selbst eine Funktion ist. Die nennen wir Gamma. Und wir nennen sie auch die Primitiven Bedingungen, die Primitiven Matcher. Der erste Parameter ist so eine Primitive. Das heißt, wir können die Quell-IP oder das Protokoll als Bedingung formulieren. Und das zweite ist so ein Match-Ausdruck. Und wir können irgendwas matchen, das ist egal was. Und das liefert entweder wahr oder falsch zurück. Und es soll halt nur dann wahr zurückliefen, wenn das zutrifft auf unser Paket. Und der zweite Parameter ist eine Match-Expressen, so wie wir sie vorher definiert haben. Der letzte Parameter ist das Paket. Und der gibt dann zurück, einen bulger Wert, der angibt, ob das Paket auf die Expression zutrifft. Lass uns jetzt die einzelne Fälle für die einzelne Regel anschauen. Die erste Regel ist für primitive Match-Bedingungen. Das ist einfach, da gehen wir einfach an die Primitiven Matcher, das erste Argument Gamma weiter und fragen nicht, ob das Paket Peter passt. Die zweite Regel ist die Match-Any Bedingungen, die immer match, das heißt es auch einfach immer true. Match-Not bedeutet, dass wir die Match-Expressen invertieren. Das tun wir also auch entsprechend mit den Bullien. Und ihr könnt euch schon denken, match-and, das ist die Konjunktion der beiden Match-Bedingungen, aus denen das besteht. Also jetzt, wir haben jetzt hier die Semantik der Match-Bedingungen. Wir können also jetzt Pakete matchen. Als nächstes brauchen wir dann die Filterregel von der RP-Tables. Die sieht man hier, sehr einfach, kann man alles sehr gut lesen. Am Anfang, also erst mal fragt man sich so, was zu helle. Die gute Nachricht ist, das ist wirklich alles, was wir brauchen über das, über die RP-Tables-Regeln zum Paketfiltern. Das passt auf einer Slide. Wir könnten das alles, wenn wir genug Zeit hätten, das zu lesen, wird uns alles stehen hier. Wir brauchen keine L-Langeman-Pages dafür. Also lass uns versuchen, das zu lesen. Alles, was da steht, sieht folgendermaßen aus. Vielleicht könnte ich ein paar Sachen erkennen. P ist das Paket, das die Firewall untersucht. Gamma ist wieder der Primitive Matcher, der die grundlegenden Features encodiert, die RP-Tables so kann. In der dritten Position haben wir das RuleSet RS. Das ist die Liste von Regeln, die die Firewalls kurz aktuell untersucht. Und S ist der Start-State, der Zustand, in dem die Firewall sich befindet, wenn sie das Paket sich anschaut. Am Anfang ist sie unentschieden, was sie mit dem Paket tun will, üblicherweise. Und T am Ende ist der finale Zustand, wo die Firewall, wo dann steht, ob die Firewalls entscheiden und die Firewall getroffen war, das Paket zu akzeptieren oder zu wegzuwerfen. Lass uns die Regeln anschauen. Die erste Regel ist die einfache Regel, die Skip Rule. Das sind alles sogenannte Inferenzregeln. Alles, was oberhalb der Regel steht, ist die Vorbedingung. Die muss gelten. Und dann gilt unter der Zeile, ist die Konklusion, die wir daraus ziehen können. Was heißt das also, je mit der Skip Regel? Was bedeutet das? Wir haben keine Vorbedingung. Das heißt, es gilt immer. Und was steht unter der Zeile? Nun, wir haben hier das empty RuleSet, die leere Liste von Regeln. Was gilt, wenn wir das leere Liste von Regeln haben? Der Start, Statene, Zielstate sind die gleichen. Das heißt, im Wesentlichen steht hier für die leere Menge von Regeln, macht die Firewall genau gar nichts. Es ist nicht sehr viel, aber wir müssen ja irgendwo anfangen. Lass uns eine etwas komplexere Regel anschauen. Hier haben wir eine Pre-Condition. Was wir uns anschauen, ist ein RuleSet, das mit einer einzigen Regel besteht. Irgendeine Match-Condition M und die Aktion ist akzeptieren. Die Vorbedingung ist, dass die Match-Bedingung, die da steht, auf das Paket zutrifft, das wir gerade untersuchen. Was würde dann passieren? Na ja, die Aktion ist accept. Das heißt, also, was passieren soll, ist, wenn wir bisher noch keine Entscheidung getroffen haben, was passiert, dann werden wir das Paket akzeptieren. Okay, auch nicht so kompliziert. Und ich denke, wir können alle zustimmen, dass das ein Verhalten ist, wie wir das von der Firewall sehen wollen. All die anderen Regeln sehen im Wesentlichen sehr ähnlich aus. Und wir haben nur elf Stück. Das heißt, wir haben genug Zeit. Es ist gar nicht so schwierig, diese Folie zu lesen, wo ihr all drüber gelacht habt. Lass uns also direkt zu der kompliciertesten Regel gehen, die wir haben. Die Regel heißt Call Return, also Zurückkehrung von einem Aufruf. Lass uns das Stück für Stück anschauen. Am Anfang haben wir hier wieder ein RuleSet mit einer einzigen Regel mit der Aktion Call See und irgendeiner Match-Bedingung M. Die Vorbedingungen sind erstens, die Match-Bedingung M muss zutreffen, ansonsten wird die Firewall diese Regel völlig ignorieren. Als zweites ist, dass die Regel, die guckt danach, wie die User die fine Chain aussieht, die benutzerdefinierte Kette zu der wir hinspringen wollen. Wir schauen uns an, wie die aussieht. In diesem Fall Gamma C, die benutzerdefinierte Regel. C ist der Name der Chain, wo wir hinspringen. Und wir gucken uns an, wie die Chain aussieht. Die besteht dann aus RS. Fängt sie an. Das heißt, wir haben die Nebenbedingung, dass die Kette in der RuleSet, das wir so da haben, anfängt mit RS. Und wir gucken dort nach, ob die auch wirklich so anfängt, ob die benutzerdefinierte Kette, wie die aussieht. Die Kette mit dem Namen C, der da in der RuleSet Call See steht. Wie sieht sie aus? Zuerst ist RS1 und dann ist irgendeine Match-AM mit Aktion Return und dann ist irgendein RS2 Das heißt, also die Kette sieht folgendermaßen aus. Es gibt irgendein Präfix, der beliebig aussieht von Regeln. Zum Beispiel die ICMP-Regeln, die wir da am Anfang hatten in der DOS Protect Chain. Dann gibt es eine Regel, deren Aktion Return aussieht. Und dann kommen potentiell noch mehr beliebige Regeln danach folgen. Okay, dann haben wir die nächste und letzte Vorbedingung dieser Regel. Die sagt, wir können den ersten Teil dieser Chain, RS1, bearbeiten, ohne zu einer Entscheidung zu kommen. Das heißt, wir haben also bisher die user-defined Chain bearbeitet und haben noch keine Entscheidung für das Paket bisher getroffen. Also, the next is in der Kette, is the next assumption, die sagt, dass die Return-Regel M-Return, die in dieser user-defined Chain drin ist, das die matched auf unser Paket. Das heißt, wir haben also zuerst diverse Regeln in der RuleSet, die wir ignorieren. Dann kommen wir zu einem M, das Return, das wir zutreffen und wir brechen diese Chain ab. Wir gehen also zurück zu dem nicht definierten Result. Also, in der Regel steht im Endeffekt, wir sind nachher immer noch unentschieden und wir haben diesen Call-C erfolgreich abgearbeitet. Das ist jetzt die mathematische Spezifikation der Implementierung von Call-C. Wir sehen hier also zum Beispiel, wie wir das Verhalten von Call-C und user-definierten Chains definieren können, ohne einen Call-Stack zu haben. Das ist eine reine Spezifikation. Was passiert, die ist nicht ausführbar, was sie kein Call-Stack hat, aber hoffentlich definiert sie klar, was die Firewall tut. Also, wie auch immer, wenn ich euch bisher verloren habe, hoffe ich, dass ihr jetzt wieder mitkommen könnt. Denn warum machen wir diesen ganzen Formalismus? Lass uns jetzt ein bisschen more angewandt werden. Mit jeder Regel werden wir jetzt den Formalismus, den wir bisher aufgebaut haben, nach und nach nutzen, um das Filterverhalten der Firewall festzulegen. Okay, also schauen wir uns diese Formel mal an. Auf der linken Seite, für die Bedingungen der Firewall, das also genau dann, wenn und auf der rechten Seite, auf der linken und der rechten Seite ist also identisch. Und der Unterschied ist, dieses F, F ist eine Funktion, die nimmt einen Ruleset und überträgt es ein anderes Ruleset. Also, was könnte diese Funktion F zum Beispiel machen? Wir haben gesagt, das Verhalten von der Firewall muss dasselbe sein. Das heißt, F nimmt einen Ruleset und macht es zu einem anderen Ruleset, das Verhalten der Firewall nicht verändert. Das heißt, F könnte eine Funktion sein, die zum Beispiel die Performance von einem Ruleset verändert und man könnte die ohne Probleme auf so ein Ruleset anwenden, weil die Formel sagt, F verändert das Verhalten der Firewall nicht. Wir können das direkt auf dem Produktionssystem ausrollen, ohne dass es das Verhalten der Firewall verändert. Wir haben eine ganze Menge von denen implementiert, zum Beispiel ein einfaches Beispiel. Wir können die Lock-Fegeln alle wegwerfen. Die Semantik kümmert sich nur darum, was tatsächlich passiert. Die Lock-Regeln tun das nicht. Das heißt, wenn wir die wegschmeißen, dann bleibt das Verhalten der Firewall genauso. Ein weiteres Beispiel ist, wir können ausrollen Aufrufe zu benutzerdefinierten Ketten. Das heißt, nachdem wir das anwenden, ist das eine Regel, die alle nacheinander abgearbeitet werden. Eine lange Liste. Es wird also nicht mehr hin und her gesprungen. Leider werden die Konditionen, die wir dann brauchen, relativ auslänglich. Gott sei Dank können wir die manchmal vereinfachen. Am Ende haben wir einfach eine Firewall. Das ist einfach eine Liste von sehr langen Regeln. Was da passiert, ist entweder accept oder dropped. Wir können unsere Firewall mit dieser Vereinfachung anwenden. Wir können das sicher anwenden, weil wir sicher sind, dass das Verhalten der Firewall nicht ändert. Also schauen wir uns ein paar mehr seitere Sachen an. Wir haben hier in dreistelliger Logik unsere Semantik implementiert. Es gibt also wahr, falsch und unbekannt. Was können wir damit machen? Naja, ein paar coole Sachen. Also gucken wir uns mal an, was wir hier in der Mitte haben. In der Mitte gibt es eine Menge. Die Menge besteht aus Paketen und die Bedingung dafür ist, dass diese von der Firewall angenommen werden. Also wir starten im unbekannten Zustand und am Ende wird es akzeptiert. In der Mitte haben wir also alle Pakete, die von der Firewall akzeptiert werden. Das können wir spezifizieren. Als theoretischer Computerwissenschaftler können wir das natürlich machen. Jetzt haben wir die Menge von diesen Paketen. Das ist ganz cool. Aber als Hacker glauben wir jetzt erst mal nicht, einfach nur als eine Menge Spezifikationen. Die steht einfach nur rum. Die hat erst mal mit der Wirklichkeit nichts zu tun. Das können wir nicht ausführen. Und als Hacker wollen wir Code ausführen. Und das ist was wir in den Mengen oben und darunter haben. Das sind ein Schätzer. Das ist in gewisser Weise eine striktere Version der Firewall, die wir in Logik implementiert haben. Das ist tatsächlich relativ möglich, die Teile von IP-Tables zu implementieren. Und wir kennen kein Tool, was alles von IP-Table ausdrücken kann. Aber wir haben jetzt hier eine Approximierung. Das heißt, hier wird die Firewall nur strenger. Das heißt, möglicherweise akzeptiert sie weniger Pakete als die Original Firewall. Und unten haben wir eine Überapproximierung. Das heißt, jetzt kann es passieren, wir akzeptieren mehr Pakete als die Original Firewall. Und das Wichtige daran ist, diese beiden können wir ausführen. Und die Wirklichkeit oder die Spezifikation, was wir wollen, ist in der Mitte. Und wir haben Executable Code, also Ausführbahncode, außen rum, sozusagen. Und wir werden das benutzen im Hintergrund. Denn was wir jetzt machen können, ist das ganze Ding ausführen und sicher einschätzen. Wenn wir feststellen, wir haben Features, die wir nicht richtig verstehen, dann können wir es einfach ausführen. Und jetzt haben wir eine gute Approximierung, einen guten Schätzer, wo es eine Expression gibt, irgendwo in der Firewall, da verstehen wir nicht, was das Ergebnis ist. Und wir werden dann sicher abschätzen können, was da passiert. Und die Frage ist, ob wir strenger oder freigegebbar sein wollen. Die Frage ist, gut, wie kriegen wir jetzt Spoofing Protection, Spoofing Schutz am Ende? Also spezifizieren wir mal, was das ist. Also, wir haben zum Beispiel ein IPS, ETH0 gehört die 192.168.0024er Netz. Und was bedeutet Spoofing Schutz jetzt? Naja, jedes IP-Paket, das da über ETH0 reinkommt, muss die Quell-IP in diesem 192.168.0024 Netz liegen muss. Also spezifizieren wir das. Also, wir haben wieder eine Menge, und wir haben es vorher schon gesehen, wir wollen, dass die, in der Menge der Pakete ist die von dem, von der Firewall akzeptiert werden. Und es soll auf dem Interface ETH0 reinkommen. Und genau wie vorher, gucken wir an das Paket, aber nicht das ganze Paket, sondern nur die Quell-IP. Das heißt, diese große Mengenausdruck auf der linken Seite ist das die Menge aller Pakete, die das Firewall akzeptiert und die auf ETH0 reinkommen. Und zwar nur deren Quell-IP. Und was muss jetzt die, diese Menge erfüllen? Naja, alle diese Quell-IPs in dieser zulässigen IP Menge liegen. Also, wir können uns darauf einigen, in diesem Beispiel ist das Spoofing-Schutz. Und im allgemeinen Beispiel brauchen wir das für alle Interfaces auf unserem System. Und jetzt haben wir also eine Spezifikation für Spoofing-Schutz. Also, ich wiederhole das nochmal, wir haben es spezifiziert. Ich denke, wir sind uns alle einig, das ist Spoofing-Schutz. Was können wir jetzt mit dieser Spezifikation machen? Naja, wir können ein Algorithmus schreiben und dem Algorithmus geben, dann haben wir nur diesen IP Assignment, also diese Menge von IPs. Und wenn der Algorithmus wahr zurückgibt, dann haben wir garantiert Spoofing-Schutz auf unserer Firewall. Also, weisen wir mal drauf hin, was hier besonders cool ist. Also, hier seht ihr, dieses beliebige gewählte Gamma. Was bedeutet das jetzt? Gamma war die Menge aller Features, die unsere Firewall unterstützt. Und das ist hier beliebig gewählt. Das heißt, unser Algorithmus kann für jede IP-Tables-Kondition, für jede Bedingung, die IP-Table, gewählt hat, können wir jetzt hier mit Sicherheit sagen, ob wir Spoofing-Schutz haben, möglicherweise implementiert das IP-Tables-Team da noch eine zusätzliche neue Regel. Und dieses Algorithmus kann das tatsächlich verstehen und prüfen, ob Spoofing-Schutz immer noch gewährleistet ist. Egal, selbst wenn ein beliebiges Feature mit eingebaut wird. Das ist eine ziemlich mächtige Spezifikation, die wir jetzt haben für den Algorithmus. Also, wir verstehen alle beliebigen Match-Conditions, die wir jemals in der Firewall benutzen können. Also, was hat jetzt diese Spezifikation auf sich? Normalerweise sind die unpräzise und sagen euch nicht richtig, was der Algorithmus eigentlich tut. Das ist eine mathematische Spezifikation. Die ist tatsächlich präzise und erzählt euch genau, was der Algorithmus euch gibt. Und was es gibt es noch mit üblichen Spezifikationen? Naja, häufig sind sie gelogen oder sie haben irgendwelche impliziten Voraussetzungen oder sie müssen speziell aufgerufen werden, die sind nicht dokumentiert. Aber in diesem Fall haben wir jetzt tatsächlich einen formellen Beweis, dass der Algorithmus diese Bedingung erfüllt. Es gibt also keine impliziten Annahmen, dass diese Spezifikationen wird euch nie belügen. Und für manchmal bei anderen Dokumentationen, da wisst ihr auch, die Dokumentation ist nicht aktuell, speziell bei speziellen Projekten, besonders. Aber hier gibt es jetzt einen Beweis, der ist maschinenverifizierbar. Das heißt, ihr könnt es auf dem Rechner ausführen lassen. Ihr könnt den Beweis in einem Computer geben und der Computer soll zu irgendeinem Zeitpunkt überprüfen, ob der immer noch stimmt und ihr könnt es zu jedem Zeitpunkt prüfen lassen, ob die Spezifikation immer noch von dem Algorithmus erfüllt wird. Die Spezifikation wird also niemals veraltet sein. Das heißt, es ist der beste Weg, euren Code zu dokumentieren. Er dokumentiert immer exakt, was der Code tut und es wird euch mit Sicherheit niemals anlügen. Also, ich habe jetzt gesagt, wir haben executable code. Das sieht aus wie eine ganze Menge formeln. Wie sieht dann der Code aus? Also, wir haben das mit Isabel implementiert und bewiesen. In dem Moment, wo wir ausführbaren Code haben, wir können es zu verschiedenen Sprachen exportieren. In dem Fall Haskell. Ihr könnt es wirklich auf eurem Rechner ausführen. Ihr braucht kein Isabel oder irgendein Beweissystem, sondern das ist ein Programm, das ihr einzeln ausführen könnt. Und da könnt ihr einfach eure IP-Table-Safe-Dump in das Tool hineinschieben und dann nehmt ihr das IP-Assignment wie auf der anderen Folie gesehen oder ihr kriegt es z.B. von IF-Config oder von IP-Address-Show und das wird einfach ausgeführt. Ihr braucht keinen zusätzlichen Input. Ihr könnt einfach diesen Check benutzen, ob Spoofing Protection auf eurer Firewall an ist. Okay, also, hier sehen wir das dann. Wir haben unser überprüftes Tool, das überprüft, ob unsere Firewall auch wirklich Spoofing Protection macht. Wenn mir jetzt hier die Zeit ausgeht, werde ich jetzt noch einen kurzen Ausblick bieten, was wir sonst auch so in unserer verifizierten Toolzelt haben können, in unserer Werkzeugkasten. Ihr habt ja schon vorher gesehen, auf der Folie vorher, wie groß war diese Firewall 4008? Das regeln ist ziemlich groß. Diese Firewall Routeser dürfte inzwischen über 5.000 groß sein. Das heißt, wir haben dann, stellt sich z.B. so die Frage, wer darf eigentlich SSH-Verbindungen aufbauen in einer Routesert mit 5.000 Regeln? Nun, hier ist die Antwort. All diese IP-Bereiche, die ihr hier seht, sind internal servers. Die korrespondieren im Wesentlichen zu den kompletten IP-V4 internen address-space und den ganzen einzelnen Servern. Und diese edges, die geben an, welche Verbindungen ermöglicht sind. Die sind wahrscheinlich, in einem Fall ein bisschen aufgesplittert und wir haben die echt eng zusammengemacht. Aber was wir jetzt bewiesen haben, ist, dass die alle Regeln, z.B., dass sie zusammengeschaltet sind, alle dieselben Zugriffsregeln haben und dass es die bestmögliche Repräsentationen, die wir haben können, die am besten kompromitteste Version welcher Zugriff ermöglicht sind, was nicht möglich ist, diesen Grafen weiter kleinart zu machen. So, in diesem Fall haben wir auf der Link, das hätte jetzt Einheit und Einheit Prime, das war ein Typo in der Firewall, der jetzt korrigiert ist. Er ist ziemlich klein in dem Grafen, wir wollen nicht zwei Internets haben, aber man kann hier sofort den Back sehen, dass wir zwei verschiedene Internet-Klassen haben. Und dann kann man es hier auf die lange Liste von Servern schauen und wir können jetzt hier dann wirklich überprüfen, dass vor all den Maschinen, die über SSH verfügbar sind, dass die alle in der einen Klasse sind, dass SSH verfügbar sind, dass SSH nicht verfügbar sind und dass wir keine lustigen, und dann gibt es noch ein paar lustige Ausnahmen, die lustige Zugriffsregeln haben, die wir auch nochmal näher anschauen sollten. Also, das war es dann soweit. Vielen Dank für eure Aufmerksamkeit. Es wäre wirklich cool, wenn ihr irgendwelche Firewall-Regelsätze herumliegen hättet, die ihr uns zu Forschungszwecken spenden könntet. Es wird uns sehr glücklich machen und natürlich ist es alles, so wie es im Source. Das heißt, ihr könnt euch das jetzt alles anschauen und damit tun, was ihr damit tun wollt. Wir haben es noch ein paar Minuten übrig für Fragen. Also, habt ihr daran gearbeitet oder wisst, weißt ihr von irgendeiner Arbeit, die darum geht, was darum geht, Firewall-Regeln zu studieren ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?