Löcher in der Firewall mit WebSockets

Löcher in der Firewall mit WebSockets

Das Internet befindet sich im ständigen Wandel. Und auch hinter der bunten Oberfläche spielt sich so einiges ab: Web-Anwendungen suchen für ihre Protokolle den Weg des geringsten Widerstands, während Administratoren die Datenströme in ihren Netzen kontrollieren wollen. In diesem Beitrag erfahren Sie am Beispiel von WebSockets, wie sich bei diesem Wettlauf Anwendungen immer neue Wege suchen, um sich einer Kontrolle durch Firewalls zu entziehen.

Vor langer, langer Zeit, als das Internet noch jung und unbekannt war, gab es verschiedene Protokolle zur Kommunikation, beispielsweise für den Transport von Mail oder Dateien, den Zugriff auf Newsgruppen oder auch auf das noch kleine World Wide Web. Für jedes dieser Protokolle wurde ein eigener Port, d. h. quasi ein eigener Briefkasten im Mehrparteienhaus des Computers, reserviert und analog zur Telefonie wurde eine Verbindung zwischen den einzelnen Steckplätzen, sogenannten "Sockets", der Kommunikationspartner hergestellt. Einzelne Protokolle wie FTP benutzten darüber hinaus zusätzlich dynamisch ausgehandelte Ports. Für die noch jungen Firewalls war die Aufgabe einfach – man brauchte nur den Zugriff auf einen dieser Ports zu sperren, um so die Nutzung der entsprechenden Applikation zu unterbinden.

Grafik veranschaulicht Portfilter zur ZugriffsbeschränkungEinfacher Portfilter zur Zugriffsbeschränkung

Mit der zunehmenden Nutzung des Internet für kommerzielle und private Zwecke entstanden Protokolle, die sich nicht mehr auf feste Ports beschränkten. Dazu gehörten z. B. Peer-To-Peer Anwendungen, die explizit versuchten, die existenten einfachen Filtermaßnahmen zu umgehen. Dieses führte dazu, dass in Firmen und öffentlichen Netzen restriktive Firewalls eingerichtet wurden, die letztendlich nur noch den Zugriff auf die Ports 25 (SMTP, d.h. Mail) sowie 80 und 443 (HTTP und HTTPS, d. h. Web) erlaubten. Um trotz der Restriktionen weiterhin zu funktionieren, verlagerten Anwendungen wie Instant-Messengers (IM) ihre Kommunikation in das Web oder entwickelten wie beispielsweise Skype ausgefeilte Mechanismen, um durch Firewalls zu tunneln.

Grafik veranschaulicht Blockierung durch PortfilterEinfacher Portfilter blockiert IM, Skype weicht auf Web aus

Aber das simple Web-Kommunikationsmodell, bei dem der Client (z. B. der Browser) eine Anfrage stellt und der Server die Antwort liefert, ist für viele Anwendungen unzureichend: So kann z. B. ein Server dem Client eine neue Nachricht nicht direkt zustellen. Stattdessen müssen ressourcenintensive Workarounds genutzt werden, wie z. B. ein ständiges Nachfragen des Clients beim Server. Daher wünschten sich die Applikationsentwickler die Zeit zurück, in der unbeschränkte Kommunikation zwischen Client und Server möglich war.

WebSockets für direkte und unbeschränkte Kommunikation

Diesem Wunsch kann durch den Einsatz von WebSockets entsprochen werden: Da direkte Verbindungen zwischen den klassischen Sockets durch Firewalls nicht mehr möglich sind, wird für eine Verbindung zwischen WebSockets zuerst eine Web-Verbindung aufgebaut, um über diese die eigentlich gewünschte Verbindung zu tunneln.

Für Freunde der OSI-Schichtenmodells heißt das: Wir erstellen innerhalb der Applikationsschicht eine neue Transportschicht und darauf packen wir eine weitere Applikationsschicht. Oder anders ausgedrückt: Wir lösen die Probleme mit dem bisherigen Workaround, indem wir einen weiteren Workaround hinzufügen. Natürlich produziert das gegenüber der "korrekten" Lösung Overhead und die Performance sinkt, aber Bandbreite wird ja billiger und Rechner werden schneller.

Grafik: OSI Layer mit Transport- und Anwendungsschicht innerhalb der AnwendungsschichtOSI Layer mit Transport- und Anwendungsschicht innerhalb der Anwendungsschicht

Aus Sicherheitssicht bedeutet das letztendlich das Bohren von Löchern in die Firewall, über die beliebige Kommunikation unkontrolliert laufen kann. Ein möglicher Ansatz ist es, diese Löcher zu stopfen, indem man das Upgrade zu WebSockets verhindert. Mit einer Application-Level-Firewall wie der genugate ist das relativ einfach und genau das ist es auch, was wir aktuell tun. Im Moment ist dieses Vorgehen akzeptabel, da es noch viele Browser, Proxies und Applikationsserver ohne Unterstützung für WebSockets gibt und die Anwendungen daher auf schlechtere Mechanismen zurückgreifen, wenn WebSockets nicht funktionieren.

Längerfristig müssen WebSockets jedoch zumindest für ausgewählte Anwendungen ermöglicht werden, idealerweise mit der Möglichkeit zur anwendungsspezifischen Inspektion der Inhalte. Dies wird jedoch schwierig, da zwischen WebSockets keine standardisierten Protokolle gesprochen werden. Stattdessen benutzt jede Anwendung und jedes Framework eigene Protokolle und kann diese auch jederzeit unangekündigt ändern.

Zu erwarten, dass sich Entwickler beim Design dieser Protokolle ausreichend Gedanken um die Sicherheit machen werden, ist wohl leider illusorisch, sodass wir hier in Zukunft mit neuartigen Angriffsmöglichkeiten rechnen müssen.

Lesen Sie auch: Firewalls – Stärken verschiedener Systeme kombinieren

 


Bildquelle: © Sergey Nivens - Fotolia.com


Diskutieren Sie mit

Sie können diesen Artikel sofort ohne Registrierung als Gast-User kommentieren.

Registrieren Sie sich jetzt! Mit einem User Account genießen Sie Vorteile:
Ihr Kommentar wird sofort im genublog veröffentlicht und Sie werden über Reaktionen auf Ihre Kommentare informiert.

Bereits registrierte User gelangen hier zum Login.



Registrieren Sie sich jetzt! Mit einem User Account genießen Sie Vorteile:
Ihr Kommentar wird sofort im genublog veröffentlicht und Sie werden über Reaktionen auf Ihre Kommentare informiert.

Bereits registrierte User gelangen hier zum Login.

Um für Sie unsere Webseite zu optimieren, verwenden wir Cookies.
Klicken Sie auf "Cookies zulassen", falls Sie der Nutzung von diesen Cookies zustimmen.
Weitere Informationen dazu finden Sie in unserer Datenschutzerklärung, in der Sie auch jederzeit Ihre Cookie-Einstellungen einsehen und anpassen können.
Datenschutz Cookies akzeptieren