Wer sein System permanent überwacht, hat den Grundstein dafür gelegt Engpässe zu vermeiden und Fehler frühzeitig zu erkennen. Neben dem Platzhirsch Nagios ... (mehr)

Dynamic Forwarding

Mit der Dynamic-Option »-D« kann sich ein SSH-Client auch wie ein Socks-Server (Socks-Proxy) verhalten und den automatisierten Zugriff auf entfernte Rechner durch einen sicheren SSH-Tunnel ermöglichen. Dynamic Port Forwarding ist ebenfalls nützlich, wenn man etwa von einem öffentlichen WLAN Hotspot über einen gesicherten Tunnel auf einen Dienst seines Heim- oder Firmen-Servers zugreifen möchte.

Es muss sich lediglich um einen Dienst handeln, für den es einen passenden Socks-Client gibt, was auf jeden Fall für Webbrowser zutrifft. In dessen Verbindungs-Optionen ist lediglich der lokale SSH-Client als SOCKS-Proxy mit der frei wählbaren Portnummer einzutragen. Da an öffentlichen WLAN Hotspots die Übertragung der Daten vom Client-Rechner zum WLAN-Router unverschlüsselt ist und daher von jedem beliebigen Netzwerk-Sniffer mitgelesen werden kann, bietet sich dieses Verfahren immer an, wenn beim Webzugriff auf den eigenen Server Login- oder andere sensible Daten übertragen werden. Der Aufbau des Tunnels zum entfernten »sshd« erfolgt dann mit

ssh -D Port Nutzer@Remotehost

Jetzt muss der Admin nur noch den lokalen SSH-Client als SOCKS-Proxy mitsamt dem angegeben Port in seine Browser-Einstellungen eintragen, im Bild am Beispiel Firefox (Abbildung 14).

Abbildung 14: Beim Dynamic Portforwarding fungiert der SSH-Client als SOCKS-Proxy. So muss ihn der Nutzer lediglich als

Auch in diesem Beispiel sorgt die Option »-N« dafür, dass der Client zwar den Tunnel aufbaut, auf dem Server aber keine Shell startet. Der SSH-Tunnel als SOCKS-Proxy kommt einem ausgewachsenen VPN schon recht nahe. Der einzige Unterschied besteht darin, dass sämtlicher Datenverkehr innerhalb der benutzen Applikationen SSH-Tunnel läuft, nicht aber DNS-Anfragen, sodass sich der SSH-Tunnel unter anderem nicht zum anonymen Surfen eignet.

Sollen andere Programme oder Dienste außer HTTP via SSH getunnelt werden, ist unter Linux zu beachten, dass manche Programme keine SOCKS-Proxies unterstützen. Ist dies der Fall, kann der Nutzer unter Linux den Wrapper »tsocks« installieren und für unser Beispiel mit folgender Konfigurationsdatei »/etc/socks/tsocks.conf« bestücken:

server = localhost
server_port = 12222
server_type = 4

Seit der Version 4.3 von OpenSSH ist es mithilfe der Option »-w« sogar möglich, ein richtiges VPN als Layer 2- oder Layer-3-Tunnel mit virtuellen Netzwerk-Adaptern (TUN/TAP-Interfaces) aufzubauen. Allerdings erfordert dies, dass der Admin auf Server- und Client-Seite die entsprechenden TUN/TAP-Devices durch Laden der zugehörigen Kernel-Module mittels »modprobe« einrichtet. Das Verfahren eignet sich also nicht zur Adhoc-Verwendung etwa im geschilderten Internet-Café-Szenario. Das Aufsetzen der zugehörigen virtuellen Netzwerk-Adapter auf Server und Client erfolgt auf dem Client mit:

ifconfig tun0 10.0.2.1 netmask 255.255.255.252

Auf dem Server sieht die Konfiguration dann so aus:

ifconfig tun0 10.0.2.2 netmask 255.255.255.252
route add -host Ziel-Host dev eth0

Erst danach kann der Nutzer ausgehend vom Client einen VPN-Tunnel aufbauen:

ssh -l Benutzer -p Sshd-port -w0:0 Ziel-Host

Damit das funktioniert, muss in der zugehörigen Sshd-Konfiguration auf dem Linux-Server die Option »PermitTunnel yes« aktiviert sein.

Firewall durchbohren

Schon die bisher gezeigten Verfahren sollten die Leistungsfähigkeit von SSH vor allem im Bereich Port Forwarding eindrucksvoll demonstriert haben. Dabei waren sämtliche Beispiele auch im Sinne des Erfinders. Ssh lässt sich in gewissen Grenzen aber auch zweckentfremden. Blockt etwa die firmeneigene Firewall den SSH-Port 22, der Admin möchte aber von zu Hause sicher auf Daten seines Firmenrechners zugreifen, kann er sich mit folgendem Trick behelfen, bei dem unter anderem Remote Portforwarding ins Spiel kommt.

Dazu muss am Firmen-Rechner ein OpenSSH-Server laufen, auch wenn die Firewall Anfragen auf Port 22 unterbindet. Zum Verfügungstellen eines SSH-Servers kann der Admin neben dem Paket »openssh-client« auch die Server-Komponenten für SSH in Form des Paketes »ssh« installieren. Waren vorher weder SSH-Client noch Server installiert, können Debian- und Ubuntu-Admins auch »tasksel« von der Kommandozeile starten und dann die Paket-Gruppe »OpenSSH server« auswählen.

Das Nachvollziehen folgender Vorgehensweise empfiehlt sich selbstverständlich nur dann, wenn der Admin auch Administrator des entfernten Servers beziehungsweise Netzes ist oder ein etwaiger Versuch mit ihm abgesprochen ist, denn er verletzt mit Sicherheit firmeninterne Sicherheits-Policies. Zu Hause muss der Admin dann dafür sorgen, dass auch der Heimrechner SSH-Verbindungen annimmt, wozu gegebenenfalls neben OpenSSH-Client ebenfalls die Server-Pakete zu installieren sind.

Außerdem muss der Heim-Rechner über eine DnyDNS-Adresse von außen erreichbar sein. Läuft der SSH-Server am Heimrechner, baut der Admin am Heimrechner einen SSH-Tunnel vom Typ Remote Port Forwarding für den Port 22 vom Firmenrechner zum Sshd am Heimrechner auf, allerdings unter Zuhilfenahme der öffentlich zugänglichen DynDNS-Adresse.

ssh Benutzer@Firmenrechner -R 4444:Heimrechner:22

Dann lässt er diesen Tunnel schlicht stehen und baut mit »ssh Benutzer@Heimrechner -p 4444« durch diesen Tunnel hindurch einen weiteren Tunnel zum Firmenrechner unter Verwendung der beim Remote Port Forwarding angegebenen Portnummer (4444) auf. Das Beispiel demonstriert zwar das Prinzip des doppelten Tunnels, wird aber dem selbst gesteckten Szenario selbstverständlich noch nicht gerecht, weil ja die Firmen-Firewall definitionsgemäß Anfragen auf Port 22 nicht passieren lässt. Die meisten Firmen-Firewalls sind aber so konfiguriert, dass Anfragen auf Port 80 (HTTP) erlaubt sind.

Es spricht also in diesem Beispiel nichts dagegen, den SSH-Server zu Hause auf einem anderem Port lauschen zu lassen, beispielsweise auch den eigentlich für HTTP reservierten Port 80. Trotzdem an dieser Stelle noch einmal der Hinweis, dass ein solches Vorgehen arbeits- oder gar strafrechtliche Konsequenzen haben kann.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2020