Wissenshäppchen: Linux

Ich habe vor Kurzem meinen Server von Ubuntu 18.04 auf Ubuntu 20.04 aktualisiert. Dabei wurden — wie sollte es auch anders sein — viele Programme, die ich über die Paketquellen installiert habe, aktualisiert... so auch Tmux.

Tmux (Webseite) ist ein Terminal Multiplexer. Wenn einem z.B. ein Terminal (eine Shell) per SSH nicht ausreichend vorkommt, so kann man sich gleich mehrere neue Fenster erstellen lassen — ohne eine zweite (oder noch mehr) SSH Verbindungen. Für die Leute, denen die Beschreibung bekannt vorkommt: Ja, Tmux ist eine Alternative zu screen, welches ich als sehr in die Jahre gekommen ansehe.

Ich habe mir dafür vor vielen Jahren auch eine Konfiguration erstellt, die meine Bedürfnisse sehr gut abdeckt... doch mit dem Update schmiss es auf einmal sehr viele Fehler, was in der Konfiguration alles nicht mehr passte.

Ich fing also an zu fluchen und wollte von vorne beginnen, doch zum Glück hatte sich garnicht so viel getan.
Dies war die relevante Information aus dem Changelog:

* The individual -fg, -bg and -attr options have been removed; they
  were superseded by -style options in tmux 1.9.

set -g pane-border-bg black
set -g pane-border-fg white

set -g pane-border-style fg=white,bg=black

Das war natürlich leicht zu bewerkstelligen. Somit habe ich nun also eine neue Konfiguration für alle Tmux Versionen von 2.9 an aufwärts.

Kurze Einführung in Tmux

tmux

tmux new -s <name>

tmux ls

tmux at

tmux at -t <name>

tmux kill-session -t <name>

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öglich¹.

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:

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

¹ 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).