Viele Unternehmen verwenden über Secure Shell (SSH) zugängliche Jump-Server, um auf geschäftskritische Systeme zuzugreifen. Administratoren verbinden sich zuerst mit SSH mit einem Jump-Server, möglicherweise über ein VPN, bevor sie sich mit dem Zielsystem verbinden. Diese Methode funktioniert normalerweise gut, solange ein Administrator bei der Befehlszeilenverwaltung bleibt. Etwas kniffliger wird es, wenn ein Administrator aus dem Bereich der Befehlszeile ausbrechen und stattdessen eine webbasierte Schnittstelle verwenden möchte.
Sehen wir uns das folgende Szenario an:Bob ist Systemadministrator bei Securecorp und hat gerade eine Warnmeldung erhalten, die darauf hinweist, dass ein Datenbank-Cluster aus sirius.securecorp.io besteht und orion.securecorp.io schneidet schlecht ab. Für eine erste Analyse nutzt er meist die RHEL8-Webkonsole. Die Firewall erlaubt ihm nicht, sich von seiner Workstation direkt mit diesem System zu verbinden, aber er kann über einen Jump-Server namens bastion.securecorp.io gehen .
[Das könnte Ihnen auch gefallen: 6 grundlegende SSH-Leitfäden für Systemadministratoren]
Der SSH-Befehlszeilenzugriff auf den Datenbankcluster ist unkompliziert:
[bob@workstation ~]$ ssh bastion.securecorp.io
[bob@bastion ~]$ ssh sirius.securecorp.io
[bob@sirius ~]$
[bob@workstation ~]$ ssh bastion.securecorp.io
[bob@bastion ~]$ ssh orion.securecorp.io
[bob@orion ~]$ Was aber, wenn Bob auf die RHEL8-Webkonsole von sirius.securecorp.io zugreifen möchte? und orion.securecorp.io ? Es gibt mehrere Möglichkeiten, dieses Ziel mit SSH zu erreichen, die alle eine Art Portweiterleitung beinhalten.
Haftungsausschluss :In einigen Organisationen erlauben Sicherheitsrichtlinien keine Portweiterleitung. Um sicherzustellen, dass Sie keine Regeln verletzen, wenden Sie sich bitte an Ihren IT-Sicherheitsbeauftragten.
SSH-Portweiterleitung
Unter Verwendung von SSH öffnet Bob einen TCP-Tunnel für beide Systeme, der auf den Webkonsolen-Port (9090) für sirius.securecorp.io zeigt und Port 9091 für orion.securecorp.io .
[bob@workstation ~]$ ssh -L 9090:sirius.securecorp.io:9090 bastion.securecorp.io
[bob@bastion ~]$
[bob@workstation ~]$ ssh -L 9091:orion.securecorp.io:9090 bastion.securecorp.io
[bob@bastion ~]$ Bob kann jetzt den Browser seiner lokalen Workstation auf https://localhost:9090 verweisen um auf die Webkonsole für sirius.securecorp.io zuzugreifen und https://localhost:9091 um auf die Webkonsole für orion.securecorp.io zuzugreifen .
Dieser Ansatz könnte in bestimmten Fällen gut funktionieren, hat aber seine Grenzen:
- TLS-Zertifikatsvalidierung:Der lokale Browser ist unzufrieden, da in den meisten Fällen der Common Name des Zertifikats nicht mit dem Hostnamen in der Adressleiste (localhost) übereinstimmt, sodass die Zertifikatsvalidierung fehlschlägt.
- Umleitungen:Wenn die aufgerufene Website Sie auf eine andere URL umleitet, schlägt die Verbindung fehl, da die Portweiterleitung nur für genau diesen Webserver gültig ist. Diese Situation kann beispielsweise bei der Verwendung von Single Sign-On (SSO) ein Problem darstellen.
Starten Sie einen Browser auf dem Jump-Server
Bob würde auch einen Browser wie Firefox auf dem Jump-Server starten und ihn lokal auf seiner Workstation anzeigen. SSH bietet eine Funktion namens X-Weiterleitung, die in dieser Situation verwendet werden kann.
[bob@workstation ~]$ ssh -X bastion.securecorp.io
[bob@bastion ~]$ firefox https://sirius.securecorp.io:9090 &
[bob@bastion ~]$ firefox https://orion.securecorp.io:9090 & Bei dieser Methode läuft der Browserprozess auf dem Jump-Server und die Verbindungen zu den Webkonsolen von sirius.securecorp.io und orion.securecorp.io sind erlaubt. Nur das Rendern des Browserfensters geschieht auf Bobs Workstation.
Während dieser Ansatz einige Probleme der einfachen SSH-Portweiterleitung löst, hat er auch Einschränkungen:
- Leistung:Diese Methode ist normalerweise ziemlich schlecht, da die grafische Ausgabe vom Jump-Server über das Netzwerk zur Workstation übertragen werden muss, was sehr ineffizient ist.
- Voraussetzungen:Auf dem Jump-Server muss ein Browser wie Firefox installiert sein und auf der Workstation muss ein X-Server laufen.
Dynamische Portweiterleitung eingeben
Nachdem wir die beiden vorherigen Ansätze untersucht und ihre Nachteile kennengelernt haben, wäre es großartig, eine dritte Option zu haben, die uns das Beste aus beiden Welten bietet:
- Der Browser der Workstation kann verwendet werden.
- Konnektivität und DNS-Namensauflösung sollten die gleichen sein wie auf dem Jump-Server.
Um dies zu erreichen, bietet SSH eine Funktion namens dynamische Portweiterleitung , das das SOCKS-Protokoll nutzt. In dieser Konfiguration fungiert SSH als SOCKS-Proxy und leitet den gesamten relevanten Datenverkehr über die SSH-Verbindung weiter. Dazu muss der Client (in unserem Beispiel der Browser) SOCKS-fähig sein.
Bob kann eine SSH-Sitzung mit dynamischer Portweiterleitung wie folgt initiieren:
[bob@workstation ~]$ ssh -D 1080 bastion.securecorp.io
[bob@bastion ~]$ Danach muss der Browser auf Bobs Workstation SOCKS-fähig gemacht werden. Die Firefox-Konfiguration kann folgendermaßen durchgeführt werden:
- Führen Sie den Browser zu about:preferences.
- Im Allgemein Scrollen Sie unten nach unten und klicken Sie auf Einstellungen... in den Netzwerkeinstellungen Abschnitt.
- In den Verbindungseinstellungen wählen Sie Manuelle Proxy-Konfiguration , geben Sie localhost an für SOCKS-Host , 1080 als Port und wählen Sie SOCKS v5 aus .
- Wählen Sie im selben Fenster Proxy-DNS bei Verwendung von SOCKS v5 .
Bob kann den Browser jetzt auf https://sirius.securecorp.io:9090 verweisen und https://orion.securecorp.io:9090 um die Leistungsprobleme seiner beiden Datenbankserver mit der RHEL8-Webkonsole zu analysieren. Er kann auch auf alle anderen internen Ressourcen zugreifen, als würde der Browser auf bastion.securecorp.io laufen .
Hinweis :Port 1080 ist der IANA-registrierte Port für SOCKS, aber die Verbindung kann jeden anderen Port verwenden. Die Zahlen in der SSH- und Browserkonfiguration müssen übereinstimmen.
Ich persönlich fand es sinnvoll, ein separates Browserprofil anzulegen, damit nicht ständig zwischen den Proxy-Konfigurationen gewechselt werden muss. Ein neues Profil kann durch Übergeben des -P erstellt werden Wechseln Sie zum firefox Befehl, der den Profilmanager startet . Ich habe mein Profil Jump genannt . Nach dem Erstellen eines neuen Profils wird eine leere Konfiguration erstellt. In diesem Profil habe ich die Konfiguration wie oben beschrieben angewendet, während ich mein Standardprofil unverändert gelassen habe.
Nach dem Erstellen des Profils kann Firefox mit dem folgenden Befehl gestartet werden:
[bob@workstation ~]$ firefox -P Jump
Ein weiterer hilfreicher Tipp ist das Erstellen einer hostspezifischen Konfiguration für die dynamische Portweiterleitung in Ihrer ~/.ssh/config Datei. Zum Beispiel:
[bob@workstation ~]$ cat ~/.ssh/config
Host bastion
Hostname bastion.securecorp.io
User bob
DynamicForward 1080 [ Ein kostenloser Kurs für Sie:Virtualization and Infrastructure Migration Technical Overview. ]
Abschluss
Es gibt viele Möglichkeiten, sich über einen Jump-Server mit internen Systemen zu verbinden, und die oben beschriebenen Möglichkeiten sind keineswegs erschöpfend. Meiner Erfahrung nach stellt Ihnen SSH jedoch einen sehr mächtigen Werkzeugkasten zur Verfügung, der in den meisten Fällen ohne viele Hürden verfügbar und sofort einsatzbereit ist. Die dynamische Portweiterleitung ist eines dieser Tools und hat mir geholfen, in bestimmten Situationen produktiver zu sein, also probieren Sie es bitte selbst aus.