© kallejipp, Photocase.com

Linux-Magazin-Autor Tobias Eggendorfer, der viel unterwegs ist, ärgert sich oft über die teuren Internetzugänge in Hotels. Eines abends in einer Herberge übermannte den Informatik- und Forensik-Professor die Experimentierlust. Eine Proxy- und Tunnelerzählung .

Reisen bildet. Jeder, der wie ich mit seinem Laptop viel unterwegs ist, macht die Erfahrung, dass in den meisten Hotels die Internetzugänge frech teuer sind. Da machen die Hilton-Hotels keine Ausnahme, in denen ich recht häufig absteige. Dass manchmal ein Viertel der Hotelrechnung der Posten WLAN-Nutzung ausmachte, wurmte mich ungeachtet dessen, dass ich sie nicht aus eigner Tasche zahlen muss, gewaltig

An einem Abend vor ein paar Wochen, ich war gerade im Münchner Ableger der Hotelkette, münzte ich meinen Ärger in Neugier um. So ausgereift können die Zugangssysteme gar nicht sein! Für die technische Umsetzung zeichnet offenbar die Firma Swisscom verantwortlich. Der recht bedeutende Telekomunikationsanbieter beliefert zahlreiche größere Hotelketten [1].

Das Verfahren fällt relativ simpel aus: Bis die eigene MAC-Adresse für die Nutzung des Internet gebührenpflichtig freigeschaltet ist, lenkt es alle Webzugriffe auf eine Auffangseite (Abbildung 1). IMAP, IMAPS und POP-Ports scheint Swisscom in recht primitiver Weise zu blocken. Bei Tests mit einem IMAP-Server baut der Client zwar eine Verbindung zum Zielsystem auf, aber sobald die steht, unterdrückt Swisscom die Antwortdaten. Das bringt manche Mailclients an den Rand der Verzweiflung.

Abbildung 1: Ohne Moos wenig los: Solange ein Hotelgast keinen Account zu den genannten Preisen erworben hat, landert er auf einer Auffangseite.

Kommissar Zufall weist die Ermittlungsspur

Beim Untersuchen des Systems kam mir der Zufall zur Hilfe: Obwohl noch nicht gebührenpflichtig angemeldet, schaltete sich plötzlich mein Instant-Messaging-Client online und ich konnte Nachrichten mit Freunden austauschen.

Nur eine kleine Panne oder eine systematische Schwachstelle? Der kommuniziert bei mir für die meisten IM-Protokolle nicht über Port 5190, sondern auf Port 443. Das hat sich auf Reisen bewährt, um lästige Firewalls zu umgehen. HTTPS ist selbst bei restriktiven Zugängen meist offen, zumindest dann, wenn mein Notebook authorisiert andockt. Im Hotel war der Anschluss aber noch gar nicht bezahlt! Bei mir keimte die Hoffnung auf, dass HTTPS-Port 443 nicht über einen Proxy läuft, sondern sich direkt durchverbindet. Und tatsächlich, über HTTPS angesurft, kam die Auffangseite nicht.

Ein Angriff will gut vorbereitet sein

Wieder zu Hause bereitete ich meinen nächsten Hotelaufenthalt vor. Ich brauchte einen HTTP-Proxy auf einem Server im Internet, der auf Port 443 Anfragen entgegen nimmt. Der ist in Perl mit dem CPAN-Modul HTTP::Proxy schnell aufgesetzt. Nach der Modul-Installation mit CPAN:

perl -MCPAN -e 'install HTTP::Proxy'

schrieb ich anhand des Beispielcodes von [2] den Mini-Proxy, zu sehen in Listing 1. Allerdings krankt die simple Lösung an ein paar Details: Damit das Programm den Port 443 öffnen darf, muss es mit Rootrechten laufen. Das ist auf Dauer aus Sicherheitssicht wenig empfehlenswert, denn die Wald-und-Wiesen-Serverapplikation steht topologisch unmittelbar im Internet. Zudem ist der Rechner nur noch als HTTP-Proxy erreichbar, was unnötig einschränkt.

Dennoch: Mit »./http_proxy.pl &« gestartet reicht das Setup für erste lokale Tests. Dann trug ich im Browser die IP meines Servers als Proxy für HTTP ein. Seriöse Browser gestatten es, für die einzelnen Protokolle verschiedene Proxies zu nutzen. Hier soll zunächst nur ein HTTP-Proxy gesetzt werden. Die Felder für die anderen Protokolle, insbesondere HTTPS, müssen freibleiben.

01 #!/usr/bin/perl
02 use HTTP::Proxy;
03 my $proxy = HTTP::Proxy->new( port => 443);
04 $proxy->start;

Einen Tunnel graben

Meine Versuche mit dem Proxy liefen erfolgreich, ich suchte aber einen besseren Weg, der nicht nur mit HTTP funktioniert. Die Richtung ist klar: ein SSH-Tunnel. Dabei soll mein Laptop als Client eine SSH-Verbindung zu einem Server im Internet aufbauen und einige Ports geeignet umleiten.

Um SSH zusätzlich zu Port 22 auf dem HTTPS-Port lauschen zu lassen, füge ich in der »/etc/ssh/sshd_config« einfach eine Zeile »Port 443« ein und schalte mit

kill -HUP `cat /var/run/sshd.pid`

scharf. Der SSHD lässt sich sogar so konfigurieren, dass er auf mehreren Ports gleichzeitig SSH-Verbindungen annimmt. In meinem Fall war das nützlich, da ich mir meinen SSH-Tunnel-Einstiegsrechner mit ein paar Kollegen teile und keine Lust hatte, die erst über eine geplante Portänderung zu informieren.

ssh 
 
  tunnel.example.com
  -p 443 -L48080:localhost:3128 -f './http_proxy.pl &'

