SSH und PWNAT für die SSH-Verbindung zwischen zwei separaten NATs

Ist es möglich, mit pwnat und SSH eine Peer-to-Peer-SSH-Verbindung zwischen zwei Computern herzustellen, die sich hinter zwei separaten Firewalls / NATs befinden?

Wenn dies möglich ist, welche Schritte müssten unternommen werden, um diese Funktionalität auf einem Linux-Computer in einem NAT einzurichten, auf dem ein OpenSSH-Server ausgeführt wird, und wie würde sich ein Client hinter einem separaten NAT verbinden?

Wenn dies möglich ist, stellt dieses Setup ein erhebliches Sicherheitsrisiko dar? Konnte sich ein beliebiger SSH-Client mit dem Server verbinden, auf dem pwnat ausgeführt wird?

— Kevin Gurney
quelle

Viel Glück, jemanden zu finden, der es versteht! Die Sache, die zu tun ist, kann sein, es einzurichten und wireshark zu tun und zu versuchen, herauszufinden, was es tut. das kann ein bisschen helfen. Es kann auch hilfreich sein, wenn jemand eine wilde Behauptung aufstellt, damit Sie ihre Argumente sehen können. Wenn Sie es sichern können, um zu steuern, wer die ssh-Authentifizierung verbindet, ist es möglicherweise in Ordnung.

— Barlop

Ich dachte, es könnte komplizierter sein, als die pwnat-Website vorschlägt. Wenn es jedoch relativ sicher und überhaupt realisierbar ist, könnte ich immer noch daran interessiert sein, es zu untersuchen.

— Kevin Gurney

Ich denke, dass die Grundidee so "einfach" ist, wie sie hier unter "Funktionsweise" dargestellt wird. samy.pl/pwnat Ich verstehe es einfach nicht. ZB kenne ich Traceroute nicht genau genug, um zu wissen, worüber er spricht, wenn er einen Vergleich anstellt.

— Barlop

Antworten:

Ja. Angenommen, Ihr Netzwerk sieht folgendermaßen aus:

Sie möchten SSH von A nach B ausführen. Sie haben sshd auf B ausgeführt. es lauscht auf tcp: //127.0.0.1: 22.

B$ pwnat -s 0.0.0.0 2022 127.0.0.1:22

pwnat on B lauscht 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 auch 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 on A hört jetzt auf tcp: //127.0.0.1: 3022.

pwnat on 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 Der IP-Header für das ICMP-Zeitüberschreitungspaket enthält die IP-Adresse 151.101.193.69 von NAT A als Quelladresse.

pwnat on B sendet ein UDP-Paket an udp: //151.101.193.69: 2022 mit dem Quellport 2022. NAT B fügt einen Eintrag in seine Tabelle ein, sodass es in Zukunft alle von udp: //151.101.193.69 empfangenen UDP-Pakete weiterleitet : 2022 at udp: //104.16.111.208: 2022 to udp: //192.168.2.10: 2022. Beachten Sie, dass viele NATs einen anderen Port auf der externen Schnittstelle zuweisen. In diesem Fall funktioniert pwnat nicht .

pwnat on A sendet ein UDP-Paket an udp: //104.16.111.208: 2022 mit dem Quellport 2022. NAT A fügt einen Eintrag in seine Tabelle ein, sodass es in Zukunft alle von udp: //104.16.111.208 empfangenen UDP-Pakete weiterleitet : 2022 at udp: //151.101.193.69: 2022 to udp: //192.168.1.10: 2022.

NAT A empfängt das von B gesendete UDP-Paket, ordnet es seiner Tabelle zu und leitet es an A weiter. NAT B empfängt das von A gesendete UDP-Paket, ordnet es seiner Tabelle zu und leitet es an B weiter. A und B können jetzt kommunizieren frei über UDP.

A$ ssh -p 3022 127.0.0.1

pwnat on A, das auf tcp: //127.0.0.1: 3022 lauscht, akzeptiert die Verbindung von ssh. pwnat on A sendet eine Anfrage an pwnat on B (über UDP), um einen Tunnel nach tcp: //127.0.0.1: 22 zu öffnen. Da dies als zulässiges Host / Port-Paar aufgeführt war, als pwnat auf B gestartet wurde, wird die Verbindung hergestellt. Der Tunnel ist jetzt fertig:

ssh on A --[tcp]--> pwnat on A --[udp]--> pwnat on B --[tcp]--> sshd on B

Wenn pwnat keine Fehler aufweist, ist dies sicherheitstechnisch nicht anders, als sshd der Welt auf einem Server zur Verfügung zu stellen, der sich nicht hinter einem NAT befindet. Beim Blick durch den Quellcode scheint pwnat jedoch irgendwie zusammengehackt zu sein, und ich würde mich nicht darauf verlassen, dass es sicher ist. Das schlimmste Szenario wäre die Ausführung von willkürlichem Code auf A und B als Benutzer, der pwnat ausführt.

— Schneeball
quelle

-1

Pwnat scheint nicht authentifiziert zu sein, was ein großes Sicherheitsrisiko darstellt. Wenn Sie mindestens eine der beiden NAT / Firewalls steuern, richten Sie einfach die Portweiterleitung / -übersetzung ein, um ein viel sichereres Setup zu erzielen.

— MacLemon
quelle

Leider ist die Portweiterleitung in meiner Situation keine Option. Trotzdem danke ich Ihnen für Ihre Beiträge. Wenn es wirklich so unsicher ist, möchte ich nicht das Risiko eingehen, größere Sicherheitslücken zu schaffen.

— Kevin Gurney

-1 Sie haben sich überhaupt nicht erklärt. Und wenn Sie der Meinung sind, dass er keine Firewall einrichten kann, sollten Sie erklären, warum. Du ergibst keinen Sinn. NAT macht offensichtlich auch keine Authentifizierung. Ihre Antwort ergibt also einfach keinen Sinn. Pwnat ist eine extrem technische Sache. Und zu sagen, NAT zu benutzen, hat die Frage überhaupt nicht beantwortet. Auch SSH führt offensichtlich eine Authentifizierung durch und dies wird es nicht aufhalten.

— Barlop

@barlop, also würde SSH in dieser Situation wie "normal" funktionieren? Ich entschuldige mich, wenn die Antwort auf diese Frage offensichtlich ist. Ich möchte nur so klar wie möglich sein.

— Kevin Gurney

@ KevinGurney ja, ich bin sicher, es würde. Diese Seite auf pwnat besagt, dass pwnat als Proxy fungiert. So funktioniert es durch einen Dereferenzierungsebene / Vermittler hinzufügen, wird es nicht aufhören ssh zu tun , was es tut, zum Beispiel des Schlüssels oder Passwort - Authentifizierung , die es tut

— barlop

Interessant. Wenn pwnat auf einem Server ausgeführt wird, wissen Sie dann, ob ein SSH-Client theoretisch eine Verbindung zum SSH-Server herstellen kann?

— Kevin Gurney