SSLH - Ausbruch aus den Firewall-Barrieren

Security VPN Linux
19.10.2019 | Andreas Müller

Die klassischen Leiden eines Systemadministrators...

Ich bin gerade mit dem Auto unterwegs und bekomme einen Anruf "Das geht nicht, bestimmt ist auf dem Server was kaputt". Also geht es an der nächsten Rastanlage hinaus und mit dem Laptop ab ins kostenfreie WLAN, das glücklicherweise verfügbar ist.
Anmeldung per SSH auf den Server und nach dem Rechten sehen... doch die Verbindung zu Port 22 wird blockiert - war wohl nix!

Also geht der nächste Griff zum Smartphone und dort schnell einen Hotspot eingerichtet... doch auch hier muss ich passen.
Das Netz ist mal wieder nur mäßig und reicht entweder zum telefonieren oder Hotspot etablieren... da klingelt es schon wieder... Hotspot fällt also auch flach.

Wieder zurück zum kostenfreien WLAN: Wie komme ich nun durch die Firewall hindurch zu meinem gewünschten Ziel?


So oder so ähnlich lässt es sich ganz gut darstellen, was einem Admin gern mal den letzten Nerv raubt. Also begann eine Recherche, wie sich das Ganze optimieren lässt.

Analyse

Beim genaueren Untersuchen von verschiedenen freien Netzwerken ließ sich immer wieder beobachten, dass HTTP Anfragen auf Port 80 gerne gefiltert werden. Ob zur Datenerhebung oder einfach nur zum Schutz vor unerwünschtem Inhalt sei jetzt mal dahingestellt.
Doch Fakt ist: Die Daten werden angesehen und unerwünschter Traffic somit auch effektiv unterbunden. Also keine Lösung, um hier was anderes als HTTP zu senden .

Der zweite Port auf meiner Liste ist 443, denn HTTPS muss schließlich auch möglich sein. Hier gibt es den gewünschten Erfolg, denn da die Daten gesichert per SSL/TLS übertragen werden, sehen für ein Analysetool die Daten alle "gleich" aus, nämlich nach irgendwelchen Daten-Paketen .
Wichtig ist der Aspekt, dass TCP als Transport Layer verwendet werden muss, da eine Filterung in der Firewall nach TCP/UDP weiterhin möglich ist.

Blöd war nun lediglich noch der Aspekt, dass auf meinem Server die Webseiten mit HTTPS angeboten werden, sprich dieser Port bereits belegt ist. Also wird ein Tool benötigt, dass diesen Port teilen kann.
Ursprünglich hatte ich gehofft, dass mein NginX dies könne... doch dies war leider nicht möglich1.

OpenVPN als erste Lösung

Wie sich herausstellte, bietet OpenVPN eine Konfigurationsoption an, um Datenpakete, die nicht für OpenVPN bestimmt sind (der Server einfach nicht versteht) weiterzuleiten.

So wurde mein OpenVPN Server kurzer Hand umkonfiguriert:

proto tcp port 443 port-share 127.0.0.1:4433

Alle Datenpakete würden nun also erst durch den OpenVPN Server gehen und anschließend zu meinem Webserver weitergeleitet werden, den ich auf Port 4433 umgestellt hatte.

Soweit, sogut... bis ich eine zweite Domain auf meinem Server hosten wollte, denn dies war nicht mehr möglich, da OpenVPN den angeforderten Domainnamen nicht weiterleitete und alles auf meiner "Default" Webseite landete .

SSLH - Ziel der Suche

Zum Glück gab es einen findigen Entwickler, der ein kleines Tool schrieb, das genau diese Probleme beheben kann!

SSLH hört nun also auf Port 443, kann durch eine Analyse des Datenstroms erkennen, um welches Protokoll es sich handelt und dann korrekt weiterleiten. Ebenso werden HTTPS Pakete nicht verändert, sodass auch eine Namensauflösung möglich ist .

Konfiguriert wird es sehr einfach über eine Konfigurationsdatei, die auf Debian-Systemen unter /etc/default/sslh zu finden ist.
DAEMON_OPTS="--user sslh -- listen 0.0.0.0:443 --ssh 127.0.0.1:22 --ssl 127.0.0.1:4433 --openvpn 127.0.0.1:1194 --timeout 5 --pidfile /var/run/sslh/sslh.pid"

Hier einmal noch die Parameter aufgeschlüsselt:

  • --user: Der System-Benutzer, unter dem sslh ausgeführt wird
  • --listen: IP und Port auf dem gelauscht werden soll
  • --ssh: Das Ziel zu dem SSH Pakete weitergeleitet werden sollen
  • --ssl: Das Ziel auf dem der HTTPS Server läuft (Hatte ich für OpenVPN verstellt, ist somit einfach geblieben)
  • --openvpn: Das Ziel zu dem OpenVPN Pakete weitergeleitet werden (Wieder der originale Port, aber weiterhin TCP)
  • --timeout: Timeout in Sekunden, bevor die Weiterleitung zu den internen Servern abgebrochen wird
  • --pidfile: Pfad, wo die Prozess-ID abgelegt werden soll

1 Seit Version 1.9.0 kann NginX auch als Proxy für Streams agieren und seit Version 1.11.5 kann auch eine Stream-Server Unterscheidung per SNI durchgeführt werden (SSL PreRead).

Dateien