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
