Arguing against using public IP space
Phil Regnauld
regnauld at nsrc.org
Sun Nov 13 22:59:24 UTC 2011
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...
More information about the NANOG
mailing list