Schleichwege durch die Firewall Schleichwege durch die FirewallEin- und abgehenden Datenverkehr zu regulieren ist weiterhin die wohl wichtigste Maßnahme, um das eigene Netz zu schützen. Etliche Protokolle und Mechanismen lassen sich allerdings missbrauchen, um die äußere Verteidigungslinie zu untertunneln. Das prominenteste Beispiel sind vermutlich SSL-verschlüsselte Web-Aufrufe, deren Inhalt der Prüfung durch Firewalls, Anti-Malware-Scannern und Intrusion Detection Systems nicht ohne weiteres zur Verfügung steht. Doch es gibt noch etliche andere "Covert Channels", die teilweise auch bidirektional nutzbar sind. Selbst Sicherheitsmechanismen schaffen hier bisweilen zusätzliche Risiken.
So ermöglichen beispielsweise HTTP-Proxies die Nutzung des World Wide Web, ohne den Benutzern eine direkte Verbindung ins Internet zu gestatten. Proxies sind daher zu einem integralen Bestandteil moderner IT-Netzwerke avanciert und bieten diverse Kontrollmöglichkeiten wie Authentifizierung der Benutzer, Limitierung des Datenvolumens und die mögliche Definition verbotener Webseiten oder Domänen, sodass eine angemessene Nutzung des WWW entsprechend der IT-Nutzungs- und Sicherheitsrichtlinien gewährleistet ist.
![[Illustration]](04-6-058-1.jpg)
Erlaubte und zu unterbindende Kommunikationswege
Was für die "normale" HTTP-Nutzung ein Segen ist, wird durch die Erweiterung auf gesicherte Verbindungen (HTTPS) zum Problem. Um die Ende-zu-Ende-verschlüsselten Verbindungen im Zusammenspiel mit einem Proxy nutzen zu können, bedarf es eines besonderen Modus, der den Proxy-Server anweist, alle Daten einfach an die Gegenstelle weiterzuleiten – denn, dieser hat ja ebenso wenig Möglichkeiten, auf den Inhalt der Anforderungen zuzugreifen, wie sonstige "Dritte" auf dem Transportweg. Eine HTTPS-Sitzung wird daher dem Proxy mit einem speziellem Kommando angekündigt: "CONNECT www.example.com:443 HTTP/1.0" – in diesem Fall mit dem HTTPS-Standard-Port TCP 443.
Anders als bei ungeschützten HTTP-Sitzungen, in denen der Proxy die Anfragen analysieren und einzeln verarbeiten kann, besteht aufgrund der Verschlüsselung keine Interpretations- oder Filtermöglichkeit. Sofern keine weiteren Prüfungen oder Einschränkungen existieren, ermöglicht dies somit beliebige (auch Nicht-HTTPS-basierende) Verbindungen durch den Proxy zu leiten. Die meisten Instant-Messenger-(IM-)Programme (vgl. S. 64) unterstützen inzwischen die Anbindung an ein Chat-Network via HTTPS-Connect am Proxy. Auch bei vielen anderen Anwendungen ist dieser Trend zu beobachten; zusammen mit der anstehenden Verbreitung von SOAP-Anwendungen (Simple Object Access Protocol) drohen sich HTTP-Proxies zum allgemeinen Applikations-Gateway für das Netzwerk zu entwickeln.
Eine einfache Eingrenzung des Missbrauchs am Proxy ist die Beschränkung von HTTPS-Connects auf den TCP-Port 443. Für mehr Sicherheit besteht die Möglichkeit, den durchgehenden Verkehr auf Konformität mit dem HTTPS-Sicherheitsstandard SSL (bzw. TLS) zu prüfen; leider bieten aber nur sehr wenige Produkte diese Funktionalität. Die umfassendste Lösung sind spezielle HTTPS-Proxies, die durch eine eigene Public Key Infrastructure (PKI) und diverse technische Tricks ermöglichen, HTTPS-Verbindungen am Proxy "umzuschlüsseln": Somit lässt sich nicht nur der Datenstrom auf Malware und unerwünschte Inhalte inspizieren, sondern auch der Missbrauch des HTTPS-Connect-Features wirksam unterbinden, da Anfragen, die keine gültigen HTTP-Anfragen innerhalb der SSL-Session enthalten, von den HTTPS-Proxies nicht verarbeitet werden.
Auch das gänzliche Sperren von HTTPS-Sitzungen auf dem Proxy würde übrigens keinen vollständigen Schutz vor Missbrauch garantieren: So genannte HTTP-Tunnelsoftware ermöglicht es, Datenverbindungen in regulären Web-Anfragen zu verstecken (z. B. HTTPtunnel, ![[externer Link]](../../../../images/link.gif)
www.nocrew.org/software/httptunnel.html). Allerdings ist der damit verbundene Aufwand relativ hoch, da hierfür die entsprechende Software auch auf der Gegenseite im Internet installiert werden muss. Steht ein solcher Tunnel allerdings erst einmal, so sind auch eingehende Anfragen ins Firmennetz möglich.
Besonders leicht ließe sich so ein bidirektionaler Tunnel allerdings mithilfe eines frei zgänglichen HTTPS-Connects am Proxy durch das SSH-Protokoll (Secure Shell) einrichten, das innerhalb etablierter SSH-Sitzungen per Port-Forwarding oder Port-Tunneling beliebige Datenverbindungen ermöglicht: ausgehend wie eingehend und zwar nicht nur für TCP, sondern auch für UDP.
Solche Kommunikationswege umgehen naturgemäß alle vorhandenen Sicherheitsmaßnahmen und erhöhen somit das Gefährdungspotenzial für die gesamte IT-Umgebung enorm – zudem sind sie nur schwer aufzudecken. Schon jetzt ist es gang und gäbe, dass "findige" Mitarbeiter dieses SSH-Feature nutzen, um Zugriff auf private E-Mails der andere Netzdienste zu erlangen, den die firmeneigene Firewall aus gutem Grund verwehrt.
Besonders beunruhingend wird dieser Ansatz, wenn man bedenkt, dass es nicht nur möglich ist einzelne TCP/UDP Ports weiterzuleiten, sondern auch eine Anbindung auf Netzwerkebene aufzubauen: OpenVPN ( http://openvpn.sf.net/) ist eine freie Software, die ein vollwertiges Virtual Private Network (VPN) auf (Open-)SSL-Basis implementiert und lediglich einen einzigen UDP- oder TCP-Port benötigt – und somit auch mittels HTTPS-Connect über Proxies funktioniert. Zwar ist diese Software noch relativ unbekannt, das dürfte sich aber in naher Zukunft ändern, da sie in etlichen Umgebungen eine gute Alternative zu IPsec-Lösungen darstellt, weil mit OpenVPN/SSL weder Interoperabilitätsprobleme zwischen den gängigen Betriebssystemen noch Einschränkungen durch Anbindungen mit Network Address Translation (NAT) auftauchen.
Einen Schritt weiter in Sachen Tarnung geht die Software NSTX ( http://nstx.dereference.de/nstx/), die Anfragen des Domain Name System (DNS) nutzt, um einen versteckten Kanal zu etablieren. Sind nicht nur netzwerkinterne DNS-Anfragen möglich, sondern auch das Abfragen von DNS-Einträgen im Internet, so kapselt NSTX beliebige IP-Pakete in syntaktisch korrekte DNS-Anfragen, die durch einen entsprechenden NSTX-Server im Internet empfangen, dekodiert und weitergeleitet werden. Lediglich das ungewöhnliche DNS-Datenaufkommen könnte dann gegebenenfalls beim Administrator einen Verdacht wecken; oftmals unterbleiben aber Netzwerkmetriken, die das aufdecken könnten. Am Rande bemerkt sei, dass diese Technik auch eine kostenfreie (aber rechtlich sehr bedenkliche) Nutzung von WLAN-Hotspots ermöglicht: Alle vom Autor bisher getesteten WLAN-Anbieter leiten DNS-Anfragen weiter, auch ohne dass man sich zuvor in das System eingebucht hat.
----------Anfang Textkasten----------
Bei der Betrachtung von Schleichwegen durch Netzwerke sollte man eine fundamentale Wahrheit beachten: Es ist unmöglich, jedwede versteckte Kommunikation zu unterbinden. Allein schon durch das Eintreten oder Ausbleiben von Ereignissen (Web-Seite besucht, Licht angelassen, ...) kann man Informationen unbemerkt – und nahezu unermittelbar – kommunizieren.
Lenkt man sein Augenmerk jedoch von der geheimen Kommunikation als solcher auf die Kommunikation über nicht-offensichtliche Kanäle, so zeigt sich ein etwas anderes Bild: Daten unbemerkt aus einem Netzwerk herauszuschmuggeln ist mit subtileren Methoden möglich als beispielsweise über eine SSH-Verbindung (etwa innerhalb digitaler Signaturen). Einen für Netzwerkverbindungen nutzbaren Kommunikationskanal herzustellen, bedingt jedoch gänzlich andere Eigenschaften: niedrige Latenzwerte und mehr oder weniger hohe Datendurchsatzraten.
Somit sind die durch Protokoll und Infrastruktur bedingten Eigenschaften der Netzwerkdienste primär maßgeblich für die Robustheit gegen ungewollte Nutzungsweisen. Leider sind es genau diese Eigenschaften, die es einem Netzwerkdienst oft erst ermöglichen, einen konkreten Wert zu entwickeln. Um einen erfolgreichen Spagat zwischen diesen Anforderungen zu erreichen, bedarf es einer weiteren Methodik: der Typisierung der zu transportierenden Daten (Payload). Aktuelle Protokolle lassen jedoch diesen Aspekt gänzlich vermissen: Sie definieren in der Regel nur die Typisierung der Strukturdaten – die Nutzdaten bleiben aber oftmals vollkommen unstrukturiert und somit unüberprüfbar.
Lediglich das SOAP-Protokoll bietet teilweise zufriedenstellende Regularien, die entsprechende SOAP-Firewalls auch heute schon tatsächlich prüfen; leider sind auch hier wichtige Protokollanteile unreguliert. Um die wachsenden Gefahren durch den Missbrauch von Applikationsprotokollen einzudämmen, werden in diesem Bereich signifikante Fortschritte notwendig sein.
----------Ende Textkasten----------
Es wäre fatal, die bestehenden Sicherheitsprobleme nur den Projekten oder Individuen zuzuschreiben, durch deren Arbeit die Umgehung von Sicherheitsmaßnahmen ermöglicht wird. Denn das eigentliche Problem liegt in der sicherheitstechnischen Unreife der "modernen" Netzwerke. Angreifer können auf vielen Ebenen die Unzulänglichkeiten weit verbreiteter Protokolle missbrauchen: angefangen beispielsweise bei ARP-Spoofing auf Datenverbindungsebene in LANs (vgl. S. 70) über IP-Spoofing auf Netzwerkebene bis hin zu Packet Insertion und Session Hijacking auf Transportebene und einem weit gefächerten Areal von Fälschungen und sonstigen Untaten auf Applikationsebene (Spam, Malware, ... und nicht zuletzt der hier behandelte Missbrauch). Alleine die Langwierigkeit des Übergangs von IPv4 auf IPv6 sollte ein Indiz dafür sein, dass es nahezu unmöglich ist, auch nur die beispielhaft genannten Misstände auf den unterschiedlichen Protokollebenen kurzfristig anzugehen.
Auch wenn weitere Möglichkeiten existieren, um "unplanmäßige" Kommunikationswege über Netzwerkgrenzen hinweg anzulegen, so sind doch die dargestellten Methoden die populärsten im Kreise derer, die sich solcher Mechanismen bedienen. Die "Nebenwirkungen" solcher Szenarien überwiegen oftmals auch die direkten Verluste: So mancher Arbeitgeber mag zwar von weit reichenden Konsequenzen absehen, wenn ein Mitarbeiter solche Software zu "harmlosen" Zwecken einsetzt – spätestens aber bei auftretendem Informationsdiebstahl, eindringender Malware oder einer Haftbarkeit gegenüber Dritten dürften Fragen nach der Verantwortlichkeit und der Effektivität der IT-Sicherheit gestellt werden. Langfristig bleibt wohl auch offen, ob die derzeit genutzten Protokolle auch in Zukunft die Bedürfnisse aller Involvierten abdecken können – die Sicherheitsanforderungen werden dabei ganz bestimmt nicht abnehmen.
Jürgen Pabel, CISSP (jpabel@akkaya.de), arbeitet als Berater für IT-Sicherheit bei der Akkaya Consulting GmbH.
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2004#6, Seite 58
| 