← Back to context

Comment by aboardRat4

1 month ago

>This is a terrible argument. First, NAT doesn't provide the security behavior users want.

Try breaking into my machine. Login:pass are administrator:pa$$w0rd, external ip 58.19.1.129, internal ip is 192.168.1.124, the system is Windows xp, and firewall is turned off on both the computer and the box the ISP gave me.

Sure, okay. You're using RFC1918 on the internal network, so I'll need to connect to your router's WAN interface to do it, but after that it's just a matter of doing `ip route add 192.168.1.0/24 via 58.19.1.129` and then connecting to whatever I want.

How do you want to get me onto your WAN interface? Unless you happen to live near me it'd probably be easiest if you give me a tunnel. Alternately, if you change the internal network to a properly-routed non-RFC1918 range, I can demonstrate this over the Internet too.

I offered to do this once before, and the person I was talking to replied with "so, you're refusing to do it then" and blocked me. So just for the avoidance of doubt: I'm offering to do this, but if you're going to provide the test environment, you're responsible for making sure I can actually reach the test environment. Otherwise you aren't going to learn anything about NAT.

  • Right, and in a similar situation, if the internal device was given a routable ipv6 address by the ISP's cable modem, you could directly access that device.

    This isn't a hypothetical. There are ISPs who do this out of the box. I plugged a linux box into my ISP's cable modem/router in Amsterdam and immediately noticed my ssh port was getting hammered by port scanners. This isn't what most customers, especially those who aren't technically sophisticated, expect.

    • I could do it if it was using a routable v4 address too, and I can do it with either RFC1918 or ULA as well (which are both routable, just not over the Internet) if I can get close enough to send the relevant packets. NAT provides no protection against any of these.

      You don't normally see many SSH brute force attempts on v6, let alone getting hammered by them. I do see some, but it's mostly to obvious addresses like <prefix>::2, ::3 etc which I don't use, or to IPs you can scrape from TLS cert logs. If you set an ssh server up on an IP that you don't publicize, finding it is hard.

  • >How do you want to get me onto your WAN interface?

    I've already given you _all_ information you could have realistically squeezed from me. The only thing left for you is to prove that NAT is not a security measure and break into my machine, given that you already have both login and pass.

    If you had exactly those parameters with ipv6, you would have already broken in.

    • And like I said, I can do that if you get me into a place where I can demonstrate it.

      If you want me to demonstrate that the lock on your safe isn't doing anything, you have to let me into the room where the safe is. Otherwise you won't learn anything about the lock on the safe.

      1 reply →