[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".