[zAy0LfpBZLC8mAC]

> So how are you, with your publically routed IP of (for example) 56.10.10.100 planning to connect to the GP, who has (for example) a public egress IP of 73.100.100.10, but is in fact using NAT, and his desktop's real IP is 192.168.1.20?

By sending a packet to them that has the destination address 192.168.1.20?

You seem to be making the assumption that the only way to send a packet to the WAN interface of a NAT router is through the public internet. While being able to do that widens the attack surface, it absolutely is not the only way, and your threat model is broken if you assume that it is.

> I realise NAT is unpopular with networking purists, but trying to claim that it doesn't prevent inbound connections seems to be overstating your case quite severely.

No, that belief is one of the big myths that keeps people configuring insecure networks.

> I'd also note that if your firewall is stateful or not is irrelevant for the point you were trying to make - oldfashioned stateless firewalls can also block inbound connections just fine.

That's true and it's not. Of course, you can block all connections with a stateless firewall, and thus obviously also block all inbound connections. But a stateless firewall is very limited in selectively blocking specifically inbound connections across random protocols, and especially so if it doesn't know detailed information about your network and services to infer what constitutes a packet establishing a connection, while with a stateful firewall you can essentially just say "drop inbound connections" without any further details about your networks, and it'll do a good job at it.

Plus, you could argue about whether, for example, dropping TCP SYNs but forwarding all other TCP packets actually counts as "blocking inbound connections", given that tons of potential "inbound packets" will be forwarded to your internal systems and you really rely on your internal systems not accepting any of them as "establishing a connection" or possibly just being vulnerable to those "inbound but not establishing a connection" sort of packets.

[jfindley]

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.

It's perhaps worth pointing out that this discussion is very much in the context of a home network, so well-actually arguments about "maybe I have a GRE tunnel set up to this random users home router" or "maybe I'm their ISP and want to break into the router I supplied them with" won't really carry much weight - you mentioned the concept of a broken threat-model, but a threat model needs to be grounded in reality, and the reality is that unless you go far out of your way to do silly things NAT is a reasonable and practical protection for home users against accidentally exposing services on their network to the internet at large.

[zAy0LfpBZLC8mAC]

> 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]

Couple 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]

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

[jfindley]

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

No. The difference between the vectors you described and "mass compromise malware" is that your vectors are targetted at one (or a very small number of) individual user(s), who are probably screwed either way, if a skilled attacker really wants to mess with them this badly. There is no realistic way to hijack DSL connections en-masse, and an attacker skilled enough to compromise an entire ISP to the point they can start doing these sorts of things has far better options available to them than anything we're talking about here. There's a huge difference between mass-deployed malware and complex targetted attacks, which is a point you seem to continually miss in this thread.

> it doesn't change that the blanket statement "NAT prevents inbound connections" is not true

More verbosely this could have been expressed as "NAT prevents inbound connections unless you have a NAT device that for some reason accept incoming packets for which it has no session and pick a device on the private network to route these packets to, not to mention the difficulty of getting those packets there in the first place". This "unless" is not normally needed though, as this is widely regarded to be a sufficiently difficult thing to achieve it's not worth mentioning.

>in consumer devices, you rarely can actually configure firewall rules?

On every consumer firewall/NAT box I've ever seen, it was possible to configure firewall rules. Perhaps this is a regional difference?

I also note that although you've presented a couple of ways you might be able to send arbitrary packets at the public IP of the NAT device (although I strongly dispute how practical they are), this isn't yet sufficient to manage to connect to arbitrary machines behind the NAT device - you must also find a way to force the NAT device to accept packets for which it has no existing session. Otherwise you're really just limited to things like tcp hijacking to try to MiTM a session - something you can likely do regardless of the presence of a firewall, if you really care enough.

[zAy0LfpBZLC8mAC]

> There is no realistic way to hijack DSL connections en-masse

So, exactly what people always say exactly up to the point where someone demonstrates the exploit chain?

> and an attacker skilled enough to compromise an entire ISP to the point they can start doing these sorts of things has far better options available to them than anything we're talking about here.

So ... exactly what people always say exactly up to the point where someone launches some malware?

> There's a huge difference between mass-deployed malware and complex targetted attacks, which is a point you seem to continually miss in this thread.

Except there really isn't. Yes, obviously there is a difference, but you can't measure how well an attack can be scaled based on how well it has been scaled. Now, deploying rogue DSLAMs sure is really impractical to scale, so that's not a concern other than for targeted attacks. But abusing misconfigured ISP networks might very well be easy to scale under the right circumstances. Mind you that the attacker doesn't have to be an actual neighbour, it might very well be enough to compromise one machine in a neighbourhood and then start attacking the neighbourhood from there, and if this is a misconfiguration of a large ISP, you might be able to just leverage an existing bot net to compromise large parts of their customer base.

> More verbosely this could have been expressed as "NAT prevents inbound connections unless you have a NAT device that for some reason accept incoming packets for which it has no session

May I rephrase this slightly for clarity?

"NAT prevents inbound connections unless it doesn't happen to be paired with a stateful firewall."

Erm ... yeah, thanks for making my point for me? Except the actually non-confusing way to put this is "NAT does not prevent inbound connections, but stateful firewalls do", obviously.

> and pick a device on the private network to route these packets to

Could it be that you just don't even understand the attack? This sounds like you think that the owner of the router would have to explicitly configure a target that could be attacked or something? If that's how you understand it, you might want to brush up on how IP routing works.

> This "unless" is not normally needed though, as this is widely regarded to be a sufficiently difficult thing to achieve it's not worth mentioning.

Erm ... in other words: People are generally mistaken about this? Yeah, I agree.

> On every consumer firewall/NAT box I've ever seen, it was possible to configure firewall rules.

As in, if you want to make some internal service publicly reachable, you have to separately set up a "port forwarding rule" and a "firewall rule"? That sure is how professional equipment/software does it, but not something I have seen in home routers in a long time.

> I also note that although you've presented a couple of ways you might be able to send arbitrary packets at the public IP of the NAT device

No, I haven't. I have been talking about sending packets to the private IP addresses, the public IP address is completely not involved in any of this.

> this isn't yet sufficient to manage to connect to arbitrary machines behind the NAT device - you must also find a way to force the NAT device to accept packets for which it has no existing session.

Yeah, it seems like you don't understand IP routing or how the attack works.

No, you don't. You just don't. That's not how NAT works or how IP works. Unless there is a stateful firewall on that device, in which case removing the NAT does not change anything about being able to establish inbound connections.

To take the example of a common VLAN with your neighbours: What you need is the MAC address of the WAN interface of your neighbour that you want to attack. You might be able to just guess it, or you could find it via an ARP request, or maybe you just can see some random packets leaking from the switch. Then, you send an IP packet with your public IP address as the source IP address and your MAC address as your source MAC address to their MAC address as the destination MAC address and their internal IP address as the destination IP address. Their router, being an IP router with NAT but without a stateful firewall, will check their NAT state for the connection, not find it, check NAT rules, not find any either, therefore not rewrite anything, then do a routing table lookup which says that it should be delivered on the LAN interface, and then, potentially after an ARP lookup, deliver it to the LAN. That just is how IP works. Again: unless there is a stateful firewall on the device.

[iso1210]

Why wouldn't rpf prevent the packet from being routed?

[zAy0LfpBZLC8mAC]

You mean RPF as in "reverse path filter"? If so: Why would it?!

[iso1210]

Oh yes, it's a packet aiming to 192.168, not a spoof packet from 192.168. Ignore me, I'll go back to sleep :D