Schleichpfade

Inhaltsverzeichnis

Viele Administratoren glauben, den Verkehr zwischen Intranet und Internet unter Kontrolle zu haben. Firewall und Proxies helfen ihnen dabei, Benutzer vom direkten und womöglich unkontrollierten Zugang zum Internet fern zu halten. Das Surfen im Web ist nur über einen HTTP-Proxy und für einige URLs erlaubt, der FTP-Download darf nur über den FTP-Proxy erfolgen. Peer-to-Peer-Protokolle sind gesperrt, um Saug-Orgien auf Kosten des Unternehmens zu verhindern. Oft ist auch der POP3-Zugriff auf die eigene Mail beim privaten Provider verboten, um zu verhindern, dass Viren am zentralen Mail-Scanner vorbei auf die Rechner gelangen. Doch solche Konzepte stehen auf tönernen Füßen. Vor allem technisch versierte Anwender finden immer einen Weg durch die Firewall ins Internet zu gewünschten Diensten. Wir zeigen gängige Schleichwege und Möglichkeiten sie zu blockieren.

Seit Jahren sind Tunneling-Techniken bekannt, mit denen sich solche Restriktionen umgehen lassen. Spezielle Clients auf Intranet-PCs kommunizieren mit modifizerten Servern im Internet. Dazu betten sie in Datenpakete erlaubter Protokolle, wie HTTP, FTP, DNS und ICMP, eigene Daten ein, die ein Tunnel-Server ausliest. Prinzipiell lässt sich jedes Protokoll für einen Tunnel missbrauchen. Wichtig ist nur, das dieses Protokoll durch die Firewall hindurchgeht. Auch muss der modifizierte Server im Internet unter der eigenen Kontrolle oder der eines Beauftragten stehen und die eingebauten Daten interpretieren können. Der Server reagiert dann je nach Client-Anfrage, beispielsweise in dem er Webseiten anderer Server zurückliefert oder Mail via POP3 abfragt und zurücksendet. Wie der Client muss auch der Server die Daten so in die Antwortpakete einbauen, dass sie durch Firewall und Proxy unverändert hindurchkommen.

Heimlichtuerei

Das Unternehmen HTTP-Tunnel bietet einen kommerziellen Tunnel-Client an, der sich zu speziellen Tunnel-Servern verbindet[1]. Die Firma betreibt eigens dafür mehrere Server im Internet, so dass man sich den den Aufbau eines eigenen sparen kann. Der Client arbeitet für lokale Applikationen als SOCKS-Proxy. Dazu muss er nur in der entsprechenden Applikation als Proxy eingetragen werden. Netzwerkpakete von Applikationen packt er in HTTP-Pakete und schickt sie entweder direkt zum Tunnel-Server oder an den HTTP-Proxy im Intranet. Von dort aus gelangt das Paket zum Tunnel-Server, der die Pakete auspackt und an ihr ursprüngliches Ziel weiterschickt. Damit später die Antworten auch wieder den Weg über den Tunnel nehmen, trägt der Server sich als Absender in die Pakete ein. Später kann er diese anhand einer Tabelle wieder dem jeweiligen Client zuordnen und zuschicken. So ist es trotz Firewall bei akzeptabler Bandbreite möglich, mit einem eDonkey- oder Kazaa-Client MP3-Dateien und anderes zu saugen. Auch Chat, Instant Messaging und sogar Windows Terminal Services sind damit möglich. HTTP-Tunnel kann mit wenig Aufwand fast jede SOCKS-fähige Applikation tunneln und unterstützt sogar die CONNECT-Methode für HTTP-Proxies. Damit muss man die Pakete nicht mehr in HTTP verstecken, sondern kann sie ohne "Umverpackung" verschicken.

Kollaborateur

Kollaborateur

Mit der CONNECT-Methode veranlasst ein Client einen Proxy, jedes Protokoll auf den Original-Ports weiterzuleiten, vorausgesetzt die Firewall erlaubt das. Ursprünglich zur Weiterleitung SSL-gesicherter HTTP-Verbindungen gedacht, lässt sich damit der Proxy zum Tunneln missbrauchen.

