[jedberg]

> This is completly incorrect. While NAT is almost always combined with a stateful firewall, the NAT itself does not provide any security.

It most certainly does. If you have an insecure device behind a nat, say something with telnet sitting open, a port scanner from the outside won't be able to find it (unless you've gone to great efforts to allow inbound connections without an established outbound connection). This is objectively better than if that device were directly addressable.

> Home devices are always going to be deployed with an allow outgoing, deny incoming firewall, regardless if they have IPv6 or not.

Not always. My last router came with the firewall off and that was just a few years ago. A lot of consumer ISPs don't bother with the firewall because they don't want to field customer service calls about things not working.

[lostlogin]

> A lot of consumer ISPs don't bother with the firewall because they don't want to field customer service calls about things not working.

This is amazing. How does it work? What stops me going to the devices behind the router?

[ATsch]

Nothing, apart from IPv6' ginormous address space.

However, I have yet to see proof of any provider that actually deployed home routers this way.

[Dagger2]

If you looked, I'm sure you could find somebody somewhere. It's not even close to common though.

[zAy0LfpBZLC8mAC]

> It most certainly does.

No, it doesn't. It's a commonly believed myth among people who don't have a clue how IP works, though.

> If you have an insecure device behind a nat, say something with telnet sitting open, a port scanner from the outside won't be able to find it

Why not?

[icedchai]

When most people say "NAT", they really mean "PAT". Port address translation: multiple private IP addresses behind a single public IP address. When a non-pedantic person sees "NAT", they understand it is actually "PAT." And in the typical consumer configuration, it actually does provide some level of security.

[Dagger2]

And when people talk about "PAT", they're actually talking about a form of NAT that doesn't block connections.

Here's how you do "PAT" on Linux: `iptables -t nat -A POSTROUTING -o wan0 -j MASQUERADE`. Notice how it's limited to outbound connections ("-o wan0")? That means it doesn't apply to inbound connections, and thus doesn't have any effect on the behavior of inbound connections.

If it doesn't have any effect on the behavior of inbound connections, then how could it possibly block inbound connections?

(The typical consumer configuration pairs "PAT" with a firewall, and the firewall does block inbound connections. It's also typical to pair it with RFC1918 addresses, which doesn't block connections but does make it much harder for most people to make the relevant connections in the first place. None of that changes the fact that "PAT" doesn't block connections.)

[icedchai]

So in other words, even without a firewall, it still provides some level of security. If your attacker can't route to your target's addresses because they are private RFC1918, they're "blocked" for all practical purposes. Yes, I know they're not technically blocked... but the typical attacker 10 hops away isn't going to know...

[zAy0LfpBZLC8mAC]

On the other hand, this might also give other people a false sense of security. Most people who tell you that "NAT provides security" think that NAT somehow drops packets, and if your network is actually targeted, this myth might well be the reason why someone ends up downloading all your files by connecting to your file server through your NAT gateway.

[Dagger2]

No... it doesn't drop connections, so it doesn't provide any security.

[icedchai]

In practical terms, it still provides some (low) level of security. If an attacker can't get IP packets to your machine because it's on an un-routable address, they can't attack it. If your attacker is getting "cooperation" from your ISP to route to it, you have bigger things to worry about it.

Obviously you should really use a firewall...

[rtempaccount1]

In standard consumer networking, say I have a /24 (say 192.168.1.0/24) and one dual-homed host performing Network Address Translation to a Internet routable address, how would an attacker easily initiate a connection to one of the hosts on that internal subnet from somewhere on the Internet?

They obviously can't address traffic directly to 192.168.1.0/24 over the Internet as that's a bogon address and the Internet routers will either reject it out of hand, or not know where to send it.

[zAy0LfpBZLC8mAC]

> They obviously can't address traffic directly to 192.168.1.0/24 over the Internet as that's a bogon address and the Internet routers will either reject it out of hand, or not know where to send it.

That's not obvious at all. Now, you obviously can't just inject a packet addressed to 192.168.1.1 anywhere on the internet and expect it to turn up on any particular LAN, but that just excludes a subset of the possible attack vectors for unwanted inbound connections.

Your ISP can still send you packets addressed to 192.168.1.1. Thus, obviously anyone compomising your ISP, or some subset of their routers can as well (hello Cisco hardcoded passwords!). Also, it has happened that ISPs failed to isolate customers from one another (think multiple customers on the same VLAN), so your neighbour could send packets addressed to 192.168.1.1 to your router's WAN interface as well. Or potentially malware on their network, if someone were to systematically exploit such a setup.

It isn't even unheard of that ISPs forgot to disable routing protocols on customer-facing interfaces and some CPE managed to advertise their RFC1918 space via RIP to their ISP's access network.

Or, for that matter, an attacker could just hook into your uplink between you and your ISP, if you are a valuable enough target, to gain access to your CPE's WAN interface.

All of those are actually solved security-wise by having a stateful firewall, which will also prevent inbound connections from anywhere else on the internet.

[raesene9]

So it does provide practical protection to use NAT in that you've reduced the set of valid attackers from "anyone on the Internet" to "people with the ability to affect the upstream router in my ISP"

That (for most average consumers) is a vastly reduced attacker set.

Security is not binary, it's a scale.

[zAy0LfpBZLC8mAC]

> So it does provide practical protection to use NAT in that you've reduced the set of valid attackers from "anyone on the Internet" to "people with the ability to affect the upstream router in my ISP"

Except it really doesn't because you haven't?

There are two practically relevant circumstances where the statement "NAT provides security" is made:

1. With regards to real-world home routers (which also come with a stateful firewall), in which case the statement is simply false: Adding or removing NAT makes no difference whatsoever for security. This is also the scenario that then is used to argue against IPv6, because IPv6 supposedly lacks this security, when it just doesn't, because the IPv6 router also comes with a stateful firewall, and adding NAT (or disabling IPv6 because of a "lack of NAT") achieves absolutely nothing security-wise, because there is no problem in the first place.

2. By people who falsely believe that NAT does in fact prevent all inbound connections and for that reason fail to configure the necessary firewall rules on more business-oriented routers, so the belief that "NAT provides security" keeps them from actually securing their network, and that in particular in scenarios where it is much more relevant than for your typical home user.

So, it is technically true that NAT could have security-enhancing effects under artificial circumstances. But under all real circumstances, it either just doesn't, or the belief that it has is what causes the configuration to be less secure than it easily could be, if only people didn't have the completely not-understood belief that "NAT provides security".