Transkript
Lisa: Hallo und herzlich Willkommen zu einer neuen Episode des INNOQ Security Podcast. Heute wollen wir, Christoph und ich, über Firewalls reden. Was uns dazu bewegt? Zum einen hat eine Hörerin im letzten Jahr ein Feedback an uns gesandt und hat uns gebeten, doch mal eine Folge über Firewalls zu machen. Und zum anderen gab es vor kurzem einen Vorfall, bei dem quasi eine Firewall involviert war. Dazu gibt es aber später mehr. Hallo Christoph, erst mal.
Christoph: Hallo Lisa.
Lisa: Was sind denn Firewalls und wozu sind sie gut?
Christoph: In der IT sind Firewalls, mal ganz grob, Dinge, die zwischen zwei Netzwerken stehen. Oder zwischen einem Service und einem Client und die auf die Verbindungen schauen, was da passiert und diese Verbindung gegebenenfalls auch blocken können. Das war sehr High Level. Es gibt aber wahrscheinlich eine ganze Reihe von verschiedenen Arten von Firewalls, aber dazu kommen wir gleich.
Lisa: Du hast das jetzt so mystisch gesagt mit “diesem Dinge, die dazwischen stehen.” Das bedeutet, dass es nicht immer ein Server zum Beispiel ist, sondern auch etwas ganz anderes sein kann?
Christoph: Ja, es kann erst mal rein Software-basierend sein. Es kann Hardware-basiert sein, als Appliance. Da läuft natürlich auch eine Art von Software darauf, die das macht. Aber die können auch Hardware-unterstützend sein. Ein Netzwerk Element hat einen Switch oder so, wo die Pakete durchgehen, da können auch Firewall Funktionen drin sein, die direkt in der Hardware unterstützt werden. Und deshalb habe ich das ein bisschen als Ding bezeichnet, weil es gibt auch andere Arten von Firewalls, die als Programm vielleicht auf deinem Computer laufen. Da gibt es ganz verschiedenes. Deshalb sagte ich erst mal “ein Ding”, das Netzwerkverbindungen aufnimmt und die gegebenenfalls blockt oder weiterreicht.
Lisa: Magst du einmal erzählen, was für verschiedene Arten es denn gibt und was die für spezielle Eigenschaften mit sich bringen?
Christoph: Man kann die auf ganz verschiedenen Dimensionen versuchen zu kategorisieren. Fangen wir mal ganz einfach an. Es gibt die Personal Firewall gegenüber einer klassischen Firewall. Die Personal Firewall ist das, was auf deinem Rechner läuft und das bringt Windows und macOS heutzutage von Haus aus mit. Linux und hat das schon lange mitgebracht, weil Linux eigentlich nicht als Desktop System benutzt wurde und wahrscheinlich immer noch nicht oft als Desktop benutzt wird. Man sagt immer: 2023 ist jetzt bestimmt das Jahr des Linux Desktop. Das ist ein Klassiker, seit 2000. Das ist eine Personal Firewall. Im Fall von macOS oder auch Windows, da sieht man das auch. Dann kriegt man Warnmeldungen, wenn Verbindungen geblockt werden sollen oder da steht: Programm XY möchte gerne hier eine Netzwerkverbindung aufmachen oder eine Netzwerkverbindung annehmen. Die ist also sichtbar und die läuft auf deinem Rechner und soll dann verhindern, dass Trojaner nach außen telefonieren oder du vom Netzwerk aus angegriffen wirst. Oder die Programme, die du vielleicht lokal startest und die von localhost eine Netzwerkverbindung annehmen müssen. Man kann auch auf dem Desktop klassische Client-server Sachen haben, die über Netzwerk Protokolle sprechen, dann über localhost, dass die nicht von außen erreichbar sind. Dafür ist das da. Und wie gesagt, die sind eingebaut. Früher musste man die extra kaufen. Als Sicherheitsprodukt hat man dann von ganz vielen Herstellern, die auch Anti-Viren Produkte herstellen, auch einen Personal Firewall extra kaufen können oder waren innerhalb dieses Anti-Viren Produkts dabei. Man kann die auch heute noch kaufen für macOS gibt es zum Beispiel Little Snitch. Das ist auch noch schön grafisch aufgearbeitet. Dann sieht man: Wo kommt die Verbindung her? Auf so einer Weltkarte oder wo soll eine hingehen? Und Information, was alles an Traffic geblockt wurde. Für Windows gibt es auch so was namens GlassWire. Das ist eine, die ich jetzt kenne, als Nicht-Windows Nutzer, die ziemlich ähnlich aufgebaut ist wie Little Snitch. Und über die wollen wir heute gar nicht so viel reden. Die richtet sich mehr an den klassischen Endnutzer, der kein Tekkie ist und vermittelt ihm das Gefühl einer vermeintlichen Sicherheit, obwohl es damit viele Probleme gab und wahrscheinlich auch keine Firewalls mehr nötig sind, die Windows oder macOS von sich nicht auch sowieso mitbringen. So ein extra Produkt halte ich jetzt eigentlich nicht für zielführend für den klassischen Endanwender. Worüber wollen wir heute reden? Eigentlich über die klassischen Firewalls. Und die sind nicht so sichtbar, sondern sind eher transparent. Die sitzen wie ein Proxy zwischen dem Service und dem Client. Bzw. zwischen den zwei Endpunkten einer Netzwerkverbindung sitzen die dazwischen. Entweder als Hardware Element, vielleicht im Switch drin. Oder es gibt auch dedizierte Produkte von verschiedenen Herstellern, Cisco zum Beispiel. Die haben eine Hardware Appliance, die man da reinbringt. Oder es gibt auch reine Softwareprodukte. Die kann ich dann, wenn ich in der Cloud bin, einfach als Service selbst auf einer EC2 Instanz installieren und die dann so konfigurieren, dass der Traffic da durchgeht. Meistens natürlich hybrid. Das ist zwar irgendwie eine Appliance, ist aber ein ganz normaler Server und da läuft dann eine Firewall Software darauf, die auf Linux Basis oder so ist. Das ist zwar von außen eine Blackbox, aber ist mit den Standard, die Linux schon mitbringt, vielleicht ein bisschen aufgepeppt mit einer guten Benutzeroberfläche oder auch eher nicht. Meist sind die Benutzeroberflächen nicht so schön und vielleicht so ein bisschen Customizing. Das sind die typischen Formen von Firewalls, die es auf der einen Kategorie gibt. Eine andere Kategorie ist: Wie funktionieren die denn? Ich habe jetzt die Verbindungen, die können angenommen oder blockiert werden. Und das waren auch die einfachsten, die sich auf der IP-Pakete anschauen. Die heißen Packet-based oder Packet Inspection Firewalls und die schauen sich IP-Pakete an. Wo kommt das her und wo geht das hin? Und daran können sie dann entscheiden: Das will ich durchlassen oder das will ich blockieren. Aber die haben sonst nicht so viel Intelligenz. Damit könnte ich zum Beispiel ein DoS oder ein DDoS Angriff versuchen abzuwehren. Wenn ich weiß: Die Angreifer kommen jetzt von folgenden IP-Adressen, dann blockiere ich die. Aber mehr können die auch nicht. Sie können Pakete anhand der Metadaten filtern. Ende der 80er, Anfang der 90er des letzten Jahrtausends gab es die ersten, die das gemacht haben. Und das hat sich dann ein bisschen weiterentwickelt. Dann kamen die Stateful Packet Inspection oder Circuit-Level-Gateway genannt. Was der Unterschied? Die schauen jetzt nicht nur auf die einzelnen Pakete, sondern die können auch feststellen, ob da eine Verbindung vorliegt. Es gibt auf IP Basis eigentlich nur noch zwei Protokolle, die gesprochen werden. TCP und UDP. UDP hat keine Verbindung, da kommen die nicht zum Einsatz. Zum Beispiel bei DNS ist ein UDP-Protokoll. Da würde eine Packet-based Inspection einfach reichen. Und diese Stateful können dann auch bei TCP-Verbindungen sehen: Welche Pakete gehören denn zu einer Verbindung dazu? Und dann kann man zum Beispiel ein bisschen mehr Angriffe auf die Netzwerke abwehren. Es gibt ein sogenanntes SYN flooding. Wenn ein TCP Handshake gemacht wird, kann man das so machen, dass man diesen Handshake nicht abschließt. Und der Server, der dann auf das letzte Paket wartet, bis die Verbindung hergestellt ist, unendlich lange wartet. Da gibt es wahrscheinlich auch Timeouts. Ich versuche ganz viele Verbindungen aufzubauen und lasse die in einem halboffenen Zustand. Dann geht dem Server vielleicht irgendwann mal die Ressourcen aus und das kann ich anhand der einzelnen Pakete nur sehr schwer feststellen. Da müsste ich eine Art State Machine haben: Wo befindet er sich jetzt im Handshake? Und das kann ich auch mit so einer Stateful Packet Inspection machen. Vereinfacht gesagt könnte man sagen: Die hat jetzt TCP gelernt. Die kennt nicht nur das IP-Protokoll, sondern kennt sie auch TCP. Und das hat sie auch wieder alles weiter verfeinert. Das ist auch schon 30 Jahre her, seitdem es die ersten gab. Und dann gibt es den großen Begriff der Next Generation Firewall, der total blurry ist, weil alles mögliche, was danach kam, ist Next Generation und die können sehr unterschiedliche Funktionen haben. Die machen zum Beispiel ein Deep Packet Inspection. Das heißt, die schauen sich nicht nur die Metadaten an. Nicht nur: Wohin geht das Paket und woher kommt es? Und gehört das jetzt zu einer bestimmten TCP-Verbindung? Sondern, die können dann auch in den Payload, also in die Daten reinschauen. Und dann kann man zum Beispiel feststellen: Diese TCP-Verbindung hier gehört jetzt aber zu illegalem Filesharing oder das ist ein Filesharing Protokoll, was da drunter äuft oder das ist ein Video Streaming Protokoll oder ein Voice Streaming Protokoll und können dementsprechend darauf reagieren. Das funktioniert nicht mehr so gut, seit dem der meiste Traffic im Internet verschlüsselt ist. Wenn ich mir den Payload anschaue und er verschlüsselt ist, dann kann ich wenig darüber herauskriegen. Da gibt es auch Techniken, die sich die Struktur anschauen. Größe, Anzahl der Pakete im Zeitraum X, wo man trotzdem vielleicht auch daraus schließen kann. Ist das jetzt ein Videostream oder war das eine Webseite, die abgerufen wird, aber das ist alles nicht so zuverlässig. Das funktioniert nicht so gut. Und andere Sachen, die unter Next Generation gefasst werden, dass die zum Beispiel auch Möglichkeiten haben, auf dem Application Level oder Application Layout zuzugreifen. Dafür gibt es dann aber auch nochmal ein extra Wort, das sind Application Level and Layer Firewalls und die arbeiten nicht auf der Paketebene mehr, sondern auf den Protokollen, die oberhalb von TCP liegen. Das könnte jetzt SMTP, XMPP und typischerweise natürlich HTTP und da kommt dann eins ins Spiel, was wahrscheinlich du und wahrscheinlich auch viele Hörerinnen gehört haben, ist die Web Application Firewall, die WAF. Die versteht HTTP. Die können das HTTP-Protokoll analysieren und versuchen darauf zu arbeiten.
Lisa: Das sind ganz schön viele verschiedene Arten, Kategorien und eine lange Historie dahinter. Sind für heutige Projekte nur die neuesten relevant oder auch ältere?
Christoph: Eigentlich sind noch alle Kategorien relevant. Es kommt aber darauf an, wo du dich in so einem Projekt befindest. Also diese klassischen Paket basierten Sachen, mit denen haben wir eher wenig zu tun, sondern das macht so der Betrieb. Im Rechenzentrum wird so was gebraucht, die wollen natürlich sicher sein gegen irgendwelche DoS-Angriffe oder so. Damit haben wir aber wenig zu tun. Wir beide sind auf jeden Fall eher in der Applikation-Entwicklung unterwegs und nicht in der Netzwerktechnik. Deshalb haben wir mit denen nichts zu tun. Trotzdem gibt es sie überall, also in jedem Rechenzentrum oder sonst wie steht wahrscheinlich so ein Ding rum. Die Netzwerkverbindung ist halt nicht direkt sozusagen ans Internet angeschlossen. Damit man, wie gesagt, zum Beispiel so einen DoS-Angriff kappen kann oder versuchen kann, den zu kappen. Wenn man den Rechner direkt ans Internet anschließt, wenn man das kann, das ist gar nicht so einfach. Zu Hause sitzt ja noch die Internet Service Provider dazwischen, die blocken auch schon jede Menge. Aber wenn man das mal einfach so dran setzt, dann kommt innerhalb kürzester Zeit, oft wenige Sekunden, dass alle möglichen Angriffe da probiert werden, auch auf dein Netzwerk eben. Und so was wird dann von so einer Firewall alles rausgehauen. Ja, ist noch dabei und ist auch sinnvoll an der Stelle, aber hat mit uns eher wenig am Hut. Manchmal bemerkt man das, wenn man irgendwie eine Applikation macht und die muss mal nach draußen telefonieren. Irgendeinen Service aufrufen, der außerhalb des Netzwerks liegt, also des internen Netzwerk, wo die Applikation läuft. Heute kann man da viele Sachen als Software as a Services (SaaS) buchen und dann muss man mit denen auch sprechen. Die bieten eine API an und dann kann es schon passieren, dass so was einfach auch mal geblockt wird, weil die dann manchmal sehr restriktiv eingestellt sind und sagen, man darf erst mal nicht nach draußen telefonieren, was vielleicht sinnvoll ist, um zu sagen ja, sollen Leute, die vielleicht in das Netzwerk eingedrungen sind, keine Daten exfiltrieren können. Also verbieten Verbindungen nach außen. Das hatte ich schon in ein, zwei Projekten mal, dass man dann sagen muss, Ihr müsst mal für folgende IP-Adressen die Firewall freischalten, damit wir da Verbindungen aufbauen können, also kann einem schon noch passieren. Manchmal ist es auch problematisch, dass über so was Webseiten gesperrt werden. Ich hatte mal, aber das ist jetzt schon sehr sehr lange her, noch vor meiner INNOQ Zeit. Sehr am Anfang meiner Karriere habe ich PHP gemacht. Das war noch PHP-Version 4. Wenn man jetzt mal so nachschaut, vielleicht bei der Wikipedia, dann weiß man, das ist sehr lange her. Da war es bei dem Arbeitgeber so, dass ich nicht auf die PHP-Dokumentation im Netz zugreifen konnte, weil die Seite gesperrt war von der Firewall. Und das war problematisch, dafür konnte man auch keine Ausnahme machen oder wollte vielleicht auch keine Ausnahme machen. Programmiersprachen, ohne dass man auf die Doku zugreifen kann, ist halt nicht immer so gut. Aber das nur so aus der Anekdote heraus. Es kann einem noch begegnen, dass man so oft auf diesen Firewalls ist. Unbewusst ist das auch so, wenn man bei Cloud Providern unterwegs ist und dann da seine Maschinen hochfährt. Da muss man denen auch erst mal so gewisse Rechte geben, ob die nach draußen telefonieren können oder in welchem IP-Adresse Bereich. Da gibt es diese VPCs. Das wird intern oft auch eigentlich nur über Firewalls gesteuert, ist dann relativ transparent. Und da kommt der Name Firewall vielleicht auch gar nicht immer vor, die Umsetzung wird dann über solche klassischen Firewalls gemacht. Was man dann schon öfter sieht, ist der Application Level oder Application-Layer-Firewall, die dann vor den eigenen APIs stehen und die man dann auch oft konfigurieren muss, dass die vernünftig von Clients, die da draußen sind, also Web-Clients, der Browser oder die Single Page Applikation im Browser, dass die die vernünftig aufrufen können. Das ist gar nicht so einfach, weil die Regeln deutlich schwieriger sind. Nicht schwieriger, sondern komplizierter. Bei dem anderen muss ich gucken, Woher kommen die Pakete, wo gehen sie hin? Das ist relativ einfach. Und wenn mein Service Provider einen gewissen IP-Bereich hat, dann kann ich den freischalten. Bei Web Application Firewalls, die dann in den Inhalt gucken, da kann ja alles mögliche drinstehen. Es gibt keine generischen Regeln, die sagen XY im Payload müssen wir rauswerfen. Die gibt es schon, die Regeln, aber die sind halt sehr, sehr fehleranfällig. Und je nachdem muss man dann sich an jemanden wenden, der das konfiguriert oder im Cloud Betrieb muss man das auch selber konfigurieren. Viele Cloud Anbieter bieten solche Sachen natürlich als Service an, dass man so eine Web Application Firewall davor hat. Das BSI empfiehlt das auch in ihrem Grundschutz als Baustein, dass vor jedem Server so eine Firewall hängt. Und da muss man wirklich sagen, vor jedem Service hängt einer. Bei der anderen Firewall, ganz klassisch auf Paket Basis, da wird es ja theoretischer Weise reichen, dass wir die sozusagen an einer Stelle zentral aufhängen. Und bei der Web Application Firewall, wenn ich jetzt verschiedene Services, Applikationen oder APIs betreibe, da brauchen die auch speziell angepasste Regeln. Das heißt, da muss ich für jeden einzelnen Service eine eigene Firewall installieren. Ob ich das jetzt wirklich jeweils einzeln mache oder nicht doch zentral und dann zum Beispiel die Regel nur auf bestimmte Pfade anwende oder so, das muss man dann sehen, wie das implementiert ist. Wenn wir die logische Sicht nehmen, hat man dann halt vor jedem seine eigene Web Application Firewall.
Lisa: Was ich irgendwie gerade die ganze Zeit im Kopf habe, habe ich die Möglichkeit in einem NGINX zum Beispiel auch Firewall Regeln zu implementieren oder ist das jetzt die ganz falsche Stelle?
Christoph: Mit jeder Art von Proxy, NGINX kann man so auch als Proxy einsetzen, kann man versuchen Firewalls zu implementieren. Ich habe beim NGINX die Möglichkeit zu sagen, ich schaue mir den Pfad oder so an und mach da bestimmte Regeln drüber. Wenn ich dann sage, der Adminpfad ist jetzt nicht aus externen Netzwerken erreichbar, dann hat man so eine Art Firewall. Das ist natürlich beschränkt, weil der NGINX hat das jetzt nicht als seine Kernkompetenz, sondern da ist ja erst mal ein Webserver oder ein Proxy Server. Es gibt das ModSecurity, das kommt eigentlich vom Apache Webserver, den konnte man ja durch Module erweitern. Vorhin habe ich gesagt ich habe mal PHP gemacht, da gab es auch das Wort PHP, dass man das im Apache direkt drin hat. Und da gibt es auch ModSecurity, das gibt es jetzt auch für mehr als den Apache. Da kommt es ursprünglich her und es gibt auch was für NGINX, das hat sich so eine Firma geschnappt und das entsprechend erweitert für verschiedene Server. Ich weiß jetzt gar nicht welche davon frei sind und welche man extra kaufen muss und dann hat man so eine volle Funktionalität, wo man dann auch mehr machen kann. Unter anderem auch sich den Payload genauer anschauen. Das geht mit einem normalen NGINX dann halt auch doch eher schwierig. Und dieses ModSecurity sorgt dafür, dass ich dann eine vollwertige Application Firewall habe. Beziehungsweise ich brauche natürlich noch einen Regelset dafür. Aber es stellt erst mal die Funktionalität bereit und dann brauche ich mir keinen eigenen Proxy schreiben, sondern habe da was, wo ich sage es gibt Regeln und danach kann ich den konfigurieren.
Lisa: Woher kriegt man so ein Regelset?
Christoph: Ja, das ist das Schwierige. Das ist ja auch das, wo sich die kommerziellen Anbieter das alles gut bezahlen lassen mit ihren Next-Generation Firewalls. Das heißt ja, die bringen Regelsets mit. Warum brauche ich dann einen kommerziellen Anbieter? Weil der mir solche Regelsets liefert. Weil er die pflegt, weil er neue Angriffe vielleicht dann auch schneller erkennt. Weil er viele Kunden hat und dann schneller darauf eine Regel macht und und so was. Und manche sind auch dann von außen gemanagt, wo das Regelset sozusagen von außen eingespielt wird. Ich kann es versuchen, selber zu pflegen. Das ist wahrscheinlich sehr schwierig, weil es unglaublich viele Arten von Angriffen gibt, die immer neu aufkommen. Da brauche ich dann halt schon dedizierte Ressourcen dafür oder ich guck, was es so auf dem freien Markt gibt bzw. auf dem Open Source Markt. Und da ist die OWASP auch dabei. Die hat nämlich das Core Rule Set, das ist ein Open Source Projekt, wo ganz viele Regeln drin sind und was dann auch gepflegt wird von anderen Leuten, die dann immer neue Regeln einpflegen und das wird dann regelmäßig releast. Gibt dann halt Versionen dabei und die gibt es dann auch direkt passend für das ModSecurity zum Beispiel. Wahrscheinlich kann ich die auch anpassen an andere Module, die ich vielleicht auch selber geschrieben habe. Und da muss man mal gucken und die kann ich mir nehmen. Woraus besteht so ein Ruleset da? Das sind ganz viele RegExe. Bei einem Core Ruleset ist sogar eine eigene Sprache, die mehr RegExes erstellt. Es ist schon ein bisschen schräg eigentlich, aber da steht dann eine ganze Liste von RegExen, die ich dann anwenden kann auf den Pfad oder auf Header oder auf den Payload. Also diese Sprache erstellt jetzt nicht nur den RegEx, sondern auch die gesamte Regel. Also wie gesagt, ich kann die auf ganz verschiedene Dinge anwenden. Da kann man sich dann die einfach erst mal nehmen und damit starten. Aber was ich ja gerade gesagt habe, man muss die anpassen an seine Applikation, also so ein RegEx, der auf irgendeinen Payload, der in einem Angriff enthalten sein könnte, reagiert. Heißt ja dann nicht, dass der RegEx nicht auch anschlagen könnte bei einem Payload, der ganz regulär an meine API gehen kann. Und das ist das Problem, ich muss dieses Ruleset nehmen und das auch ganz spezifisch anpassen. Und meistens heißt das, man muss alles mögliche testen und schauen, wann geht’s kaputt. Das ist auch relativ komplex und da sind irgendwie hunderte von Regeln drin. Da bleiben halt auch x Regeln drin für Angriffe, wo ich vielleicht gar nicht mehr anfällig bin, die sozusagen bei mir schon gefixt sind, aber die werden trotzdem da gemacht. Ein Beispiel ist Lockwood J, da hatten wir auch schon mal drüber gesprochen? Wenn ich das jetzt bei mir gefixt hab, dann ist die Regel halt trotzdem noch da. Da kommt eher selten mal was raus. Und das andere ist, das sind natürlich auch ganz viele Regeln für Dinge, von denen ich überhaupt nicht betroffen sein kann. Gehen wir mal wieder auf PHP, irgendwie so ein PHP Include von files, der möglich ist. Der ist dann halt da möglich und nicht in meiner Technologie. Also bei JSP gibt es sowas auch, solche Includes, aber wenn ich jetzt ein Go Programm oder Rails Service habe, da geht das dann halt nicht. Trotzdem habe ich diese Regeln dabei, dann ist das halt schwierig. Es macht dann halt Sinn, wenn ich sie zentral hab, die Firewall. Und ich habe da X Services in verschiedenen Programmiersprachen, Frameworks oder so dahinter. Wenn ich es aber direkt davor setze, dann habe ich auch eine ganze Reihe von Regeln, die bei mir in der konkreten Situation überhaupt keinen Sinn machen.
Lisa: Das ist, glaube ich, eine ganz gute Überleitung zu. Was kann überhaupt schief gehen oder was sind generell die Probleme mit Firewalls? Du hast gerade schon gesagt, ich blocke viel mehr, als ich eigentlich blocken müsste, weil da eben Regeln drin sind für Sprachen, die mich vielleicht nicht interessieren. Dann hattest du schon auch noch angedeutet, dass man das Regelset ja selber aktuell halten muss, also dass da auch eine Pflicht bei mir liegt, das zu tun. Aber was sind die weiteren Probleme mit einer Firewall?
Christoph: Da gibt es eine ganze Reihe. Also eins hast du jetzt schon genannt. Das ist ja so, wenn man mehr blockiert, als man möchte. Da kann man relativ schnell dann die Ausnahmen schaffen für solche Sachen. Ist halt blöd, wenn es nicht bei den Tests auffällt, sondern im Betrieb. Man testet ja auch nur gewisse Dinge und nicht alle Möglichkeiten, wie so eine API oder ein Service genutzt werden kann. Also das wird immer wieder mal auftauchen, damit kann man vielleicht umgehen. Ich glaube, das größere Problem oder das größte Problem ist halt, dass man sich in falscher Sicherheit wiegt. Oft ist die Security Strategie halt “Wir haben ja eine Firewall. Steht ja auch beim BSI im Grundschutz drin, dass wir eine Firewall haben müssen und damit sind wir dann safe. Angriffe werden dann draußen gehalten und wir schauen dann halt nicht mehr so auf die Security”. Und das ist echt problematisch und da muss man aufpassen. Warum ist das eine falsche Sicherheit? Die Firewall soll ja Angriffe abblocken, aber da gibt es mehrere Probleme mit. Einmal, die kann nicht in die Zukunft schauen. Wenn was neues, eine neue Art von Angriff kommt, da muss eine neue Regeln erstellen. Als Lockwood J rauskam, dann hat es gedauert, bis die Anbieter die Regel hatten. Das ging bei dem Angriff, der wirklich groß in den Medien war, bzw. die Angriffsmöglichkeit, die wirklich so prävalent überall war, dass man da schnell reagiert hat, aber das muss ja nicht so sein. Da hat es, glaube ich, so ein Tag gedauert bei Lockwood J, bis die ersten Firewall-Regeln da waren. Vielleicht auch schneller bei den kommerziellen Anbietern, ist nicht immer klar, wann die damit so weit waren. Es können aber auch andere Angriffe kommen, die vielleicht nicht so populär sind, wie Lockwood J, dann dauert es vielleicht etwas, bis sie da sind und in der Zeit bin ich verwundbar. Außerdem haben wir gerade gehört, da sind viele RegExes dabei, die das machen. Die kann man vielleicht auch umgehen, den Payload ein bisschen umformulieren oder so, der dann trotzdem noch wirksam ist, aber wo der RegEx nicht mehr matcht. Oder ein anderes Encoding nehmen, wo der RegEx da nicht drauf reagiert. Coding Bypass ist ein typisches Problem von Firewalls. Das heißt, ich kann damit eigentlich nur die bekannten Sachen abwehren und das vielleicht auch noch nicht mal immer sicher. Also das ist ein großes Problem. Und das andere ist, so eine Firewall läuft ja mit sehr hohen Privilegien, also zum Beispiel als Root User und hat erst mal Zugriff auf das interne Netz. Das heißt die Firewall selber ist eigentlich ein Angriffsziel und die erhöht meine Angriffsoberfläche eigentlich ungemein. Und man hat schon sehr oft gesehen, dass solche Firewalls halt dann selber Schwachstellen hatten und zwar viele und mit dem man dann halt auf einmal irgendwie eine Maschine mit Root Rechten im Intranetz hat. Das ist natürlich ziemlich blöd. Ich gebe WEBSEC-Trainings-Trainings, nur mal als Beispiel, da sprechen auch mal über Firewalls an einer Stelle. Und dann zeige ich vom Heise Newsticker zwei Wochen und dann sind da irgendwie sechs oder sieben Meldungen drin, dass Firewall Produkte eine Lücke haben, die man sofort patchen sollte, weil die dann übernommen werden können. Und ein Hersteller ist sogar in den zwei Wochen doppelt dabei mit zwei verschiedenen Lücken. Wer sowas macht, wer so einschlägige Seiten, Heise Security, Golem und so beobachtet, der wird andauernd solche Lücken kriegen, also mitkriegen, dass es solche Lücken gibt. Und das ist halt ein Problem, das meiner Ansicht wahrscheinlich zwei Ursachen hat. Einmal sind das sehr komplexe Programme, die da geschrieben werden müssen. Gerade diese Next-Generation Firewalls, die dann x andere Funktionen noch haben in so einem Security Gesamtprodukt, sind dann vielleicht Teil von einem Intrusion-Detection-Prevention-System oder haben andere Sensorik da drin und alles mögliche, machen Deep Packet Inspection. Was wir auch oft machen, damit man überhaupt diese Deep Packet Inspection machen kann ist, die brechen die TLS-Verbindung auf, also terminieren TLS, damit sie da reingucken können. Zum Teil wird dann der ganze Traffic auch gespeichert, damit man da nachträglich noch mal gucken kann. Also sehr komplex, kann man sehr viel falsch machen, wird sehr viel falsch gemacht. Und das andere sind die Admin-Oberflächen. Die sind meistens eher, sagen wir mal so, sieht immer aus, als würde man das hinterher noch so eilig da draufgeklappt haben. Wenn du schon mal bei deinem Heimrouter geguckt hast, die haben ja meistens auch so eine Firewall-Funktion und da haben auch ganz viele, gerade dieses China-Plastik-Zeug was man von seinem Internetprovider kriegt, so ganz grausige Oberflächen, wenn man noch drauf zugreifen kann. Manchmal klemmen die Internetprovider das auch ab, aber wenn man sich irgendwas kauft, so einen WLAN-Router oder so, die sind alle erst einmal so naja, also wird wahrscheinlich unseren Ansprüchen an Applications UX nicht genügen. Und gerade in diesen Anwender Oberflächen sind ganz oft so Probleme, die man eigentlich schon vor Jahren aus normalen Applikationen hätte rausnehmen müssen. Hardcodierte-Admin Passwörter oder so was. Ganz einfache Probleme, die einem, wie gesagt, seit zehn Jahren nicht mehr passieren. Die Top Ten werden da nicht so wirklich beachtet. Was man vielleicht verstehen kann, weil es vielleicht a so ist, dass die User da nicht so einen Wert auf ein riesen UX legen, die werden oft gezwungen mit so einer Firewall zu arbeiten. Es sind nicht immer die, die die bedienen müssen oder administrieren müssen, die die auch einkaufen. Das andere ist vielleicht, dass man solche Sachen vielleicht auch gerne weitergibt, also outsourcen und die woanders entwickeln lässt. Die, die solche Sachen herstellen, das sind ja zum Großteil Netzwerk-Ausrüster oder sonstiges. Software ist eigentlich nicht unbedingt deren Kerngeschäft, das ist vielleicht auch die Hardware. Und wenn ich dann aber Zugriff auf die Admin-Oberfläche habe und da alles steuern kann, dann habe ich das Ding ja übernommen und das ist halt schlecht. Von daher, falsches Gefühl von Sicherheit. Besser wäre eigentlich, wenn man auf eine Firewall verzichten könnte, aber das geht halt nicht immer.
Lisa: Wir hatten ganz am Anfang schon angekündigt, dass wir das nicht nur wegen der Nutzerin oder Hörerin-Anfrage aufnehmen, die Firewall Geschichte, sondern dass es auch einen relativ aktuellen Vorfall gibt, wo Firewalls involviert sind. Ich glaube, jetzt ist ein guter Zeitpunkt, den einmal zu beschreiben.
Christoph: Ja, das in den letzten Wochen, genaues Datum weiß ich jetzt nicht. Wir verlinken das in den Shownotes. Da hat der Troy Hunt das ist derjenige, der das „Have I been Pwned?“, da haben auch schon mal darüber gesprochen, also den Service betreibt. Also da, wo man nachgucken kann, ob seine E-Mail oder sein Passwort vielleicht schon mal in einem Breach drin war. Der sammelt solche Daten, bereitet die dann auf, macht aus diesen Pawned Passwords Service. Diese API kann man kommerziell nutzen, muss man bezahlen, dann gibt es verschiedene Pakete und je nach Paket kann ich dann zehn Requests pro Minute machen oder 100 oder sonst wie. Desto mehr ich zahle, desto eher kann ich das benutzen. Da gab es dann halt ein Problem, dass bei dem Bezahlvorgang bei Ihnen, ein Nutzer, irgendwas schiefgelaufen ist. Da konnte der ich glaube kein Upgrade oder so machen, sondern hatte immer noch so gesperrt nach zehn Aufrufen, obwohl er sich 50 gekauft hat oder so. Nach ein bisschen Recherche von Troy Hunt, er beschreibt das in einem Blogpost, den verlinken wir auch. Es hat sich dann rausgestellt, dass das mit seinem Cloud Anbieter oder seinem CDN-Anbieter ein Problem mit der Firewall war. Da kam zwischen seinem Zahlungsdienstleister und der Seite, der die Abwicklung macht, kam dann ein Request nicht richtig durch. Was war letztendlich die Ursache? Das konnte er nicht so genau erklären, aber es hängt mit der Firewall zusammen. Das ist aufgetreten, nachdem der Anbieter ein Update des Ruleset gemacht hat und das war basiert auf dem OWASP Ruleset, da steht auch bei, welche Version von dem OWASP Core Ruleset da genommen wird und dann hat er herausgefunden, das kann man dann sehen, welche Indikatoren da anschlagen. Die Firewall ist nicht so eine Ja, nein, sondern es gibt verschiedene Indikatoren, die da anschlagen können. Da müssen mindestens drei RegExes matchen, die vielleicht eine Injektion anzeigen oder so und dann gibt es ein Scoring und dann kann man einen Schwellwert einrichten. Da ist der Schwellwert halt überschritten, weil da was angeschlagen hat, was aber nicht klar war, er konnte sich dann den Traffic noch mal anschauen und sehen, das war ein ganz legitimer Request, da war nichts Auffälliges dabei. Jedenfalls in dem Blogpost ist noch nicht klar, warum, aber da hat einfach ein Update der Firewall und auf einmal können Leute, die dann bezahlen, kriegen ihre Leistung nicht. In dem Fall ziemlich blöd. Man kann sich vorstellen, was auch noch woanders passiert, das ist jetzt nicht so ein Service, der so wahnsinnig teuer ist. Das ist erst mal unbemerkt untergegangen. Was ich auch erschreckend fand bei dem Service, der kann auch den ganzen Traffic mitschneiden, wenn man das einstellt. Das wird dann zwar verschlüsselt, man kann dann einen Public Key dafür nehmen, dass man das mit seinem Private Key noch selber entschlüsseln kann, aber trotzdem, der sammelt erst mal den ganzen Traffic. Und wenn da mal was schiefgeht. Ich meine das ist standardmäßig aus, aber das sind so Möglichkeiten, die vielleicht dann auch nicht so cool sind. Ich fand das ganz passend, weil der Troy Hunt auch ein Sicherheitsforscher ist und dann Probleme mit so einer Firewall kriegt. Ich hatte ja gerade gesagt, vielleicht ist es manchmal besser, keine Firewall zu haben. Es gibt die eine Ausnahme, wo die Firewall vielleicht immer gerechtfertigt ist, wenn ich keine Deployment-Fähigkeit habe. Sagen wir mal, ich kann nur alle drei Monate deployen, in so Großkonzernen passiert das öfter mal, vielleicht nicht nur in Großkonzernen, aber typischerweise irgendwelche Sachen, Konzerne, Firmen, Projekte wo es etwas träger zugeht und ich kann das nicht machen. Es gibt das große Deployment alle drei Monate, große Zeremonie, alle müssen am Wochenende arbeiten, damit das gemacht werden kann, weil man dann offline gehen muss, es gibt 1000 Gründe dafür. Das ist jetzt nicht nur Konzernzähigkeit und fehlende Kommunikation, sondern auch fehlende Tests, den Entwicklungsprozess mit irgendwelchen Quality-Gates, die manuell durchgewunken werden müssen, es gibt 1000 Gründe. Wenn man das hat, dann bin ich halt drei Monate ungeschützt. Nehmen wir mal an, Lockwood J ist da aufgetreten, sind aber noch zwei Monate bis zum nächsten Deployment. Was mache ich denn dann? Da gibt es oft irgendwelche Möglichkeiten oder Sachen, dann sagen wir, wir machen trotzdem einen Hotfix, dann ist aber ein großer Alarm und was weiß ich was. Die andere Lösung ist, es gibt jetzt eine Regel in der Firewall, die dann auch genutzt wird und dann sind wir jetzt auch mal sicher. Da wäre es eigentlich besser, wären zwei Sachen deutlich besser. A Ich muss meine Deployment Fähigkeit erhöhen. Eigentlich muss ich immer in der Lage sein, immer zu deployen, wenigstens solche Hotfixes. Es muss ja nicht sein, dass ich ein Feature neu deploye, aber ein Hotfix müsste ich eigentlich sozusagen in der Zeitspanne sofort deployen können. Das ist das eine und das andere, es wäre natürlich gut, wenn ich auch weiß, wie ich solche Fixes machen. Das Core Ruleset kommt von der OWASP, es gibt die OWASP Top Ten, wo die zehn größten Sicherheitsrisiken beschrieben werden für Webanwendungen. Wenn ich denen aus dem Weg gehen könnte, weil ich weiß, wie die funktionieren, weil ich weiß, wie man die ausnutzen kann und weiß, was ich dagegen tun kann, dann wäre das wahrscheinlich viel besser, als sich mit trügerischer Sicherheit auf eine Firewall zu verlassen und dafür viel Geld zu bezahlen.
Lisa: Also wäre das quasi deine Alternative zu Firewalls, die OWASP Top Ten kennen und sich davor schützen?
Christoph: Ja, also wäre schön, wenn man noch ein bisschen mehr, als die OWASP Top Ten kennt, ist jetzt auch nicht eine hundertprozentige Alternative zur Firewall. Wie gesagt, es gibt Gründe, aber es wäre besser, anstatt sich auf eine Firewall zu verlassen, was halt viele tun und sagen, Sicherheit ist gewährleistet durch die Firewall, auch vom BSI empfohlen, sondern dass ich die Ursachen bekämpfen kann. Und wenn ich die Lücken nicht mehr habe, die ausgenutzt werden können und sichere APIs anbieten kann, einen sicheren Service, dann wäre das natürlich viel besser. Die Ursache da bekämpfen und die OWASP Top Ten bieten sich halt schon als Einstieg dafür, dass man mit denen anfängt. Nicht irgendwelche esoterischen Sicherheitslücken, sondern da fängt man bei denen an, dann hat man schon mal eine sehr, sehr gute Basis geschaffen, um zu sagen “Ja, da kenne ich mich aus, darauf habe ich geachtet. Ich bin deutlich weniger gefährdet und ich muss mich nicht auf die Firewall verlassen.”
Lisa: Angenommen ich möchte mich mehr mit den OWASP Top Ten befassen. Hast du da einen Tipp, wie ich das machen kann?
Christoph: Natürlich. Jetzt kommt der kleine Werbeblock hier, ganz neu bieten wir an bzw. im Moment bin das ich, der das als Trainer anbieten kann, ist ein OWASP Top Ten Training. OWASP Top Ten in der Praxis heißt das. Damit kann man sich auf so was vorbereiten, dass man erst mal die OWASP Top Ten kennenlernt, dann lernt, die zu vermeiden und wie diese funktionieren. Es würde sich anbieten, so was mal zu machen, also jedem Webentwickler würde sich sowas anbieten, das zu machen. Das ist der erste Einstieg, wie kann ich sozusagen sichere Services im Internet anbieten? Habe natürlich überhaupt keinen Bias, ich finde es das beste Training ever. Ja, das hat seinen Grund, weil das ist im Gegensatz zu vielen anderen Trainings sehr praxisorientiert. Das ist nicht so, wir machen viele Folien und erklären da was und sieht alles ganz toll aus, sondern wir machen da so einen Wechsel der Perspektive. Wie funktioniert das? Ich stelle trotzdem erst mal natürlich die OWASP Top Ten vor, versuche so ein bisschen zu erklären, wie es im Allgemeinen funktioniert. Aber dann müssen die Teilnehmer und Teilnehmerinnen versuchen, die OWASP Top Ten auszunutzen, und zwar indem sie die Rolle der Angreifer und Angreiferin annehmen. Es gibt dann eine kleine Anwendung, wo absichtlich Fehler eingebaut sind an gewissen Stellen und die müssen die dann ausnutzen und zwar unter Zuhilfenahme von ihrem Browser, den Dev Tools, Google Kenntnisse sind vielleicht auch nicht schlecht. Manche Sachen lassen sich auch gut googlen. Ja, das ist schon wichtig, die Zuhörerenden sehen das nicht, du musstest es so ein bisschen grinsen. Wenn man die Perspektive der Angreifer nimmt, die Googlen ja auch, gibt es schon fertige Exploits, wie kann ich was ausnutzen und hacken sich dann schnell was zusammen. Und wenn ich weiß, wie ich solche Informationen finde, ist das schon ganz gut. Ja und mit den Informationen und ein paar Tipps von mir versuchen sie sich da rein zu hacken. Und wenn sie das geschafft haben, dann gibt es das für die einzelnen Themenbereich noch mal etwas schwerer. Wenn das ein öffentliches Training ist, sind die Teilnehmerinnen oft sehr heterogen von den Vorkenntnissen und dann haben die, die dann schnell fertig sind, auch noch was zu tun. Und die, die etwas langsamer sind, müssen dann nicht abbrechen und das schaffen dann auch die Gruppen normalerweise. Man gibt dann ein bisschen wie gesagt, Hilfestellung dazu. Dann haben sie erst mal die andere Perspektive, was erst mal ein riesiges Aha-Erlebnis bei vielen Teilnehmerinnen erzeugt. Aha, so einfach geht manches. Und aha, so denken manchmal auch die Angreifer. Der Bruce Schneier, ein berühmter Security Forscher, hat noch mal gesagt, muss auch dieses Hackers Mindset einnehmen. Wenn man mit Sicherheit zu tun hat, muss man nicht denken, wie kriegt man ein System zum Laufen, wie funktioniert das, sondern wie kann es kaputt machen? Das fehlt oft und dieser Perspektivwechsel hilft da. Aber das ist nicht alles, weil das richtet sich ja nicht an angehende Penetrationstester und Testerinnen, sondern das richtet sich an Entwickler und Entwicklerinnen. Und dann schauen wir uns dem Source Code an, was da falsch ist. Dann wird normal gefragt, was könnte man da besser machen und wie anders? Und dann fällt auch auf, welche Details man beachten muss, weil meistens sind die ersten zwei drei Sachen entweder nur ein halber Fix oder gar kein fix oder ein eher schlechter Fix, wo man sagt, man kann es prinzipiell besser machen. Dann ist das so das zweite Aha-Erlebnis. Aha, da muss ich jetzt auf die Details achten an der Stelle. Dann kommt man da zusammen und dann geht man so die Sache durch, in den späteren wird es dann etwas schwieriger und man muss ein bisschen kombinieren. Aber auf jeden Fall hat man dann sehr viel getan dabei und hat so richtig die praktische Erfahrung, und zwar von beiden Seiten. Ich finde das eigentlich ein relativ gutes Training dafür. Es gibt bestimmt auch woanders gute Trainings, aber gerade bei solchen Sachen, meiner Ansicht, der Praxis Anteil sehr, sehr wichtig. Das kann man nicht so gut aus Folien lernen, da lernt man andere Inhalte. Wenn man viele Folien macht, dann hat man einen großen Überblick und hat überhaupt erst mal was von den Sachen gehört und weiß dann Aha, da sollte ich mal drauf achten. Aber wenn ich dann wirklich darauf achten muss auf irgendwelche Dinge, dann muss ich es mal ausprobiert haben. Und das macht man indem. Wie gesagt, das ist jetzt neu im Programm. Ich hatte das schon mal in Workshops gemacht, in Einzelworkshops, in verkürzter Form. Daher kommen jetzt auch die Erfahrungen, wenn ich sage die Teilnehmer schaffen das auch immer alle. Das ist jetzt wirklich eine Erfahrung davon. Und jetzt ist das halt in so einem schönen zwei Tage Training verpackt. Der erste Termin öffentlich ist der 10.-11. Mai in Düsseldorf, ist ein vor Ort Training. Aber man kann sowas natürlich auch immer anfragen, wenn man das intern für die Firma braucht, dann kann man auch so was anfragen. Jetzt bin ich ganz rot geworden, weil ich so viel Eigenwerbung für mich gemacht habe und mich so über den grünen Klee gelobt habe. Ja, aber muss manchmal auch mal so sein. Es wird keiner gezwungen, das zu buchen, aber ich lege es euch echt ans Herz.
Christoph: Und alle Hörerinnen, die ich überzeugt habe, beim Training an Düsseldorf am 10. Und 11. Mai dabei zu sein. Die bekommen von uns dann noch ein passendes Bücherpaket geschenkt, bestehend aus Hacking APIs, APIs Security in Action und wahlweise Black Hat Go oder Black Hat Python. Je nachdem, welche der beiden Programmiersprachen euch da mehr zusagt. Dazu müsst ihr dann einfach nach der Buchung eine Mail an [email protected] schicken, darin hier auf die Podcastfolge verweisen und Name, Adresse, Bestellnummer usw. angeben. Dann können wir euch das dann zusenden.
Lisa: Schöner Werbeblock, Christoph. Wir hätten noch eine Musik einspielen müssen, so einen kleinen Jingle vorher und danach. Möchtest du denn zum Thema Firewalls noch irgendwas sagen oder wollen wir das einfach abschließen, das Thema?
Christoph: Inhaltlich haben wir, glaube ich, das meiste so gesagt, dabei jedenfalls überblicksmäßig. Damit muss man sich auch mal in der Praxis beschäftigen. Aber was ich ganz wichtig find, Firewall sollte man ganz sicher benutzen, aber das bietet jetzt erstmal keine Sicherheit. Man sollte aufpassen, dass man sich nicht damit sagt, das ist jetzt okay. Das ist wie beim Autofahren, Wenn ich einen Airbag habe, sollte ich trotzdem nicht mit 300 durch kurvige Straßen fahren, weil ich dann irgendwann am Straßengraben lande oder vorm Baum, dann nutzt vielleicht auch der Airbag dann nichts mehr. Also keine falsche Sicherheit, Firewalls wichtig, sollte man nutzen. Aber es gibt noch 100.000 andere Dinge, die noch dazu gehören, um sichere Software zu haben im Web.
Lisa: Das war ein sehr schöner Abschluss, muss man nicht mit dem Werbeblock enden. Dann vielen, vielen Dank, Christoph, für die Folge. Ich habe viel mitgenommen für mich und ich bin dir dankbar, dass wir das aufbereitet haben. Ich hoffe, wir konnten dem Wunsch der Zuhörer entsprechen, die das Thema sich gewünscht hat. Falls ihr da draußen irgendwelches Feedback an uns habt, dann sendet uns das gerne als Mail an [email protected]. Wenn euch der Podcast gefällt, dann könnt ihr uns gerne bewerten oder uns auch weiterempfehlen. Und ich bedanke mich recht herzlich, dass ihr heute zugehört habt und sage bis zum nächsten Mal!
Christoph: Ciao!