Die Zeile veranlasst SSH, sich zum angegebenen Rechner auf Port 443 zu verbinden und dort das Perl-Skript auszuführen. Dank »-f« geht der SSH-Client in den Hintergrund, kurz bevor das Kommando startet. Das hat den Vorteil gegenüber dem klassischen »&«, dass eine eventuell nötige Passworteingabe noch im Vordergrund stattfindet. Nun kann ich im Browser den HTTP-Proxy als »localhost 48080« eintragen (Abbildung 2).

Abbildung 2: Nach den Bohrarbeiten für den Tunnel trägt der Reisende im Browser das eine Tunnelende als HTTP-Proxy ein.

Wieder auf Reisen

Zurück im Hotel in München musste ich das natürlich gleich ausprobieren. Wie erhofft verbanden sich der SSH-Client und -Server über Port 443, durchtunnelten die Swisscom-Restriktion und ich konnte kostenlos surfen.

Natürlich lässt sich das Ganze erweitern, beispielsweise um E-Mails abzurufen:

ssh 
 
  tunnel.example.com
  -p 443 -L48080:localhost:3128 -L60110:
 
  pop.example.com
 :110 -L60993:
 
  imap.example.com
 :993 -L60025:
 
  smtp.example.com
 :25 -f './http_proxy.pl &'

Ein SSH-Tunnel zum Empfang von E-Mails über unverschlüsselte Protokolle wie POP3 ist per se sinnvoll und sollte sich im Handgepäck jedes Reisenden finden. Auch eine SMTP-Authentifizierung lässt sich über einen SSH-Tunnel zumindest schützen. Zudem umgehe ich so die von manchen Anbietern gesetzte Spam-Sperre für fremde SMTP-Server.

Alternativen

Wie gesehen habe ich für meine Experimente den Weg über einen SSH-Server gewählt. Natürlich wären auch andere möglich gewesen, beispielsweise indem ich einfach mit

ssh 
 
  tunnel.example.com
  -p 443 -X -f '/usr/local/mozilla/mozilla &'

auf dem entfernten Rechner meinen Mozilla starte und Server-based-Computing-mäßig surfe. Wegen der zu übertragenen Datenmasse macht das Geruckele aber keinen Spaß. Die edleren Protokolle von VNC oder NX [3], auf 443 umgebogen, würden die Variante flott machen.

Auch denkbar ist es, einen Open-VPN-Server zu Hause auf dem TCP-Port 443 lauschen zu lassen. Open VPN ist in der Lage ein ganzes Netzwerk über einen TCP oder UDP-Port zu tunneln. Damit wäre der Laptop sofort Mitglied im Heimnetz. Open VPN ließe sich auch dazu bewegen, einen Proxy zu täuschen und den gesamten Netzwerkverkehr durch das VPN zu lenken [4].

Was Anbieter tun können

Wie hätte Swisscom das Problem umgehen können? Soweit sichtbar setzt der Anbieter großflächig auf Proxies, die Unterscheidung zahlender User/nicht autorisierter User anhand der IP oder MAC-Adresse prüfen und steuern. Einen HTTPS-Proxy fehlerfrei zu betreiben ist nicht trivial – es gar nicht zu tun, weckt aber den Spieltrieb und animiert War Driver aus der WLAN-Nachbarschaft.

Besserung würde eine einfache Firewall bringen, die alle Ports für den Rechner des Gastes blockt, bis der zahlt. Das hilft zwar nicht gegen IP- umd MAC-sniffende Gäste, die anderen den Zugang wegfangen. Doch das Problem hat das bestehenden System auch schon. Komplexität und Sicherheit sind nicht immer äquivalent.

Schluss is’!

Das Hotel habe ich sofort nach meinem erfolgreichen Test in Kenntnis gesetzt. Die Mitarbeiter an der Rezeption versprachen mir die Meldung an Swisscom weiterzuleiten. Und oh Wunder: Bei meinem letzten München-Besuch war der Sicherheitsmangel beseitigt!

In ähnlichen Fällen, wo das Linux-Magazin Schwachstellen aufgedeckte hatte, wurden die meist betroffenen Firmen erst nach Einschalten der jeweiligen Presseabteilung tätig – und das nicht immer mit Erfolg [5]. (jk)

Linux-Magazin Labs

Sicherheit zu gewährleisten bedeutet, viele Angriffsvektoren auf einmal im Auge zu behalten. Wo es früher ausreichte, eine Liste von Ports einer Firewall zu konfigurieren, ist Security heute komplexer. Besonders Webapplikationen machen dem Admin das Leben schwer: Eine Recherche des Linux-Magazins zeigte, dass die Dokumentationslage einem schwarzen Loch ähnelt. Es gibt keine verlässliche Stelle, die Tipps und Techniken zusammenträgt. Das muss sich ändern! Linux-Magazin Labs sammeln Lesererfahrung zur Web-Security Dazu stellt das Linux-Magazin unter [http://linux-magazin.de/lab] ein Wiki ins Netz. Jeder Magazin-Leser, Webmaster, Entwickler von Webapplikationen oder Securityspezialist findet dort Tipps: Welche Daten soll ich filtern oder beobachten? Reichen Reverse-Proxys oder Modsecurity aus? Wie verhindere Angriffe mit Netfilter? Was bringen SQL-Firewalls oder Security-Libs für PHP oder Java? Die Redaktion steuert thematisch passende Beiträge aus dem Linux-Magazin bei. Um aus dem Projekt eine Referenz zu machen, bedarf es Ihrer Mithilfe! Kommen Sie doch mal vorbei! Abbildung 3: Die Linux-magazin Labs sammeln Erfahrungen und Vorschläge von Lesern zur Wensecurity. Von Zeit zu Zeit entstehen daraus Magazinartikel.