Chuck Church (chuckchurch) writes:
When you all say NAT, are you implying PAT as well? 1 to 1 NAT really provides no security. But with PAT, different story. Are there poor implementations of PAT that don't enforce an exact port/address match for the translation table? If the translation table isn't at fault, are the 'helpers' that allow ftp to work passively to blame?
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. Etc...