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
