Security gain from NAT

Mon Jun 4 19:34:31 UTC 2007

> Also, it is good to control the Internet addressable devices on your network 
> by putting them behind a NAT device. That way you have less devices to 
> concern yourself about that are directly addressable when they most likely 
> need not be. You can argue that you can do the same with a firewall and a 
> default deny policy but it's a hell of a lot easier to sneak packets past a 
> firewall when you have a directly addressable target behind it than when 
> it's all anonymous because it's NATed and the real boxes are on RFC1918.
This is patently untrue. Using a firewall such as CheckPoint, which 
integrates NAT into the object definition, makes it just as likely to 
accidentally allow traffic to a NAT'd address as it does a real address. 
Either you are allowing access to the _object_ or you are not.

If you start messing with the NAT table directly then you open up another 
can of worms- namely additional complexity and a greater opportunity for 
mistakes.

> So really, those who do not think there is a security gain from NATing don't 
> see the big picture.
We see the big picture- we see applications with a ton of extra code to 
handle NAT- code that may contain mistakes and end up being compromised.

We see firewalls that need more code to handle NAT'd applications- code 
that contains mistakes and can be compromised.

We see firewall rule sets that are more complicated and make less than if 
NAT were not involved.

We see security/performance problems that are harder to troubleshoot 
because we have to dig through a NAT table to figure out which connection 
is which.

Keep it simple. NAT is a terrible terrible hack- and it's sad that it's 
become so accepted in the maintsream.

-Don