4 ms·
This is a terrible argument. First, NAT doesn't provide the security behavior users want. The firewall on their router is doing that, not the address translatio
by bigstrat2003 10mo ago
This is a terrible argument. First, NAT doesn't provide the security behavior users want. The firewall on their router is doing that, not the address translation. Second, that firewall is on by default, blocking inbound traffic by default, so why on earth would you conjecture that router manufacturers will suddenly stop doing that if NAT isn't on by default? Third, it's not remotely likely that a user will misconfigure their firewall to not secure them any more. Non-technical users won't even try to get in there, and technical users will know better because it's extremely easy to set up the basics of a default deny config. There is no security regression here, just bad arguments.
- phire 10mo agoThe firewall on your typical IPv4 router does basically nothing. It just drops all packets that aren’t a response to an active NAT session. If the firewall somehow didn’t exist (not really possible, because NAT and the firewall are implemented by the same code) incoming packets wouldn’t be dropped, but they wouldn’t make it through to any of the NATed machines. From the prospective any machine behind the router, nothing changes, they get the same level of protection they always got. So for those machines, the NAT is inherently acting as a firewall. The only difference is the incoming packets would reach the router itself (which really shouldn’t have any ports open on the external IP) reach a closed port, and the kernel responds with a NAK. Sure, dropping is slightly more secure, but bouncing off a closed port really isn’t that problematic.
- snuxoll 10mo agoNAT gateways that utilize connection tracking are effectively stateful firewalls. Whether a separate set of ‘firewall’ rules does much good because most SNAT implementations by necessity duplicate this functionality is a bit ignorant, IMO. Meanwhile, an IPv6 network behind your average Linux-based home router is 2-3 nftables rules to lock down in a similar fashion.
- fc417fc802 10mo agoIt's also trivial to roll your own version of dropbox. With IPv6 it's possible to fail to configure those nftables rules. The firewall could be turned off. In theory you could turn off IPv4 NAT as well but in practice most ISPs will only give you a single address. That makes it functionally impossible to misconfigure. I inadvertently plugged the WAN cable directly into my LAN one time and my ISP's DHCP server promptly banned my ONT entirely.
- phire 10mo ago> In theory you could turn off IPv4 NAT as well but in practice most ISPs will only give you a single address So, I randomly discovered the other day that my ISP has given me a full /28. But I have no idea how to actually configure my router to forward those extra IP addresses inside my network. In practice, modern routers just aren't expecting to handle this, there is no easy "turn of NAT" button. It's possible (at least on my EdgeRouterX), but I have to configure all the routing manually, and there doesn't seem to be much documentation.
- zrail 10mo agoOut of curiosity how did you discover this?
- phire 10mo agoWent to double check what my static IP address was, and noticed the router was displaying it as 198.51.100.48/28 (not my real IP). I don't think the router used to show subnets like that, but it recently got a major firmware update... Or maybe I just never noticed, I've had that static IP allocation for over 5 years. My ISP gave it to me for free after I complained about their CGNAT being broken for like the 3th time. Guess they decided it was cheaper to just gave me a free static IPv4 address rather than actually looking at the Wireshark logs I had proving their CGNAT was doing weird things again. Not sure if they gave me a full /28 by mistake, or as some kind of apology. Guess they have plenty of IPs now thanks to CGNAT.
- ksndjdbdb 10mo agoInstead of all my devices being behind one IP and using an internal IP subnet, now each device has a globally routable ip address that will be used... Cool great opsec.
- aboardRat4 10mo 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.
- Dagger2 10mo agoSure, 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.
- smw 10mo agoRight, 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.
- Dagger2 9mo agoI 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.