5 ms·
> Perhaps you could expand on the threat model you're talking about where you, as a remote attacker, can somehow get a packet with an RFC1918 dest IP sent to th
by zAy0LfpBZLC8mAC 7y ago
> Perhaps you could expand on the threat model you're talking about where you, as a remote attacker, can somehow get a packet with an RFC1918 dest IP sent to the WAN port of your intended victims home router.
The threat model is really simple: If it's not under your control, then you shouldn't needlessly rely on it for security. And from the point where the wires leave your house, it's not under your control.
A random selection of possible attack scenarios:
- Hooking up a DSLAM to your DSL somewhere along the path to the CO.
- Compromising your ISP's edge routers through vulnerabilities/hard-coded passwords.
- If your router happens to also announce its RFC1918 prefix to the outside world and your ISP's misconfigured edge routers propagate those routes in their access network, being your neighbour might be enough.
- If your ISP is incompetent at configuring VLANs so you end up in the same VLAN as other customers in your area, again, being your neighbour might be enough.
(And yes, those are things that have happened.)
> It's perhaps worth pointing out that this discussion is very much in the context of a home network,
Except it really isn't. For one, the context was the home network of someone who would prefer to assign a public prefix on their home network. That is probably very much not the kind of stereotypical home network that is generally meant when you speak about "a home network" (i.e., a bunch of consumer devices on a WiFi). And also, the distinction really is only relevant in so far as specific home networks generally are not targeted, but that doesn't really change that it's still a bad idea to completely unnecessarily have a NAT run without a stateful firewall (the NAT needs to keep all the state that the firewall needs to keep anyway), and that as soon as you do have that firewall, NAT does not add anything at all.
So, yes, it might be that in some particular setups NAT without a stateful firewall is good enough for your particular needs. But that doesn't change that the general idea that "NAT prevents inbound connections" needs to die, because it is (a) far from true in the general case and (b) even where/in so far as it is true, you are almost always better off with a stateful firewall instead, so it's a bad rule of thumb both because you actually have to understand the limits of where it applies to not end up vulnerable and because the alternative actually works better with no downsides, except in rare circumstances, and even then, it's only an economical downside (namely: buying a new device that does things properly instead of using what you already have).
- jfindley 7y agoCouple of points: Most of those vectors would represent extreme levels of paranoia for the average home user. If you have sufficiently motified and skilled adversaries that they are prepared to start hijacking your DSL connection, you're probably screwed before you start. Secondly: I never said you shouldn't also have a firewall - indeed basically all NAT routers are also firewalls, and both are active by default. The added protection NAT offers is that even if an inexperienced user accidentally opens up too much in their firewall, it's unlikely that this will make their internal home network publically accessible because ordinarily attackers aren't going to be able to send packets there. This is a real and useful feature for users who don't count the Mossad in their home network threat model (which is likely almost everyone reading this).
- zAy0LfpBZLC8mAC 7y ago> Couple of points: Most of those vectors would represent extreme levels of paranoia for the average home user. That's not really a useful measure, though, because this can be said about every single vulnerability used in a mass compromise up to the second when that mass compromise happens. The difference between "extreme levels of paranoia" and "common sense security practice" is someone somewhere deciding to use that particular vulnerability in some malware because random circumstances made a bunch of vulnerabilities that individually are kinda useless align to make an exploit chain. > If you have sufficiently motified and skilled adversaries that they are prepared to start hijacking your DSL connection, you're probably screwed before you start. Yes, that is probably true. But for one, that's not the only option I listed, and also, it doesn't change that the blanket statement "NAT prevents inbound connections" is not true and is easily misapplied by people who do not understand the details. Notice how noone ever says "NAT prevents inbound connections well enough for low-value targets, kinda"? And so, people actually believe that it does and then set up vulnerable company networks. > The added protection NAT offers is that even if an inexperienced user accidentally opens up too much in their firewall, it's unlikely that this will make their internal home network publically accessible because ordinarily attackers aren't going to be able to send packets there. Talking about contrived examples ... in consumer devices, you rarely can actually configure firewall rules? What you can configure is "port forwarding", and that then automatically implies that tt is actually open not not just NATted. So, at best that applies to inexperienced users setting up somewhat professional equipment, presumably in a context where security matters a bit more and targeted attacks are more likely, and where the belief that "NAT prevents inbound connections" now actually puts them at risk? edit: And not only does it put them at risk, it also makes it hard for them to notice that they are vulnerable. If you have a firewall without NAT, it's trivial to check that inbound connections are refused. If a random access from anywhere on the internet is rejected, then your default DENY rule is probably effective. With NAT, not so much.