On Nov 16, 2011, at 9:13 AM, -Hammer- wrote:

> "NAT neither provides nor contributes to security.
> NAT detracts from security by destroying audit trails and 
> interrupting/obfuscating
> attack source identification, forensics, etc."
> 
> Respectfully, I'm really struggling with this. Sentence one is an opinion. 
> It's all a matter of the designers viewpoint. Step 1 in most security books 
> is to not reveal ANYTHING to ANYONE that you don't have to. Taken to the 
> extreme, that could include your network layout and native addressing schema.
> 

Actually, the first rule of security in many texts I have read is "Security 
through obscurity
is no security.". While you don't reveal anything to anyone that you don't have 
to, it is
arguable that you need to reveal enough for security threats (abusers, 
attackers, etc.)
to be identified as part of being a good network citizen. As with most things, 
taken
to extreme, you reach a point of reductio ad absurdum.

> Sentence two is wrong. If employing NAT breaks your audit trail or interferes 
> with your forensics then you need to address your audit/forensics method. We 
> have correlation engines that track the "state" of a conversation (defined as 
> multiple TCP sessions in series) thru our secure architecture. We can 100% 
> tell you the public IP of a session whether it's the destination or source 
> and whether it's been NATted once or three or four times. We have 
> cookies/sessionIDs/JSessionIDs/ and Xforwarders we manipulate to allow the 
> application layer to manage the proper source of the client as well. These 
> are proven technologies that have been around for a decade. They have stood 
> up in court and been used against bad guys w/o question. While I agree that 
> this is an extra layer of complexity, the focus is to make in manageable.
> 
It may not break your own, but, it certainly breaks that of your user's victims.

Most people don't store port information in their webserver logs, for example. 
They may not have
that data to come back at you to identify the internal host in question. All 
they have is the public
IP address of your NAT box and the date/time the event occurred.

Ignoring for a moment the fact that if your clocks aren't perfectly 
synchronized, that may not
necessarily provide the needed identification, even if they do have the port 
number, without
the source port number from your side, they don't have enough for you to find 
the attacker.

> I'm not saying you are flat out wrong Owen. I am saying that it's all a 
> matter of your viewpoint.
> 

I think in considering this in general, all viewpoints must be considered. From 
the global
viewpoint, overall, I think that the case is well made that the security 
negatives associated
with NAT and the cost/impact imposed on everyone, including those outside of 
the NAT-
using organization far outweigh the (very minuscule) possible positives that 
have been
argued so far.

This leaves one and only one key benefit to NAT, which is address sharing 
(conservation).
Since we don't have a shortage of IPv6 addresses, bringing a technology forward 
into
IPv6 solely for the purpose of address sharing (conservation) makes little 
sense.

Owen


Reply via email to