- NAT punching does require cooperation of programs on the protected machines, though, no? How is it different from them inviting traffic in any other way (like, requesting a page via https from an infected server could hijack the client on the protected machine if the client has security holes in the right places; the https client is willing to get traffic here, just as some VoIP program is willing to receive a call)?
- And is it any different from a stateful firewall on IPv6?
> NAT punching does require cooperation of programs on the protected machines
As does listening to a port.
> And is it any different from a stateful firewall on IPv6?
Hum, not much. And that's the point, all of those are basically the same. NAT doesn't give you much security, and NAT without a firewall usually gives you less security than a firewall, since NAT usually is configured for connectivity, and a firewall for protection.
> > NAT punching does require cooperation of programs on the protected machines
> As does listening to a port.
Listening on a port is for incoming connections, exactly the kind that we're blocking with either a (stateful) firewall or NAT. Listening on a port is a declaration of a program (a server) to communicate with whichever counter party can connect to this port (until the server program decides to close the connection), and limiting that reach is the topic here.
NAT hole punching is more like an outgoing connection in that the client agrees to communicate with a particular single counter party for each punch. That's why I made the comparison to opening an https connection to a server. The risks look basically the same to me (the client has to trust the server in the https case, and the client has to trust the intermediating server in the NAT hole punching case to intermediate with the right client; admittedly it additionally has to trust the other peer (e.g. that its compressed data doesn't try to break decoders), but in cases where it communicates with another party via a server the situation may be the same again (unless the server re-encodes the data and does that securely)).
> And that's the point, all of those are basically the same.
That's a relief for me to hear, as I started to doubt myself whether I am missing something ("why is it not OK to use NAT to block incoming connections?").
> since NAT usually is configured for connectivity, and a firewall for protection.
Sure, a firewall can add additional restrictions. I have always understood NAT's protection to be limited to prohibiting incoming connections (unless when adding port forwarding), while allowing outgoing connections including NAT hole punching.
I'm also talking in the context of configuring a Linux machine via iptables (where you configure both NAT and other firewalling rules). Maybe you're thinking more in terms of consumer "NAT" vs. consumer "firewalling" devices and their respective capabilities. Or maybe this whole "don't consider NAT to be a security feature" movement is just to pull people towards IPv6 by saying they don't need NAT to be as secure (or better if they configure additional restrictions)?
The point here is that the movement against IPv6 for security reasons is disingenuous or even outright dishonest. Those security reasons don't exist.
Personally, I have never seen any argument for IPv6 based on security (except for some very fringe ones about address enumeration). But if anybody makes one to you, well, it would be disingenuous, or maybe even dishonest too. There is no security-based argument either way.
> 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.
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.
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.
That is usually not true. NAT punching is a thing for decades now.