Entwicklung einer Web 2.0 Firewall

Waren Webseiten in den 1990er Jahren noch statische Objekte zur reinen Informationsdarstellung, so besteht die Landschaft des heutigen Web 2.0 aus durchwegs bunten, interaktiven Webpräsenzen, die standardmäßig auch eine Bereitstellung von Informationen durch ihre Nutzer vorsehen, etwa mittels Kommentaren oder Uploads. Diese veränderte Umgebung macht vor dem typischen Bildschirmarbeitsplatz in Organisationen der öffentlichen Hand nicht halt: Auch wenn während der Arbeitszeit im Browser hauptsächlich Anwendungen des eigenen Intranets aufgerufen werden, so ist doch ein kurzer Seitenblick auf eine der Google-Seiten zur Beschaffung weiterer Informationen inzwischen der Normalfall. Genauso haben Personaler für sich entdeckt, während der Dienstzeit Facebook und andere soziale Netzwerke zum routinemäßigen Abklopfen von Bewerbern zu nutzen. Ganz zu schweigen von der Nutzung von Web-2.0-Seiten während der Mittagspause oder bei kurzen, fachfremden Zugriffen während des Tages: Der Zugriff auf Web-2.0-Inhalte am Arbeitsplatz ist, wird er nicht durch Filterung einer Firmen-Firewall geblockt, heutzutage üblich.

Problematisch sind hierbei nicht die vordergründigen Inhalte der aufgerufenen Seiten. Denn in Zeiten, in denen Firmen verstärkt mit Blogs, Twitter-Meldungen und YouTube-Kanälen auf sich aufmerksam machen, ist es teilweise sogar erwünscht, dass Mitarbeiter neben ihrer normalen Tätigkeiten bspw. durch Networking die Werbung neuer Kollegen vorantreiben. Zur Gefahr werden kann aber ein Missbrauch der überaus mächtigen Frameworks, mit denen die diversen Seiten realisiert sind: War beim „alten“ Web noch alles statisch, so lebt das neue, unter dem unscharfen Begriff Web 2.0 zusammengefasste Netz davon, dass auch auf Client-Seite, also im Web-Browser des Kunden oder Interessenten, einiges an Programmlogik abläuft. Dies kombiniert mit der Fähigkeit, ohne komplettes Neuladen der Seite eine schnelle Kommunikation zwischen Web-Browser und Server darzustellen und einzelne Inhalte schnell nachzuladen, gibt einem Angreifer allerhand Werkzeug an die Hand. Und damit lässt sich schon einiges anstellen: Ausspähen von Informationen aus dem lokalen Verlauf des Browsers, Beobachten von Sitzungen oder Nutzung des Clients als unwissende Plattform für weitere Angriffe. Der Kreativität sind hier keine Grenzen gesetzt. Möglich wird dies, weil die Darstellung aktiver Inhalte – angefangen bei JavaScript – heute in Browsern unverzichtbar aktiviert ist, denn sonst bleiben die meisten Seiten „dunkel“.

Hier wäre es also wünschenswert, dass man nicht nur „den großen Hebel umlegen“ und die Web-2.0-Technologien damit komplett verbannen kann, sondern dass auch eine feingranularere Aufstellung von Richtlinien möglich ist. So könnte ein Administrator festlegen wollen, dass zwar generell keine Web-2.0- Seiten aufgerufen werden dürfen, aber dass die interaktive Ansicht von Google Maps z. B. zur Planung von Dienstreisen schon funktionieren soll – auch im ansonsten streng abgesicherten internen Firmennetz. Nun ist es für das Projekt aber nicht genug, eine herkömmliche URL-Filterung vorzunehmen, etwa in der Hinsicht, dass jeglicher Inhalt von maps.google.de die Firewall einfach passieren darf. Denn erstens möchte man vielleicht nur eine von vielen Seiten auf einem bestimmten Host erlauben. Zweitens sind, gerade durch die von Sicherheitsexperten wie Dan Kaminsky gezeigten Angriffe auf das Internet-Namenssystem, DNS-Täuschungen möglich, sodass ein Angreifer theoretisch für kurze Zeit selbst für eine Firma als maps.google.de erscheinen kann – genug Zeit, um schadhaften Code zu platzieren. Und drittens sind selbst die SSL-Sicherheitszertifikate, die die Zugehörigkeit von bestimmtem Inhalt zu einer Internet Domain sicherstellen sollen, nach neuerlichen Analysen von Experten wie Moxie Marlinspike und anderen in Verruf geraten.

