> Yes you can punch holes in NAT, but that's an explicit action (well side-stepping the insanity that is UPnP) for for non-technical users sitting behind a NAT router will effectively mean that they're unlikely to receive direct inbound network attacks from the Internet.
Hole punching the NAT does not mean that the user will configure port forwarding. It means that the outside is able to send packets inside, without any explicit user action. It works, because most NAT implementations do not check the source IP address, so when user sends packets from port A to ip X, and the router receives packets to port A from ip Y, it will dutifully forward them, even if they are not related.
> without any explicit user action. It works, because most NAT implementations do not check the source IP address, so when user sends packets from port A to ip X, and the router receives packets to port A from ip Y, it will dutifully forward them, even if they are not related.
That is completely untrue. The vast majority of home routers (I would venture 99% of them) run Linux, and use the built in NAT, which does check source IP, for both TCP and UDP connections.
NAT is not a firewall, and many NAT implementations will let packets in through _if_ you know the internal IP, _and_ all routers along the way including the last one support source-routing -- which is definitely not most setups.
Furthermore, quite a bit of the home users using IPV4 these days are behind a CGNAT, which makes this even harder, as you need to source route through multiple NATs.
Hole punching without cooperation from the inside is not impossible, but it is extremely hard these days, to the point that unless its an ultra-targeted attack, no one is likely to try.
> That is completely untrue. The vast majority of home routers (I would venture 99% of them) run Linux, and use the built in NAT, which does check source IP, for both TCP and UDP connections
Of course it is true. The true thing you wrote is, that Linux is one of the few implementations that do check the source IPs. However, even if many home routers do run Linux, it does not mean that they use Linux's NAT. Many do not have enough CPU power to route/NAT at the speeds needed, so they have hw acceleration for that, and that is a separate implementation.
But hey, why do you think hole punching is a thing? Because it works, relatively large scale.
Hole punching refers to cooperative nat traversal, that is, with help from the inside - in every discussion I have ever seen.
Care to point to 3 examples of common home routers that do not check source IP? I’ve verified many TP-Links, Linksys (when they were owned by Cisco) and Netgears, and all used the kernel to NAT (and yes, they couldn’t do the 1Gb while NATting - usually 300-700 or so. And much lower if you use IPSEC)
> Hole punching refers to cooperative nat traversal, that is, with help from the inside - in every discussion I have ever seen.
If by cooperative you mean that there is outcoming connection on the port, then yes, that's cooperative. If by cooperative you mean some sort of port mapping, whether manual or UPnP, then no, you don't need that.
For details, see the paper linked in sibling response.
That paper does not support your assertion that "most NATs do not check the source address and only check the port", in fact, they only consider "endpoints" which are (ip,port) pairs.
Thinking about it, any NAT that ignores the ip part is horribly broken. I still await your examples of routers in actual use that have this behaviour.
I really don't know a lot about the hole-punching thing, can you please point me to some docs / demos / code / etc. available that would demonstrate this ?
Is there any exploit / known technique / program that allows you to explore a network behind a NAT without cooperation from inside ?
A web page can, in some circumstances, be made to probe - e.g. if you have an <img src="http://192.168.1.0"/> it will likely do an http connection to that address; whether you can actually use it for exploration depends on a lot of things.
There's a class of attacks called "DNS rebinding" that use DNS and named hosts to bypass some browser protections and cross-origin policies (see e.g. [0])
But you still need some form of cooperation - a browser request - which, as [0] points out, can be bought as an ad -- just one more reason for ad blockers.
Network Address Translation (NAT) causes well-known difficulties for peer-to-peer (P2P) communication, since the peers involved may not be reachable at any globally valid IP address. Several NAT traversal techniques are known, but their documentation is slim, and data about their robustness or relative merits is slimmer. This paper documents and analyzes one of the simplest but most robust and practical NAT traversal techniques, commonly known as “hole punching.” Hole punching is moderately well-understood for UDP communication, but we show how it can be reliably used to set up peer-to-peer TCP streams as well. After gathering data on the reliability of this technique on a wide variety of deployed NATs, we find that about 82% of the NATs tested support hole punching for UDP, and about 64% support hole punching for TCP streams. As NAT vendors become increasingly conscious of the needs of important P2P applications such as Voice over IP and online gaming protocols, support for hole punching is likely to increase in the future.
> Is there any exploit / known technique / program that allows you to explore a network behind a NAT without cooperation from inside
If you wanted to exploit this, you would have to guess the port, and it would be forwarded to a machine behind the NAT, which "owns" the open port.
> If you wanted to exploit this, you would have to guess the port, and it would be forwarded to a machine behind the NAT, which "owns" the open port.
Only iff you have static nat forwarding that port, which is almost never. With dynamic NAT (99.99% of setups) no machine "owns" the port before it sends a packet out, and once it does, it only "owns" it with respect to the IP it sent the packets to.
Hole punching the NAT does not mean that the user will configure port forwarding. It means that the outside is able to send packets inside, without any explicit user action. It works, because most NAT implementations do not check the source IP address, so when user sends packets from port A to ip X, and the router receives packets to port A from ip Y, it will dutifully forward them, even if they are not related.