Security gain from NAT

Dorn Hetzel dhetzel at gmail.com
Mon Jun 4 20:49:47 UTC 2007


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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20070604/72d4887f/attachment.html>


More information about the NANOG mailing list