Archive for Januar 2014

Es muss nicht immer VPN sein – surfen über einen SSH-Tunnel


Ein virtuelles Privates Netzwerk (VPN) bindet entfernte Nutzer über das Internet in ein lokales Netzwerk ein. Das geschieht im Allgemeinen transparent, d.h. für die Nutzerinnen und Nutzer sieht es so aus, als ob sie sich beispielsweise im Uni-Netz befinden. Alle Netzdienste in einem Firmen- Heim- oder Universitätsnetz können dann unterwegs so genutzt werden, als ob man vor Ort wäre. Sehr häufig geht es aber nur um einen einzigen Netzdienst, nämlich das Web. An der Universität Duisburg-Essen werden viele Dinge heute webbasiert erledigt. Allerdings erfordern viele Seiten, dass sich der Nutzer im IP-Adressbereich der Uni befindet. Das ist beispielsweise für viele Bibliotheksdienste der Fall, die Zugriff auf Online-Angebote der Verlage realisieren. Warum also ein vollständiges VPN verwenden, wenn eigentlich nur die Verbindungen über die Ports 80 (http) und 443 (https) genutzt werden? Eine Möglichkeit http- und https-Verbindungen umzuleiten ist ein Web-Proxy, der auf Protokollebene zwischen dem Browser und dem Web vermittelt. Dazu muss aber ein dezidierter Proxy-Server betrieben werden, der von außerhald des Uni-Netzes zugänglich ist. Alternativ realisiert ein sogenannter Socks-Proxy so etwas auf Socket-Ebene also über TCP/IP Ports.

Ein Tunnel sie alle zu knechten …

Alle aktuelle Browser unterstützen die Verbindung über einen Socks-Proxy. Wer Login-Zugriff per SSH auf einen Rechner in dem Zielnetz hat, kann sehr einfach einen Socks-Proxy per SSH-Tunnel realisieren. Das ist beispielsweise an der Universität Duisburg-Essen für alle Nutzer der Fall. Alle Mitarbeiter haben mit ihrer Unikennung Zugriff auf staff.uni-due.de und alle Studierende können die Maschine student.uni-due.de mit ihrer Kennung nutzen.

Linux/MacOS/Unix:

Unter unixoiden Betriebsystemen wie Linux und MacOS geht das sehr einfach mit Bordmitteln auf der Kommandozeile (hier mit staff.uni-due.de für Mitarbeiter):

ssh -N -D2000 <unikennung>@staff.uni-due.de

Der Parameter -N verhindert hier den Aufbau einer interaktiven Shell-Verbindung. Der Parameter -D gibt den lokalen Zugriffsport für den dynamischen Tunnel an. Diesen Port wählt man unter Unix geschickter Weise oberhalb von 1023, damit keine Root-Rechte erforderlich sind.

Windows:

Unter Windows benötigen Sie einen SSH-Clienten wie beispielsweise den quelloffen Putty.

Nach der Installation wird Putty folgendermaßen konfiguriert (hier staff.uni-due.de  für Mitarbeiter, Studierende verwenden student.uni-due.de):

putty_tunnel0

Dann wird der Tunnel mit dem lokalen Endpunkt Port 2000 (willkürlich gewählt) konfiguriert. Wichtig für einen Socks-Proxy ist die Einstellung “Dynamic”:

putty_tunnel1

Nach klick auf “Add” ist der Tunnel eingerichtet. Sinnvollerweise speichert man das Profil nun ab. Vorsicht ist geboten bei der Checkbox „Local ports accept connection from other hosts“. Wer diese Option anwählt tunnelt womöglich andere Rechner oder gar Angreifer mit in das Universitätsnetz.

Betriebssystemunabhängig – die Browser-Konfiguration:

So konfiguriert man den Browser (hier z.B. Firefox, sorry ich verwende nur den englischsprachigen), damit er den Tunnel auch benutzt:

putty_tunnel2

Technisch gesehen wird nun jeder http-Request über den lokalen Port 2000 des Klienten abgewickt, der ja über den (gesicherten) ssh-Tunnel mit dem Publikumsrechner im LAN der Uni verbunden ist.

Wenn der Tunnel erfolgreich in Betrieb genommen worden ist, kann man zum Beispiel auf www.wieistmeineip.de überprüfen, ob auch wirklich der Tunnel im Browser verwendet wird. Dort wird nun eine IP-Adresse aus dem Uni-Adressbereich 132.252.X.X angezeigt. Natürlich muß die Proxy-Einstellung immer wieder rückgängig gemacht werden, wenn der Tunnel wieder abgebaut wird. Zweckmäßig ist die Nutzung eines extra Browsers oder beispielsweise bei Opera die Verwendung der Schnelleinstellungen.

