![Firejail funktioniert nicht über Socks5-SSH-Tunnel](https://rvso.com/image/168783/Firejail%20funktioniert%20nicht%20%C3%BCber%20Socks5-SSH-Tunnel.png)
Ich habe einen Ubuntu 18.04-Server, in dem ich zwei virtuelle Schnittstellenpaare (veth0a und veth0b) erstellt und das Ende einer Schnittstelle (veth0b) einem neuen Netzwerk-Namespace (netns0) zugewiesen habe:
ip netns add netns0
ip netns exec netns0 ip link set lo up
ip link add veth0a type veth peer name veth0b
ip link set veth0b netns netns0
Anschließend habe ich Firejail verwendet, um einen bestimmten Benutzer (Testbenutzer) zu zwingen, diesen neuen Namespace standardmäßig zu verwenden, indem ich ihn /usr/bin/firejail
als Standard-Shell für diesen Benutzer festgelegt und der Datei Folgendes hinzugefügt habe /etc/firejail/login.users
:
test-user: --netns=netns0
Um sicherzustellen, dass dies funktioniert, habe ich den folgenden Test ausgeführt:
- Ausführen
tshark -i veth0a -f "port 443"
über das Root-Konto - Melden Sie sich als Testbenutzer per SSH beim Server an
curl https://1.1.1.1
Als SSH-Benutzer ausführen
Die Tshark-Ausgabe zeigt die richtige veth0b-Quell-IP-Adresse für den 1.1.1.1-Verkehr.
Das Problem tritt bei mir auf, wenn ich versuche, mit dem Testbenutzerkonto eine dynamische Socks5-Portweiterleitung über SSH einzurichten:
ssh -D 10000 -q -C -N test-user@server_ip
Wenn ich diesen Befehl von meinem Laptop oder meiner Workstation aus ausführe, kann ich einen lokalen Socks5-Server auf Port 1000 einrichten und ihn über die SSH-Verbindung tunneln. Wenn ich ihn als meinen lokalen Socks5-Proxy einrichte und gehe, wird https://api.ipify.org
demonstriert, dass der Proxy funktioniert und dass mein Laptop die IP-Adresse des Servers verwendet.
Das Problem besteht darin, dass der Sock5-Verkehr nicht durch den richtigen Namespace zu laufen scheint. Mit anderen Worten: Wenn ich auf meinem Laptop im Internet surfe und über die Testbenutzer-SSH-Verbindung mit dem Socks5-Server verbunden bin, erscheint mein Verkehr nicht in tshark -i veth0a.
Ist ein zusätzlicher Schritt erforderlich, um sicherzustellen, dass der Portweiterleitungstunnel auch Firejail verwendet? Beeinflusst das Festlegen der Shell in /etc/passwd nur eine interaktive Login-Shell? Muss ich auch die nicht interaktive Shell des Benutzers ändern /usr/bin/firejail
? Wenn ja, wie mache ich das?
Für jede Hilfe wäre ich sehr dankbar.
Antwort1
Was Sie versuchen, kann nicht funktionieren, und ich erkläre Ihnen, warum.
Ihre SSH-Verbindung verbindet sich mit dem Remote-ServersshdDaemon, der auf dem Host und nicht im Netzwerk-Namespace ausgeführt wird. Dort wird eine Instanz für Ihre Verbindung erstellt. Dann werden Sie authentifiziert, dann werden Tunnel eingerichtet,DannIhre Benutzersitzung ist eingerichtet.
Hier ist ein Auszug aus einem Beispiel, das mit einem SSH-Client der Version 7.9p1 ausgeführt wurde ssh -v -4 -D 10000 remoteuser@server
:
debug1: Offering public key: /home/localuser/.ssh/id_ed25519 ED25519 SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
debug1: Server accepts key: /home/localuser/.ssh/id_ed25519 ED25519 SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
debug1: Authentication succeeded (publickey).
Authenticated to server ([192.0.2.2]:22).
debug1: Local connections to LOCALHOST:10000 forwarded to remote address socks:0
debug1: Local forwarding listening on 127.0.0.1 port 10000.
debug1: channel 0: new [port listener]
debug1: channel 1: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug1: Sending environment.
debug1: Sending env LANG = C.UTF-8
Wie Sie sehen, passiert zuerst … Local connections to LOCALHOST:10000 forwarded to remote address socks:0
.channel 0: new [port listener]
Dann Entering interactive session
passiert. Normalerweise würde diesFeuergefängnisusw., und es wäre zu spät: Was auch immer vorher getan wird, geschieht im Host-Netzwerk-Namespace. Aber in Ihrem Fall, da Sie Folgendes verwenden -N
:
-N
Führen Sie keinen Remote-Befehl aus. Dies ist nur zum Weiterleiten von Ports nützlich.
es wird nie eine Shell ausgeführt,Feuergefängniswird nicht ausgeführt und es wird kein alternativer Netzwerk-Namespace berührt. Dies wäre auch ohne -N
die oben erläuterte Vorgehensweise nicht wichtig.
Wenn Sie das wirklich tun möchten, benötigen Sie einen separaten SOCKS5-Proxy und Sie können diese -D
Option nicht mehr verwenden. Sie können eine Instanz vonsshdoder jedes andere SOCKS5-fähige Tool (zB:dante-server
) innerhalb des Netzwerk-Namespaces und führen Sie Port-Umleitungen durch, indem Sieiptable,Nftablesoder die klassische -L
Option vonsshumleiten zuveth0b's IP und den Abhörport dieses SOCKS5-Proxys, aber das erfordert wahrscheinlich mehr als nurFeuergefängnisund ein normaler Benutzer. An diesem Punkt sollten Sie das gesamte Setup besser vonsystemdoder mit einem ausgewachsenenLXC(oderLXDoderDockeretc.) Container. ip netns
Oftmals reichen hierfür sogar Features aus (siehe:Namespace-Verwaltung mit IP NetNS (iproute2)).