Arguing against using public IP space

Mon Nov 14 01:36:18 UTC 2011

On 11/13/2011 4:27 PM, Phil Regnauld wrote:
> That's not exactly correct. NAT doesn't imply firewalling/filtering. 
> To illustrate this to customers, I've mounted attacks/scans on hosts 
> behind NAT devices, from the interconnect network immediately outside: 
> if you can point a route with the ext ip of the NAT device as the next 
> hop, it usually just forwards the packets... Phil 

"It depends" on your NAT model.  If you take a default Cisco PIX or ASA 
device...

(a) There is an option to "permit non-NAT traffic through the 
firewall".  If not selected (nat-control) then there must be a covering 
NAT rule for any inside host to communicate with the outside interface, 
let alone outside-to-inside.

(b) By default all inbound traffic is default-deny, only "return" 
traffic for inside-initiated connections is allowed.

Yes, it's stateful (which is another argument altogether for placing a 
stateful device in the chain) but by all means, it does not allow 
outside traffic into the inside, regardless of the addressing scheme on 
the inside.

Beyond that, using 1918 space decreases the possibility that a "new, 
unexpected" path to the inside network will result in exposure.  If you 
are using public space on the inside, and some path develops that 
bypasses the firewall, the routing information is already in place, you 
only need to affect the last hop.  You can then get end-to-end routing 
of inside hosts to an outside party.  Using 1918 space, with even 
nominal BCP adherence of the intermediate transit providers, you can't 
leak routing naturally.  (Yes, it's certainly possible, but it raises 
the bar).

If the added protection were trivial, I would think the PCI requirement 
1.3.8 requiring it would have been rejected long ago.

Jeff