Arguing against using public IP space

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...