Da der Zugang ins Netz in fast allen Unternehmen zumindest über den Proxy erlaubt ist, können Netzwerkverantwortliche HTTP-Tunnel nur verhindern, in dem sie die Verbindung zu den Servern mit Firewall-Regeln verbieten. HTTP-Tunnel hat ständig 12 Server in Betrieb, die alle in die Regeln aufgenommen werden müssen. Das Abschalten der CONNECT-Methode im Proxy sollte lieber nicht in Betracht gezogen werden, ohne CONNECT funktioniert nämlich auch HTTPS nicht mehr.

Der Client arbeitet nur noch in der kommerziellen Version einwandfrei. Eine ältere, kostenlose Version 2.7.x wird zwar noch auf einigen Free- und Sharewareseiten angeboten, baut aber zu den Tunnel-Servern keine Verbindungen mehr auf. Immerhin kann man damit noch versuchen, über die CONNECT-Methode aus dem LAN auszubrechen. Eine richtig konfigurierte Firewall sollte diese Versuche blocken: Nur Verkehr über Port 80 und 443 darf nach draußen. Der HTTP-Tunnel-Server ist ebenfalls gegen Gebühr erhältlich, als Plattform dient jedes Windows-System, das WinSock unterstützt.

Mit dem GNU-httptunnel[2] gibt es auch eine kostenlose Open-Source-Implementierung. Das Paket besteht aus Client und Server und ist für Windows und Linux verfügbar. Beliebige Protokolle tunnelt es mit HTTP, allerdings ist der Aufbau paralleler Verbindungen nicht möglich.

Ganz ohne zusätzliche Programme kommen Anwender aus, die nur aus einem Firmennetz heraus ihren SSH-Server zuhause erreichen wollen. Der Windows-SSH-Client Putty unterstützt einen Verbindungsaufbau via Proxy und HTTP-CONNECT. Blockiert die Firewall Verbindungen auf den SSH-Port 22, kann der Mitarbeiter seinen SSH-Server zuhause auch auf den HTTPS-Port 443 verlegen. Über die eingebauten SSH-Tunnelfunktionen lassen sich dann auch weitere Verbindungen durch die Firewall leiten. So genannte Reverse-Tunnels (Option -r bei OpenSSH) drehen dabei die Datenflussrichtung um, sodass der Zugriff vom SSH-Server auf den Client im Unternehmensnetzwerk möglich ist. Die dort angelangten Pakete lassen sich dann zu anderen Servern weiter routen, etwa dem Mailserver. Benutzer von openssh können CONNECT-Tunnel mit dem Utility connect nutzen [5].

Namedropping

Selbst wenn gar keine Internet-Verbindung erlaubt ist, weder über HTTP noch über HTTPS, kann man manchmal trotzdem noch ins Internet gelangen. Voraussetzung dafür ist aber, dass im LAN ein Nameserver mit Verbindung zum Internet vorhanden ist. Mit dem Name Server Transfer Protocol (NSTX) ist es möglich, IP-Tunnel über Nameserver zu etablieren, in dem Benutzer eigene IP-Pakete in DNS-Anfragen und -Antworten einbetten [3]. Das Protokoll ist dabei RFC-konform, das heißt, die Pakete sind gültige DNS-Pakete -- allerdings durch die hinzugefügten Daten ziemlich aufgebläht. Die Funktion ist ähnlich dem HTTP-Tunnel, allerdings weitaus trickreicher, da DNS-Pakete eigentlich nicht für den Transport von Nutzdaten entworfen wurden. Man benötigt einen NSTX-Client und einen NSTX-Server. Der NSTX-Server arbeitet parallel auf einem DNS-Server im Internet und muss als "authorative" Nameserver registriert sein, also als Server, der den Namensraum einer Domäne verwaltet. Im Gegensatz zum Tunnel über HTTP sind die Hürden für einen praktischen Einsatz sehr viel höher. Schließlich muss die übergeordnete Instanz -- also etwa das DENIC -- den Verkehr an den Nameserver weiterleiten.

