5

Is it possible to use pwnat and SSH to establish a "peer-to-peer" SSH connection between two machines that are behind two separate firewalls/NATs?

If this is possible, what are the steps that would need to be taken to set up this functionality on a Linux machine inside of a NAT that is running an OpenSSH server, and how would a client behind a separate NAT connect?

Also, if this is possible, is this setup a major security risk? Could any arbitrary SSH client connect to the server running pwnat?

3
  • good luck finding somebody that understands it! the thing to do may be to set it up and do wireshark and try to figure out what it is doing. that may help a bit. It may also help when somebody makes a wild claim so you can see their arguments. If you can secure it so you can control who connects + the ssh authentication then it may be ok. – barlop Jul 5 '14 at 23:11
  • I figured it might be more complicated than the pwnat website suggests. However, if it is relatively secure and at all possible to achieve, I might still be interested in looking into it. – Kevin Gurney Jul 5 '14 at 23:12
  • I'd guess that the basic idea, is as "simple" as it is presented here under how does it work . samy.pl/pwnat I just don't understand it. e.g. I'm not familiar enough with traceroute in enough depth to know what he is discussing when he makes a comparison. – barlop Jul 5 '14 at 23:17
2

Yes. Suppose your network looks like this:

network diagram

You want to SSH from A to B. You have sshd running on B; it is listening on on tcp://127.0.0.1:22.

B$ pwnat -s 0.0.0.0 2022 127.0.0.1:22

pwnat on B is now listening on udp://0.0.0.0:2022 and is configured to allow connections to tcp://127.0.0.1:22. It is also sending periodic ICMP echo requests to 3.3.3.3 (hardcoded IP).

A$ pwnat -c 127.0.0.1 3022 104.16.111.208 2022 127.0.0.1 22

pwnat on A is now listening on tcp://127.0.0.1:3022.

pwnat on A sends an ICMP time exceeded packet to 104.16.111.208 whose payload matches the outgoing ICMP echo requests coming from NAT B. NAT B sees that the payload matches the outgoing ICMP echo requests and forwards the ICMP time exceeded packet to B. Note that the IP header for the ICMP time exceeded packet contains NAT A's IP, 151.101.193.69, as the source address.

pwnat on B sends a UDP packet to udp://151.101.193.69:2022 with source port 2022. NAT B adds an entry in its table so in the future it will forward any UDP packets it receives from udp://151.101.193.69:2022 at udp://104.16.111.208:2022 to udp://192.168.2.10:2022. Note that many NATs will assign a different port on the external interface. If this is the case, pwnat doesn't work.

pwnat on A sends a UDP packet to udp://104.16.111.208:2022 with source port 2022. NAT A adds an entry in its table so in the future it will forward any UDP packets it receives from udp://104.16.111.208:2022 at udp://151.101.193.69:2022 to udp://192.168.1.10:2022.

NAT A receives the UDP packet that B sent, matches it in its table, and forwards it to A. NAT B receives the UDP packet that A sent, matches it in its table, and forwards it to B. A and B can now communicate freely over UDP.

A$ ssh -p 3022 127.0.0.1

pwnat on A, which is listening on tcp://127.0.0.1:3022, accepts the connection from ssh. pwnat on A sends a request to pwnat on B (via UDP) to open a tunnel to tcp://127.0.0.1:22. As this was listed as an allowed host/port pair when the pwnat on B was started, it makes the connection. The tunnel is now complete:

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

If pwnat has no bugs, then this is no different security-wise from exposing sshd to the world on a server that isn't behind a NAT. However, glancing through the source code, pwnat seems kind of hacked together and I wouldn't rely on it being secure. The worse case scenario would be arbitrary code execution on A and B as the user who's running pwnat.

-1

Pwnat seems to be unauthenticated which I'd consider a major security risk. If you control at least one of the two NAT/Firewalls just setup port forwarding/translation for a much more secure setup.

7
  • Unfortunately, port forwarding is not an option for my situation. I appreciate your input, nonetheless. If it is really that insecure, then I would not want to take the risk of creating any major security holes. – Kevin Gurney Jul 5 '14 at 22:51
  • -1 you have not explained yourself at all. And if you think he can't then set up a firewall you should explain why. You make no sense. NAT does not do authentication either obviously. So your answer just doesn't make sense. pwnat is an extremely technical thing. And saying to use NAT has not answered the question at all. Also SSH does authentication obviously and this won't stop it doing so. – barlop Jul 5 '14 at 23:06
  • @barlop, so SSH would work as "normal" in this situation? I apologize if the answer to this question is obvious. I just want to be as clear as possible. – Kevin Gurney Jul 5 '14 at 23:14
  • @KevinGurney yes I am sure it would. That page on pwnat said pwnat acts as a proxy. So it's working by adding a level of indirection / a middleman, it won't stop ssh doing what it does, e.g. the key or password authentication that it does – barlop Jul 5 '14 at 23:19
  • Interesting. So, if pwnat was running on a server, do you know if any SSH client could, in theory, connect to the SSH server? – Kevin Gurney Jul 5 '14 at 23:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.