[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfilter
Subject:    NAT as security (was Re: Ipfilter 4 alpha)
From:       Clayton Fiske <clay () bloomcounty ! org>
Date:       2002-07-29 23:45:54
[Download RAW message or body]

On Mon, Jul 29, 2002 at 06:59:06PM -0400, Jefferson Ogata wrote:
> > I would argue that such information can likely be determined even with
> > NAT. Consider all the recent hype about Microsoft products which contact
> > their servers with various information about the machine they're running
> > on.
> 
> I don't use those Microsoft products on my networks, and even if I did, they 
> would only be exposing information about those hosts.

It was just an example. There are many ways to expose information
about a host, and NAT offers little to no benefit in that department
on a per-host basis. A packet originated by a remotely-identifiable
stack is still remotely-identifiable whether it was NAT'd or not.

> Sure, and I could hire a teenager to decode and rewrite the IP header on the 
> fly as well. What's your point? We're talking about the usefulness of a 
> feature in ipf. Obviously I can deploy another technology to solve the same 
> problem that ipf solves. In fact, we can drop state and packet filtering from 
> ipf while we're at it. I can just use another box to do everything.

ipf can provide perfectly good security without NAT. It can't without
packet filtering.

The origin of the thread was about the usefulness of a feature, to
which one person offered that NAT was important for security. It is
that argument which I am discussing. I have no problem with NAT being
included in ipf. I'm only debating the reason given.

> > This can also be accomplished without NAT. It's not a feature of NAT,
> > but a by-product of it.
> 
> Again, what's your point? Any encryption algorithm can be broken by brute 
> force. Do we give up on encryption?

I know of many network security techniques which are superior to NAT.
If you can offer me a network data privacy method that's superior to
encryption, I'll be happy to use it instead.

> > Understood, however I think it is attempting to solve a problem which is
> > better solved by other methods. "Security through obscurity is no security
> > at all."
> 
> I see. Care to send me a list of your passwords?

Sure. My temporary passcode for the next 20 seconds is 192609. Knock
yourself out.

> NAT used in a well-designed implementation can make external analysis of a 
> network extremely difficult for even an advanced intruder.

Ok, you have your NAT network which is difficult to analyze externally,
and I'll have my firewalled network which is secure even if its topology
is discovered.

> If you read my note more carefully you'll observe that I don't tout NAT as a 
> super-ninja-all-in-one security tool. Perhaps you are responding to someone 
> else's post.

Yes. If you read my inital post more carefully, you'll observe that I was
in fact responding to someone else's post.

Since this is clearly a religious war, and probably off topic by now,
I will cease participation in this thread.

-c

[prev in list] [next in list] [prev in thread] [next in thread]