Re: Security gain from NAT

["Dorn Hetzel" <dhetzel () gmail com>]

Well, give the junky little NAT boxes their due.  Grubby little home
networks running windoze on one or a few computers cause a lot less trouble
in the world when there is a junky little NAT box between the house LAN and
the big world outside.  Better ways to do it?  Absolutely!  Easier,
cheaper and more widely methods that at least squelch a good bit of the
crap?  Maybe not...

On 6/4/07, Donald Stahl <don () calis blacksun org> 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