Ist es möglich,pwnatund SSH, um eine „Peer-to-Peer“-SSH-Verbindung zwischen zwei Maschinen herzustellen, die sich hinter zwei separaten Firewalls/NATs befinden?
Wenn dies möglich ist, welche Schritte müssen unternommen werden, um diese Funktionalität auf einem Linux-Computer innerhalb eines NAT einzurichten, auf dem ein OpenSSH-Server läuft, und wie würde ein Client hinter einem separaten NAT eine Verbindung herstellen?
Und wenn das möglich ist, stellt diese Konfiguration dann ein großes Sicherheitsrisiko dar? Könnte sich ein beliebiger SSH-Client mit dem Server verbinden, auf dem pwnat läuft?
Antwort1
Ja.Angenommen, Ihr Netzwerk sieht folgendermaßen aus:
Sie möchten per SSH von A nach B wechseln. Auf B läuft SSHD, das auf tcp://127.0.0.1:22 lauscht.
B$ pwnat -s 0.0.0.0 2022 127.0.0.1:22
pwnat auf B hört jetzt auf udp://0.0.0.0:2022 und ist so konfiguriert, dass Verbindungen zu tcp://127.0.0.1:22 zugelassen werden. Es sendet außerdem periodische ICMP-Echoanforderungen an 3.3.3.3 (fest codierte IP).
A$ pwnat -c 127.0.0.1 3022 104.16.111.208 2022 127.0.0.1 22
pwnat auf A lauscht jetzt auf tcp://127.0.0.1:3022.
pwnat auf A sendet ein ICMP-Zeitüberschreitungspaket an 104.16.111.208, dessen Nutzlast mit den ausgehenden ICMP-Echoanforderungen von NAT B übereinstimmt. NAT B erkennt, dass die Nutzlast mit den ausgehenden ICMP-Echoanforderungen übereinstimmt, und leitet das ICMP-Zeitüberschreitungspaket an B weiter. Beachten Sie, dass der IP-Header für das ICMP-Zeitüberschreitungspaket die IP von NAT A, 151.101.193.69, als Quelladresse enthält.
pwnat auf B sendet ein UDP-Paket an udp://151.101.193.69:2022 mit Quellport 2022. NAT B fügt seiner Tabelle einen Eintrag hinzu, sodass es in Zukunft alle UDP-Pakete, die es von udp://151.101.193.69:2022 bei udp://104.16.111.208:2022 empfängt, an udp://192.168.2.10:2022 weiterleitet.Beachten Sie, dass viele NATs der externen Schnittstelle einen anderen Port zuweisen. Wenn dies der Fall ist,pwnat funktioniert nicht.
pwnat auf A sendet ein UDP-Paket an udp://104.16.111.208:2022 mit Quellport 2022. NAT A fügt seiner Tabelle einen Eintrag hinzu, sodass es in Zukunft alle UDP-Pakete, die es von udp://104.16.111.208:2022 bei udp://151.101.193.69:2022 empfängt, an udp://192.168.1.10:2022 weiterleitet.
NAT A empfängt das von B gesendete UDP-Paket, gleicht es in seiner Tabelle ab und leitet es an A weiter. NAT B empfängt das von A gesendete UDP-Paket, gleicht es in seiner Tabelle ab und leitet es an B weiter. A und B können jetzt frei über UDP kommunizieren.
A$ ssh -p 3022 127.0.0.1
pwnat auf A, das auf tcp://127.0.0.1:3022 lauscht, akzeptiert die Verbindung von ssh. pwnat auf A sendet eine Anfrage an pwnat auf B (über UDP), um einen Tunnel zu tcp://127.0.0.1:22 zu öffnen. Da dies beim Start von pwnat auf B als zulässiges Host/Port-Paar aufgeführt war, stellt es die Verbindung her. Der Tunnel ist nun fertig:
ssh on A --[tcp]--> pwnat on A --[udp]--> pwnat on B --[tcp]--> sshd on B
Wenn pwnat keine Fehler hat, ist das sicherheitstechnisch nicht anders, als SSHD auf einem Server, der sich nicht hinter einem NAT befindet, der Welt zugänglich zu machen. Wenn man sich jedoch den Quellcode ansieht, scheint pwnat irgendwie zusammengehackt zu sein, und ich würde mich nicht darauf verlassen, dass es sicher ist. Der schlimmste Fall wäre die willkürliche Codeausführung auf A und B als Benutzer, der pwnat ausführt.
Antwort2
Pwnat scheint nicht authentifiziert zu sein, was ich als großes Sicherheitsrisiko betrachte. Wenn Sie mindestens eine der beiden NAT/Firewalls kontrollieren, richten Sie einfach eine Portweiterleitung/-übersetzung ein, um eine viel sicherere Konfiguration zu erreichen.