Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet. The fact that consumer cpe's typically do both nat and stateful firewalling does not mean that those functions are inseparable. -----Original message----- From: Chuck Church <chuckchurch@gmail.com> To: 'Phil Regnauld' <regnauld@nsrc.org> Cc: "nanog@nanog.org" <nanog@nanog.org> Sent: Sun, Nov 13, 2011 23:53:19 GMT+00:00 Subject: RE: Arguing against using public IP space -----Original Message----- From: Phil Regnauld [mailto:regnauld@nsrc.org]
PAT (overload) will have ports open listening for return traffic, on the external IP that's being "overloaded".
What happens if you initiate traffic directed at the RFC1918 network itself, and send that to the MAC address of the NAT device ?
In many cases, it just works. That's how IP forwarding works, after all :)
inside net ----------[NAT]-----------{ext net}----[attacker] 192.168.0.0/24 .254 1.2.3.4 1.2.3.5
S:1.2.3.5 D:192.168.0.1 next hop: 1.2.3.4
Now, on the way back *out* from the inside net, traffic from 192.168.0.1 back to 1.2.3.4 might get translated - it depends if what the NAT is programmed to do if it sees, say, a S/A packet with no corresponding SYN, on its way out. It might just get dropped. UDP would in some cases get natted, but since you know your destination port on 1.2.3.5, you know what to expect, and you can build an asymmetric connection since you control the attacking host.
Either way, you've still injected traffic into the inside net.
That makes sense, but I'm wondering if that should be considered correct behavior. Obviously a non-consumer grade router can have rules defining what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect everything coming from the outside in to either a) match up with something in the translation table, b) be a service the router itself is hosting (http, etc), or c) be a port it explicitly forwards to the same inside host. Anything not matching one of those 3 categories you'd think could be dropped. Routing without translating ports and addresses seems like the root of the issue. Chuck