On 6/4/07, Donald Stahl <[email protected]> wrote:

> 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