Lange Tunnel, tiefe Schluchten – HTTP Tunneling leicht gemacht

Heutiges Thema: Tunnel. Genauer: HTTP Tunneling. Noch genauer: Wie ich aus den Fesseln meines Arbeitgebers ausbreche und (fast) jede (Firmen-) Firewall überwinde.

Alle Blümchenpflücker und Rollkragenpulloverträger brauchen heute mal nicht weiterzulesen

Einführung

Ich denke jeder der auf Arbeit Internetzugang hat, hat sich schonmal gewünscht, gerade die Seite zu besuchen oder gerade diesen Dienst zu benutzen, aber der Arbeitgeber hat durch die Firewall ziemlich restriktive Grenzen gesetzt. Sei es, um die Mitarbeiter zu überwachen, sei es auch nur um das Netzwerk zu schützen. Zumindest gegen letzteres ist auch nichts einzuwenden. Aber als erfahrener und allwissender Support-Mitarbeiter wollte ich halt doch ganz gern mal zu Hause auf meinen Server zugreifen und die Mails lesen oder einen Download starten oder oder oder.
Die hier vorgestellte Lösung, die ich auch bei mir einsetze, funktioniert grundsätzlich immer, sobald man surfen kann und das kann man an praktisch jedem internetfähigen PC.

Grundlagen

In den meisten Firmen gibt es eine Firewall, die dafür da ist unerwünschten Internetverkehr nicht zuzulassen. Meistens ist diese so konfiguriert, dass nur bestimmte Dienste explizit erlaubt sind, alles andere ist verboten. Da jedoch das Surfen (genauer: das Protokoll HTTP) meistens erlaubt ist, bietet sich dieses an, darüber einen Tunnel aufzusetzen.
Ein Tunnel, in dem Sinne wie er hier verwendet wird, ist ein Dienst der ein bestimmtes Protokoll (z. B. Mail oder SSH) durch ein anderes hindurchleitet. Es werden also die Anfragen des Mailprogramms in normale HTTP Anfragen verpackt, durch den Proxy hindurchgeleitet (der Proxy denkt es handelt sich um normales Surfen) und am Zielserver wieder ausgepackt und an den eigentlichen Zielserver, der nun ausserhalb der Firewall liegt, weitergeleitet.
Vorteil: es lässt sich prinzipiell jedes Protokoll durch jedes andere Protokoll hindurchtunneln. Die c’t hat z.B. auch einmal eine Beispielimplementation vorgestellt, die HTTP durch DNS Anfragen hindurchtunnelt. Es reichte also schon am Arbeitsrechner, DNS Anfragen stellen zu können, um Surfen zu können. Ich beschränke mich hier jedoch darauf, beliebige Protokolle durch das HTTP Protokoll zu tunneln.
Nachteil: es ist immer ein Tunneling-Server notwendig, der die getunnelten Anfragen wieder auspackt und an den
eigentlichen Zielserver weiterleitet. Bei der weiter fortschreitenden Verbreitung von DSL auch mit höheren Bandbreiten, sollte es aber kein Problem mehr sein, einen kleinen Server zu Hause immer online zu halten und diesen mit DynDNS auch von aussen immer erreichbar zu machen.
Ausserdem hat man maximal die gesamte Uploadgeschwindigkeit zur Verfügung, was nochmals durch den Overhead, die das Tunneling und später auch noch SSH verursachen, verringert wird. Bei meinen 16kb/s Upload durch DSL, bekomme ich, wenn ich surfe ungefähr ISDN Geschwindigkeit heraus. Fürs Surfen natürlich ungeeignet, zumal die Anbindung des Firmenproxies wesentlich schneller ist, aber ich will ja primär nicht surfen, sondern Mail abholen.

Einrichtung des Tunnels

Es gibt viele Tools und auch kommerzielle Anbieter, die das HTTP-Tunneling erlauben. Ich persönlich verwende GNU httptunnel. Es gibt sowohl den Server als auch den Client als Windows- und Linux-Binaries. In Debian Linux installert man es ganz einfach mittels apt-get install httptunnel, die Windows Binaries sind über die Homepage zu bekommen. Zuerst sollte man den Server einrichten. Dazu folgende Kommandozeile starten:

Läuft der Server, kann man den Client auf dem Arbeitsrechner einrichten. Dies funktioniert auf ähnliche Weise und sieht so aus:

Kurz zusammengefasst kann man mit folgenden Befehlen eine Tunnel-Verbindung für Pop3 Zugriff aufbauen:

auf dem Server: hts -S –max-connection-age 20000 -F mail.gmx.de:110 8890

auf dem Client: htc -F 110 –strict-content-length -B 5k –max-connection-age 2000 -P firmenproxy:port tunnelserver:8890

Das Mailprogramm auf dem Client kann nun auf den lokalen Rechner, also localhost eingestellt werden. Da wir den Standardport für POP3 weiterleiten, braucht man hier keine Änderung mehr zu machen. Der Tunnel sorgt nun dafür, dass alle Anfragen auf den lokalen POP3-Port über den Firmenproxy an den Tunnel-Server weitergereicht werden. Dieser leitet dann alle Anfragen an den eigentlichen Mailserver weiter. Zurück geht es dann den umgekehrten Weg.

