Schleichpfade
Seite 2: 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.