So ein Socks-Proxy funktioniert auch in Umgebungen, in denen herkömmliche VPN-Lösungen versagen (müssen), z.B. doppeltes NAT. Es ist auch möglich beliebig viele Klienten aus einer NAT Umgebung gleichzeitig zu verbinden, was bei einem VPN zu Problemen führen kann. Auch Unitymedia-Kunden mit IPv6-Stack ohne IPv4 profitieren von dieser Lösung.

socks-proxy

Übrigens bekommt Ihr Provider (oder das Internet-Cafe in dem Sie sich befinden) nicht mit was in dem Tunnel passiert, alles ist bis zum Socks-Proxy in der Uni verschlüsselt. Nach dem Tunnel, also ab staff.uni-due.de bzw. student.uni-due.de geht es aber wieder unverschlüsselt weiter. Zumindest Ihr Provider hat aber keine Chance diese Verbindungsdaten abzugreifen.Der Provider sieht nur die Verbindung zum Socks-Proxy. Gegen die Datenschnüffellei der NSA schützt das aber nicht wirklich, da der Traffic aus der Uni zu den Webseiten die Sie besuchen abgegriffen wird, was wirklich eine Frechheit ist!

Spezialitäten:

Wer mehr möchte, kann auch Programme die keine Socks-Proxys unterstützen mit dieser Technik ausstatten, indem man einen Wrapper wie z.B. tsocks einsetzt.

Es ist sogar möglich einen kompletten Stack über einen Socks-Proxy umzuleiten. Dazu wird das Tool tun2sock (bzw. badvpn) eingesetzt. Damit ist ein SSH-basiertes VPN realisierbar.

Für Kunden von Unitymedia mit neuem Ipv6-Stack ohne IPv4 wäre es damit möglich das Zwangs-NAT für alle Verbindungen zu überwinden.

Noch ein Tipp für die Besitzer eines Servers/virtuellen Servers oder eines Shellaccounts mit fester erreichbarer IP:

Wer von einem limitierten Internetzugang (z.B. NAT und kein Zugriff auf den Router) aus Serverdienste (Web, ssh, etc.) betreiben möchte, kann z.B. mit

ssh -R 3333:localhost:22 <gateway-maschine>

einen ssh-Server des nicht erreichbaren Rechers in einem NAT (oder in einem Ipv6-only-Netz) auf den Port 3333 auf einer Gateway-Maschine (die über eine öffentlich erreichbare IP-Adresse verfügt) umlenken, wenn auf der Gateway-Maschine in der Konfigurationsdatei /etc/ssh/sshd_config

GatewayPorts yes

(Neustart des sshd erforderlich) eingetragen wird.

So kann die versteckte Maschine per ssh auf den Port 3333 der Gateway-Maschine erreicht werden. Das klappt beispielsweise auch mit einem Server (z.B. auch Webserver, dann aber Port 80 weiterleiten) auf einem Smartphone (oder einem mobilen Roboter, wie ich das hier im Jahre 2009 realisiert habe) im UMTS-Netz, dass bei fast allen Providern auch per NAT betrieben wird!

nat-tunnel-server

Dazu sind natürlich auf der aus dem Internet erreichbaren Maschine Root-Rechte erforderlich.

Ohne Root-Rechte ist es etwas komplizierter so etwas zu realisieren, hier benötigt man zwei Tunnel:

auf der hinter einem NAT versteckten lokalen Maschine:

ssh -R 3333:localhost:22 <gateway-maschine>

auf der Gateway-Maschine mit öffentlicher IP:

server# ssh -g -L4444:localhost:3333 localhost

Dann kann nun über den Port 4444 der Gateway-Maschine per ssh auf die versteckte Maschine zugegriffen werden. Das funktioniert mit beliebigen Quellports, also auch mit Port 80. Die Beispiele beziehen sich auf die Unix-Kommandozeile aber sollten mit entprechenden Einstellungen auch unter Windows funktionieren, sofern man einen sshd für Windows installiert.

Vorausgesetzt wird immer, dass keine Firewall die Ports blockiert. Wenn man nicht über root-Rechte verfügt, muss man Ports oberhalb von 1023 wählen, es geht bis 65535 ;-) .
Die Maschinen staff.uni-due.de und student.uni-due.de am ZIM der Universität Duisburg-Essen erlauben dieses erweiterte Verfahren übrigens nicht, da sie durch Firewalls geschützt sind. Einen Socks-Proxy können Sie aber mit diesen Maschinen aufbauen.