Flexibilität und Absicherung

Auf diese Weise kann man beliebig viele Tunnel einrichten. Allerdings hat ein Tunnel immer nur einen definierten Eingang und einen definierten Ausgang und kann auch nur exklusiv von einem Programm verwendet werden. Wenn ich jetzt über einen Tunnel der ursprünglich nur für POP3 eingerichtet wurde, auch SMTP fahren will, dann müsste ich den gesamten Tunnel ändern. Auf die Dauer war mir das zu aufwändig, zumal ja immer auch Änderungen am Server vorzunehmen sind. Dafür benutze ich SSH/Putty.
Der HTTP-Tunnel wird so definiert, dass er die SSH Verbindung tunnelt: auf dem Client also auf Port 22 lauscht und die Verbindung an einen SSH Daemon auf demselben Server weiterreicht, auf dem auch der Tunnel-Server läuft. SSH selbst ist nämlich in der Lage ebenfalls Verbindungen zu tunneln und rein theoretisch kann Putty (der Windows SSH Client) auch SSH-Verbindungen durch einen Proxy tunneln. Dies hat jedoch bei mir nie wirklich funktioniert. GNU httptunnel sorgt also dafür, dass die SH Verbindung getunnelt wird, den Rest besorgt ssh selbst: man kann über ssh beliebig viele Tunnel anlegen, für die man dann sogar in den Genuss der Verschlüsselung kommt. Die Verbindung sieht dann ungefähr so aus:

Die Verbindung wird also zweimal getunnelt. Vorteil dieser Methode ist, dass man nur einen httptunnel aufsetzen muss und SSH beliebig viele weitere Tunnel darüber tunneln kann. Und da man diese Tunnel bei SSH nur auf dem Client definieren muss, sind keine weiteren Änderungen auf dem Server mehr notwendig. Komfortabler geht es kaum.

Nach Einrichtung des HTTP-Tunnels konfiguriert man Putty also so, dass es eine ssh Verbindung zu localhost aufbauen soll (httptunnel am besten so konfigurieren, dass es auf dem Standard SSH Port lauscht) und dann über den Punkt Connection – SSH – Tunnels die Tunnel einrichten. Hier mal ein Screenshot:

Einen weiteren Vorteil dieser Methode hatte ich schon kurz erwähnt: die Verbindungsdaten werden komplett verschlüsselt. Zwar sind HTTP Tunnel durch Firewalls nur schwer zu entdecken und gar nicht zu verhindern, aber die Daten die darüber verschickt werden, sind grundsätzlich nicht verschlüsselt. Da man aber möglicherweise auf seine persönlichen Daten zu Hause zugreift, wäre es doch ganz günstig eine Verschlüsselung einzurichten. Sofern man SSHv2 verwendet, ist das auch wirklich sicher.
Zumindest bis die Daten auf dem Client gelandet sind. Denn natürlich kann die Firma, wo man arbeitet, lokale Überwachungsprogramme laufen lassen, die dann doch anzeigen, was man denn gerade so im Internet tut. Auf jeden Fall sollte man – wenn man über den Tunnel auch surft – ab und zu den Browsercache löschen. Und man sollte sich auch auf jeden Fall im klaren sein, dass der Firma solche Aktivitäten der Mitarbeiter bestenfalls unangenehm sind und dass man schlimmstenfalls gekündigt werden kann, wenn über den Tunnel sensible Firmendaten oder Erwachsenenmaterial laufen.

Fazit und Anmerkungen

HTTP-Tunnel sind eine einfache und günstige Möglichkeit, die Fesseln, die einem die IT-Abteilung angelegt hat zu sprengen. Alle eingesetzten Programme erfordern auf dem Client keine Installation und sollten so auch bei restriktiven Rechten auf dem Rechner laufen. Läuft einmal der Tunnel und die SSH Verbindung ist die Erweiterung einfach am Client zu erledigen. Erfahrene Benutzer können so dem Administrator ein Schnippchen schlagen.
Als Praxistipp kann ich noch empfehlen trotz der SSH Verbindung zwei HTTP-Tunnel einzurichten, die beide SSH tunneln. Zumindest der Proxy in meiner Firma hakt ab und zu, sodass die SSH Verbindung schonmal abbrechen kann. Leider neigt dann der httptunnel Prozess dazu, nicht zu erkennen, dass die Verbindung nicht mehr besteht. Allerdings kann ein HTTP-Tunnel immer nur exklusiv belegt werden, so dass nach Abbruch der SSH Verbindung, kein sofortiger Reconnect zum selben HTTP-Tunnel aufgebaut werden kann. In so einem Fall benutze ich dann einfach den zweiten HTTP-Tunnel.

Und nochmal der Hinweis: jeder ist für die Konsequenzen aus seinem Tun selbst verantwortlich. Mit viel Aufwand und Handarbeit ist es zumindest möglich zu erkennen, dass ein Benutzer einen Tunnel benutzt, auch wenn durch die SSH-Verschlüsselung nicht klar zu erkennen ist, was dort abläuft. Wie die IT-Abteilung darauf reagiert, sollte jeder in seiner Firma selbst abschätzen können.

Trotzdem wünsche ich euch von nun an viel Spass beim Tunnel graben