3 ms·

> I have always understood NAT's protection to be limited to prohibiting incoming connections It doesn't actually do this. NAT rewrites the source address of o

> I have always understood NAT's protection to be limited to prohibiting incoming connections It doesn't actually do this. NAT rewrites the source address of outbound connections. Inbound connections aren't outbound connections so it does nothing to them, which means it doesn't prohibit them. That is why you don't need NAT for security: it doesn't give any in the first place.

pflanze 4y ago
> which means it doesn't prohibit them OK. I want to dig down into this. Let's say I have a router `R`, which I'm running NAT and optionally other iptables rules on. I've got a client machine `C` sitting in a private network "behind" `R`. `R` is connected to the internet via a gateway `G`. `A` is some machine out there owned by an attacker. There's a vulnerable TCP service running on `C` listening on *:1313. A | internet | G | 4.3.2.1 | | eth_public 4.3.2.77 R | eth_private 10.0.0.1 | | 10.0.0.2 C `A` can't connect to 10.0.0.2:1313 since it's not routable from their position. Thus, the fact that NAT on its own doesn't prohibit traffic to `C` doesn't matter in this scenario, practically `A` still can't reach it. So far so good? The only issue I can see is that if `A` can hack `G`, because `G` doesn't have to depend on routing to reach `R`, it can send traffic to `R` with a target address of 10.0.0.2, which `R` then forwards to `C`. I haven't verified that this works (don't have enough devices with me). Is this what you're after? Fair point. If I'd add the following rule to `G`, `C` would be safe even if `G` is hacked[*]: iptables -A FORWARD -i eth_public -d 10.0.0.0/16 -j REJECT [*] Of course that requires that any outgoing connections that `C` makes are not vulnerable against the possible packet manipulation from `G`. Am I missing anything? Edit: simplified the rule PS. I'd welcome a good pointer (book or other) on network security and also IPv6; I'm a software developer, and only occasionally dealing with networks.
- Dagger2 4y ago
  That's basically it. In that network, G can connect to C just fine. You need the firewall rule to block inbound connections, because NAT just does nothing to them. I don't have any good learning resources for this stuff, sorry. I mostly picked it all up by running it on my home network and Googling for stuff when I hit something I didn't get.

pflanze 4y ago

> which means it doesn't prohibit them OK. I want to dig down into this. Let's say I have a router `R`, which I'm running NAT and optionally other iptables rules on. I've got a client machine `C` sitting in a private network "behind" `R`. `R` is connected to the internet via a gateway `G`. `A` is some machine out there owned by an attacker. There's a vulnerable TCP service running on `C` listening on *:1313. A | internet | G | 4.3.2.1 | | eth_public 4.3.2.77 R | eth_private 10.0.0.1 | | 10.0.0.2 C `A` can't connect to 10.0.0.2:1313 since it's not routable from their position. Thus, the fact that NAT on its own doesn't prohibit traffic to `C` doesn't matter in this scenario, practically `A` still can't reach it. So far so good? The only issue I can see is that if `A` can hack `G`, because `G` doesn't have to depend on routing to reach `R`, it can send traffic to `R` with a target address of 10.0.0.2, which `R` then forwards to `C`. I haven't verified that this works (don't have enough devices with me). Is this what you're after? Fair point. If I'd add the following rule to `G`, `C` would be safe even if `G` is hacked[*]: iptables -A FORWARD -i eth_public -d 10.0.0.0/16 -j REJECT [*] Of course that requires that any outgoing connections that `C` makes are not vulnerable against the possible packet manipulation from `G`. Am I missing anything? Edit: simplified the rule PS. I'd welcome a good pointer (book or other) on network security and also IPv6; I'm a software developer, and only occasionally dealing with networks.

Dagger2 4y ago
That's basically it. In that network, G can connect to C just fine. You need the firewall rule to block inbound connections, because NAT just does nothing to them. I don't have any good learning resources for this stuff, sorry. I mostly picked it all up by running it on my home network and Googling for stuff when I hit something I didn't get.