[97207] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Security gain from NAT

daemon@ATHENA.MIT.EDU (Donald Stahl)
Mon Jun 4 16:42:52 2007

Date: Mon, 4 Jun 2007 15:34:31 -0400 (EDT)
From: Donald Stahl <don@calis.blacksun.org>
To: Leigh Porter <leigh.porter@ukbroadband.com>
Cc: Jim Shankland <nanog@shankland.org>,
	Owen DeLong <owen@delong.com>, NANOG list <nanog@nanog.org>
In-Reply-To: <46646237.4050702@ukbroadband.com>
Errors-To: owner-nanog@merit.edu


> 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

home help back first fref pref prev next nref lref last post