[ale] OT move to new Colo that wants to use NAT

Jim Popovitch yahoo at jimpop.com
Mon Nov 10 12:34:58 EST 2008


2008/11/10 Michael H. Warfield <mhw at wittsend.com>:
>        There was a hack a while back that allowed someone to spoof a packet (I
> think using source routing - another security plague) that ended up on
> the NAT device that was then delivered to the private broadcast address.

All that does is allow discovery of hosts behind a NAT.  As others
have stated, using NAT for security-by-obscurity is well... neither.
NAT doesn't effectively hide hosts that communicate through the NAT
provider.

> Now, there was some legitimate debate back then about if that was an
> implementation flaw, a bug, or a legitimate feature.  Just the fact that
> the discussion even took place tells you that NAT was not designed with
> security in mind.

I guess I see things differently than you do.  I don't need something
to be discussed and designed for a purpose in order to use it for that
purpose.  Over the years I have utilized many things outside their
intended purpose to achieve some sort of thing.  LCD monitors didn't
start out hooked to TV receivers, it took someone thinking outside the
box.... and now we have a billion dollar industry.   Using a hairpin
on a keylock isn't beyond debate and discussion....it's certainly not
what the mfg recommends... but if needed it can be utilized to achieve
an objective.    NATs weren't designed for securing networks.. and
security vendors don't want you to use a NAT when their $$
source-port-solution-dejour-in-a-box will do... but if the NAT, among
other things, works for someone why not use it?

> It still isn't and the flaw in many NAT products that
> facilitates the Kaminsky flaw illustrates that.  The NAT devices are
> working perfectly fine and yet they negate security measures taken on
> boxes behind them.

Let's not mix apples and oranges now,

The Kaminsky "flaw" exposes a design defect in DNS.  To say that NATs
break a defective protocol is quite a stretch.  NATs that didn't
respect source-port randomization prevented flawed DNS software from
trying to mask it's poor design.   Point the finger at DNS, not NAT.

>        NAT for security is using a hammer to drive a screw.  When all you have
> is a hammer, all your problems looks like a nail.

But if you don't need a jack hammer, and a regular one will do....

As many have pointed out, security is a layered and thought out
approach.  There is no one-shoe fits all scenario.

-Jim P.


More information about the Ale mailing list