Es ist also klar, dass man sich in puncto Sicherheit nicht auf „Umverpackungen“ verlassen, sondern die transportierten Inhalte und damit auch die transportierten Web-2.0-Logiken selbst analysieren können möchte. Die transportierten Logiken werden im Rahmen des Projekts übrigens als Overlays betrachtet, also als zusätzliche Transportschichten, die durch Umfunktionieren von Anwendungsschichten (sog. Overlaying) entstehen. So wird etwa gerade das Hypertext-Transportprotokoll HTTP heute zu deutlich mehr Zwecken verwendet als eben nur zum Transport von Texten mit MarkupLanguage (HTML). Gerade HTTP 1.1 mit seinen persistenten Verbindungen und HTML5 mit der Erweiterung der Websockets spannen hier den Bogen weit.

Um aber trotzdem wieder Kenntnis von echten Inhalten nehmen zu können, muss zunächst eine Entwirrung der vielen geschichteten Transportprotokolle vorgenommen werden. Diese Auftrennung erlaubt erst danach wieder eine semantische Analyse des eigentlich transportierten Inhalts. Zur schnellen Klassifizierung der vorbeirauschenden Inhalte wird eine Anleihe bei einem verwandten Gebiet genommen: Netzwerk-basierte-Intrusion Detection Systeme (NIDS) stellen sich vom Prinzip her auch die ganze Zeit lauschend an den Verkehr etwa eines ganzen Netzsegmentes und versuchen, aus den vorbeifliegenden Mustern diejenigen zu extrahieren, die auf Anomalien (Abweichungen vom Normalzustand) oder sogar speziell auf laufende Angriffe innerhalb des Netzwerks hindeuten. Um die verwendeten NIDS leicht auf das jeweilige Problem anpassen zu können, soll im Projekt PADIOFIRE auch noch eine Sprache entwickelt werden, mit der vom IDS zu erkennende Inhalte der Web-2.0-Kommunikation in Regelsätzen beschrieben werden können. Mit der speziell für die Overlay-Analyse angepassten NIDS-Technologie ist das erste Teilziel von PADIOFIRE erfüllt, nämlich die Overlay- und Anwendungsprotokoll-Analyse durch IDS-basierte Regelsprachen. Nun ist nur noch das Problem der Leistungsfähigkeit des Gesamtsystems in den Griff zu bekommen: Heutige Netzwerkverbindungen arbeiten im Bereich von 1 bis 10 GBit/s. Eine aussagekräftige Analyse der eintreffenden Datenströme muss also von vornherein mit der Anzahl der eingesetzten Rechnersysteme oder mindestens der Prozessorkerne innerhalb eines eingesetzten Systems skalieren, sonst ist das Unterfangen mit steigender Bandbreite schnell unmöglich. Um die Arbeit sinnvoll auf mehrere Systeme oder Kerne zu verteilen, ist ein strombasierter Ansatz empfehlenswert. Das bedeutet, dass alle Datenpakete, die zu einer einzelnen logischen Verbindung gehören, auch vom selben Analysesystem bearbeitet werden müssen – sonst fehlt wichtiger Kontext für die Analyse. Das Aufspalten des kompletten Netzwerkverkehrs in separate, den einzelnen Kommunikationsbeziehungen zugeordnete Ströme soll durch das bereits bestehende, im Forschungsprojekt HISTORY entwickelte Toolkit „Vermont“ erledigt werden. Damit ist als Teilziel des Projekts das effiziente Monitoring und die parallele Erkennung auf Multicore-Systemen erfüllt.

Das Projekt PADIOFIRE wird vom Bundesministerium für Bildung und Forschung gefördert.