[97218] in North American Network Operators' Group
Re: Security gain from NAT
daemon@ATHENA.MIT.EDU (Dorn Hetzel)
Mon Jun 4 17:40:06 2007
Date: Mon, 4 Jun 2007 13:49:47 -0700
From: "Dorn Hetzel" <dhetzel@gmail.com>
To: "Donald Stahl" <don@calis.blacksun.org>
Cc: "Leigh Porter" <leigh.porter@ukbroadband.com>,
"Jim Shankland" <nanog@shankland.org>,
"Owen DeLong" <owen@delong.com>, "NANOG list" <nanog@nanog.org>
In-Reply-To: <20070604152658.S56463@calis.blacksun.org>
Errors-To: owner-nanog@merit.edu
------=_Part_10155_16306537.1180990187486
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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
>
------=_Part_10155_16306537.1180990187486
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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...
<br><br>
<div><span class="gmail_quote">On 6/4/07, <b class="gmail_sendername">Donald Stahl</b> <<a href="mailto:don@calis.blacksun.org">don@calis.blacksun.org</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>> Also, it is good to control the Internet addressable devices on your network<br>> by putting them behind a NAT device. That way you have less devices to
<br>> concern yourself about that are directly addressable when they most likely<br>> need not be. You can argue that you can do the same with a firewall and a<br>> default deny policy but it's a hell of a lot easier to sneak packets past a
<br>> firewall when you have a directly addressable target behind it than when<br>> it's all anonymous because it's NATed and the real boxes are on RFC1918.<br>This is patently untrue. Using a firewall such as CheckPoint, which
<br>integrates NAT into the object definition, makes it just as likely to<br>accidentally allow traffic to a NAT'd address as it does a real address.<br>Either you are allowing access to the _object_ or you are not.<br>
<br>If you start messing with the NAT table directly then you open up another<br>can of worms- namely additional complexity and a greater opportunity for<br>mistakes.<br><br>> So really, those who do not think there is a security gain from NATing don't
<br>> see the big picture.<br>We see the big picture- we see applications with a ton of extra code to<br>handle NAT- code that may contain mistakes and end up being compromised.<br><br>We see firewalls that need more code to handle NAT'd applications- code
<br>that contains mistakes and can be compromised.<br><br>We see firewall rule sets that are more complicated and make less than if<br>NAT were not involved.<br><br>We see security/performance problems that are harder to troubleshoot
<br>because we have to dig through a NAT table to figure out which connection<br>is which.<br><br>Keep it simple. NAT is a terrible terrible hack- and it's sad that it's<br>become so accepted in the maintsream.<br>
<br>-Don<br></blockquote></div><br>
------=_Part_10155_16306537.1180990187486--