Die Funktionsweise eines DNS-Tunnels ist einfach erklärt. Der Client im Intranet fragt eine Internet-Adresse eines Servers im Internet, beispielsweise foo.bar.de, beim lokalen Nameserver (DNS) an. Da der lokale DNS die Domäne bar.de nicht selbst verwaltet, muss er dazu den Nameserver für diese Domäne, etwa ns.bar.de, befragen, der mit dem NSTX-Server bestückt ist. Der NSTX-Client bringt die Daten zur Kommunikation mit dem NSTX-Server im Host-Namen des angefragten Systems unter. Bei der Frage nach einem Rechner in der Domäne bar.de kann der Name beispielsweise so aussehen: hhaabbcveellkdgg.bar.de. Um standardkonform zu bleiben, dürfen nur die Zeichen a-z, A-Z, 0-9 und _ im Namen enthalten sein. Der Client hat die Nutzdaten also dementsprechend codiert: "hhaabbcveellkdgg"

Einfacher hat es der Server: Er schickt die Antwort in einem so genannten TXT-Resource-Record mit, der beliebige Daten enthalten kann.

Selbsttest

Selbsttest

Der schweizerische Sicherheitsdienstleister Compass Security Network Computer (CSNC) hat einen Windows-DNS-Tunnel-Client entwickelt, der sich an die in NSTX verwendeten Methoden anlehnt. Ergänzend betreibt CSNC einen eigenen DNS mit dazu passendem Tunnel-Server. CSNC bietet damit Interessierten die Möglichkeit, selbst zu testen, ob das Netzwerk für DNS-Tunnel anfällig ist.

Zum DNS-Tunnel-Test benötigt man den Tunnel-Client und einen Web-Browser zur Konfiguration des Tunnel-Servers. Vorzugsweise sollten Tester den Internet Explorer einsetzen, da es derzeit mit anderen Browsern zu Problemen kommen kann. Nach dem Start baut der Tunnel-Client mit dem Browser eine SSL-gesicherte Verbindung zum Server auf. Um auf das Konfigurationsmenü zugreifen zu können, muss man sich mit Name und Passwort einloggen. Anschließend darf man zwischen Simple, Advanced und Interactive Test auswählen. Simple Test führt recht schnell drei kurze Checks durch, um die Verwundbarkeit für DNS-Tunnel zu demonstrieren. Beim Advanced Test lädt der Client vom Server unter anderem einen EICAR-Testfile, auf den eigentlich jeder Virenscanner reagieren sollte. Im Interactive Test kann der Benutzer verschiedene Schritte und Befehle selber konfigurieren und kombinieren.

Jeder Test ist in allen Schritten beschrieben und mit übersichtlichen Bildern illustriert, die entsprechend des Test-Fortschritts farblich besonders hervorgehoben sind. Nach dem Start eines Tests tauschen Tunnel-Client und Tunnel-Server Daten per DNS Query und -Reply aus, während der Webbrowser die Ergebnisse des Tests per HTTP abfragt und anzeigt.

Der Tunnel-Client ist kostenlos erhältlich, der Tunnel-Server von CSNC steht für die Tests ebenfalls zur freien Verfügung. Um den Client benutzen zu können, muss man vorab den Nutzungsbedingungen zustimmen. Nach Angaben von Compass Security ist ein möglicher Missbrauch des Tunnel-Servers durch Dritte ausgeschlossen. Weitere Informationen zum Test finden Sie auf den Seiten von Compass Security [4], wo auch der Client zum Download bereit steht. Zur Anmeldung an den Tunnel-Server gibt man als Benutzername heise und als Passwort compass.dtt an.

Prinzipiell lassen sich auch andere Protokolle für Tunnel missbrauchen, sie müssen sich nur durch das Internet routen lassen. An ICMP-Ping-Pakete kann man beliebige Daten anhängen. Auch in FTP-Pakete lassen sich Pakete einbetten. Eine asymmetrische Kommunikation entsteht, wenn zwei unterschiedlichen Protokolle für den Hin- und Rückweg eingesetzt werden, beispielsweise SMTP und POP3 oder IMAP.

Holzpferde

