4 ms·

> 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

> 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 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. 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 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 ago
iso1210 7y ago
Why wouldn't rpf prevent the packet from being routed?
- zAy0LfpBZLC8mAC 7y ago
  You mean RPF as in "reverse path filter"? If so: Why would it?!
  - iso1210 7y ago
    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

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

iso1210 7y ago

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

zAy0LfpBZLC8mAC 7y ago
You mean RPF as in "reverse path filter"? If so: Why would it?!
- iso1210 7y ago
  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