[ffsm8]

Just by sending the packet.

That's essentially how NAT hole punching works. It doesn't work on all routers, but most do just route the packet. You just need to know the exact configuration of the network and send the correct packet through a valid port and it goes through

https://en.m.wikipedia.org/wiki/Hole_punching_(networking)

[dfawcus]

Having implemented a commercial hole punching mechanism, and having tested it on home and commercial deployments (various UK and USA ISPs), I have to agree.

For most deployments (home and commercial) the NAT function (its session table) employs Endpoint Independent Mapping, and Endpoint Independent Filtering (see BEHAVE RFCs).

As such once something behind the NAT (say at IP:Port) has connected to an external node, any external node can connect back to that internal IP:Port location by targeting packets at the public IP':Port' mapping. This applies even if the node behind the NAT was not expecting, nor desiring it.

For home deployments, there is generally no additional firewall.

For commercial deployments, there is usually a firewall working in an Endpoint Dependent Filtering manner (usually full 5-tuple, Port and Address Dependent Filtering).

This additional firewall blocks off the unexpected connection allowed by the home scenario above, but still allows for hole punching if the behind NAT node(s) can coordinate punching via a third party to exchange their public mappings.

Notably in the home deployment case, if the attacker is working with known public ports and addresses (i.e. itself being none NATted), then it can easily bypass the filtering logic of the home NAT once it learns of the existence of the 5-tuple public flow from the home NAT.

[indigo945]

But even if the attacker knows the 5-tuple (which is a big if), how would they send a package with the correct headers? Pretty much every ISP firewall will just drop your packages if you send them with a source IP that's not yours.

Note that if you can fake source IP addresses, then a proper firewall won't protect anymore either, because all rules of the form "allow inbound connections from 1.2.3.4 only" are now broken.

[dfawcus]

I am assuming attacks against a home/retail NAT box, where the full 5-tuple is not required, only the 3-tuple being translated to on the public side of that NAT box. That being the endpoint independent mapping.

All an attacker needs to do is send packets from any source address and port, but using the same protocol (TCP/UDP) targeting that public 3-tuple, and the NAT box will allow the packet in.

I was not suggesting that the attacker resort to spoofing its source address, but use its real one. The attacker itself could be a zombie controlled by the real CnC entity, so mitigating against detection.

Finding the 3-tuple is the challenge, but not too great a one. One would start by seeing what info could be leaked from the public sites such NATed clients are connecting to.

[blueflow]

IP packets originating from or addressed to a private IP address cannot be routed through the public Internet.

[ffsm8]

You can't send a packet addressed to i.e. 192.168.1.2 oder the Internet, sure. But that wasn't what we were talking about either. You can connect to the device that's behind a nat and has that ip address. I've linked to one of the best known strategies for that, hole punching.

Feel free to read that to broaden your horizon

[blueflow]

Look what Arnavion wrote in this thread previously:

> If your firewall is disabled, an incoming v4 packet on the WAN interface with destination IP = a NAT'ed LAN device's address like 192.168.1.2 ....