Tunnel stellen für den Netzwerkverantwortlichen ein Problem dar, weil sie Einfallstore für Viren, Würmer und Trojaner bieten und die Möglichkeit, Daten unbemerkt herauszuschmuggeln. Peer-to-Peer-Netze, IRC-Clients und die private Mailabfrage sind für Schädlinge die häufigsten Verbreitungsmedien und deshalb sicherheitshalber gesperrt. Die Tunnel reißen nun wieder Löcher in das geschützte Netzwerk, wenn nicht eine gut konfigurierte Firewall die Netzübergänge mittels Content-Scanning überwacht. Denkbar sind Trojanische Pferde und Backdoors, die nach dem Befall eines Rechners Daten sammeln und nach Hause telefonieren. Bisherige Versionen öffnen eigene Server-Ports, um sich aus der Ferne steuern zu lassen. Meist blockt aber die Firewall noch solche Verbindungsversuche.

Mit IP-Tunneln durch die Firewall können die Schädlinge unerkannt arbeiten. Über spezielle Programme wie beispielsweise der Advanced Port Redirect Engine kann der Trojaner im Intranet sogar als Server arbeiten, obwohl der Verbindungsaufbau aus dem Internet nicht möglich ist. Der Redirector dreht die Richtung des Verbindungsaufbaus für Server und Client unbemerkt um, die Richtung des Datenflusses bleibt aber erhalten. Angreifer haben dann jederzeit, durch die Firewall hindurch, Zugriff auf Systeme im Intranet und können weitere Programme nachladen und starten, -- der Albtraum des Netzwerkverantwortlichen.

Spurensuche

Spurensuche

Der Aufwand für einen Administrator, einen Missbrauch festzustellen, ist abhängig vom Protokoll, das zum Tunneln verwendet wird. Mit einem Netzwerk-Sniffer lassen sich die Pakete auf allen Ebenen analysieren. Verdächtig viel Netzwerkverkehr von und zu einem Rechner führt schnell zum Schuldigen. Bleibt die Netzlast im Rahmen des Normalen, hilft die Suche nach verdächtigen DNS-Anfragen mit seltsamen Hostnamen und deren aufgeblähte Antworten. ICMP-Ping-Paketen mit Nutzdaten-Anteil kommt der Administrator ebenfalls schnell auf die Spur. Bei HTTP-Tunnel muss man schon tiefer in die Pakete hineinschauen, um zu erkennen, ob da nun getunnelte Pakete drin stecken. Schwierig wird es allerdings bei verdeckten Kanälen, die zusätzliche Verschleierungsmethoden wie Steganografie einsetzen. Hier hilft nur eine Anomalie-Analyse, etwa ob eine bestimmte Verbindung logisch über einen längeren Zeitraum besteht.

Abwehr

Sich gegen die ungewollte Durch-Tunnelung der Firewall zur Wehr zu setzen ist schwer. Nur eine komplette Trennung vom Internet bringt hundertprozentigen Schutz. Normale Firewalls filtern den Verkehr nur bis auf Port-Ebene, in die Pakete schauen sie nicht hinein. Hier hilft es, die IP-Adressen oder URLs bekannter Tunnel-Server zu blocken. Allerdings bietet das nur Schutz vor Diensten, wie sie HTTP-Tunnel bietet. Zu welchen Adressen ein Trojaner Verbindungen aufbaut, wird man kaum vorhersagen können. Application Level Firewalls und Firewalls mit Intrusion Prevention inspizieren vorbeikommende Pakete zwar genauer, allerdings ist es auch für diese nicht einfach, Daten zu erkennen, die beispielsweise huckepack mit HTTP transportiert werden. DNS-Tunnel können sie eventuell an kryptischen Hostnamen und den Text-Feldern der Resource Records erkennen und blockieren. Bei DNS genügt es auch schon, die interne Zone vom Internet zu entkoppeln. Interne Rechner können dann zwar keine Namensauflösung mehr für Systeme im Internet durchführen, in der Regel ist dies aber auch gar nicht nötig. Benutzt man beim Surfen im Internet einen Proxy, so löst dieser die angeforderte URL gegen eine IP-Adresse auf.

Literatur

[1] HTTP-Tunnel

[2] GNU httptunnel

[3] NSTX-Implementierung

[4] Compass Security DNS-Tunnel-Test

[5] Johannes Endres, Muschel aufbohren, Tipps und Tricks zur Secure Shell, c't 1/2004, S.172 (kostenpflichtiger Download ) (dab)