Aus dem Alltag eines Sysadmin: Httptunnel

Als echtes Landei habe ich Piercings zum ersten Mal in den Nasen von Opas Zuchtbullen gesehen, lange bevor es Menschen einfiel, sich Metall durch Antlitz und sekundäre Geschlechtsteile zu stanzen. In der Epoche zwischen beringtem Nutzvieh und getackerten Mitmenschen kamen Firewall-Piercings auf: Setuptricks, die beliebigen TCP-Verkehr durch eine sowieso vorhandene Firewall-Öffnung wie Port 80 fädeln.

Aus dieser Zeit stammt Httptunnel [1]. Obwohl Admins das Tool heute durch ein paar IPtables-Zeilen ersetzen könnten, bleibt es benutzerfreundlich und gehört zur Serienausstattung der meisten Distributionen. Ich werde Httptunnel im Urlaub verwenden, der mich in zwölf Stunden nach Okzitanien [2] bringt, einer Gegend mit netten Menschen, herrlicher Landschaft und Internetcafés, deren Betreiber unter einem Netzzugang ausschließlich HTTP verstehen. Ich dagegen will im IRC die Ergebnisse des in Okzitanien ausgetragenen internationalen Quallenweitwurfs vermelden, also brauche ich SSH.

Abbildung 1: Charly legt im Frankreichurlaub einen Tunnel quer durch Firewalls, um im IRC über Quallenweitwurf berichten zu können.

HTC, die Clientkomponente von Httptunnel, lauscht auf einem Port, (der über 1024 liegen muss, wenn ich nur als User arbeite). Dort eingehende Verbindungen verpackt der Client in HTTP und schickt sie auf einem Firewall-Piercing-fähigen Port zum Ziel. Ich versuche Port 443:

htc -w -F 4711 kintyre.kuehnast.com:443

Beim Ausprobieren hilft mir der Parameter »-w«, der verhindert, dass der Prozess sich als Daemon im Hintergrund abduckt. Später werde ich ihn weglassen. Das »-F« steht für Forward, dahinter folgen Quelle und Ziel der Weiterleitung. Da die Quelle ein Port auf dem Localhost ist, gebe ich keinen Hostnamen an, sondern nur den Port. Beim Ziel darf ich nicht nur IP-Adressen, sondern wie im Beispiel auch Hostnamen verwenden.

Im Krebsgang

Auf dem Ziel läuft das Ganze rückwärts. Die Serverkomponente HTS nimmt auf dem Port 443 eingehende Verbindungen entgegen, schält sie aus dem HTTP heraus und leitet sie an den konfigurierten Zielport weiter. In dem Beispiel ist das 22, denn ich möchte ja einen SSH-Login haben: »hts -w -F localhost:22 443«.

Unlogischerweise muss ich den Zielport 22 zuerst angeben, danach den Port, auf dem HTS auf Verbindungen lauscht. Aber egal, es kann losgehen. Auf dem Client öffne ich eine SSH-Verbindung gegen Localhost, Port 4711, mit

ssh -p 4711 charly@localhost

und kann mich auf dem Server einloggen (Abbildung 1). Das mit dem Quallenweitwurf war natürlich ein Witz - aber seit das Languedoc nicht mehr Industriealkohol, sondern richtig gute Weine produziert, mache ich die Daheimgebliebenen anderweitig neidisch. (jk)

Der Autor
Charly Kühnast administriert Unix-Betriebssysteme im Rechenzentrum Niederrhein in Moers. Zu seinen Aufgaben gehören die Sicherheit und Verfügbarkeit der Firewalls und der DMZ. Im heißen Teil seiner Freizeit frönt er dem Kochen, im feuchten Teil der Süßwasseraquaristik und im östlichen lernt er Japanisch.