Firejail funktioniert nicht über Socks5-SSH-Tunnel

Firejail funktioniert nicht über Socks5-SSH-Tunnel

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/firejailals 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:

  1. Ausführen tshark -i veth0a -f "port 443"über das Root-Konto
  2. Melden Sie sich als Testbenutzer per SSH beim Server an
  3. curl https://1.1.1.1Als 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.orgdemonstriert, 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 sessionpassiert. 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:

-NFü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 -Ndie 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 -DOption 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 -LOption 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 netnsOftmals reichen hierfür sogar Features aus (siehe:Namespace-Verwaltung mit IP NetNS (iproute2)).

verwandte Informationen