Well, I must disagree that NAT is not an effective security tool. It is
correct to say that its original purpose is to conserve IP address space,
but it is also a very effective barrier against attack, for several reasons.
It saves the trouble of protecting hosts through ACLs, because an attacker
cannot easily select a target address. Even if he can identify an address,
he cannot route to it, unless he is only a few hops away and your network is
bleeding private routes and your ISP is accepting and announcing them, all
unlikely. And even if all of that is true, he cannot initiate a connection
to the target machine because no static translation exists in the NAT device
(unless the NAT box is truly lame). There's several layers of protection
right there (but keep reading ).

The white paper from AT&T describes a method to count hosts behind NAT if
you can attach a sniffer to a choke point near the NAT device, but that's
not easy for a remote attacker to accomplish, and even then, so what? Now he
knows how many machines are behind my NAT. He'd have to try pretty hard to
leverage that information to gain access. So, in general, I have no trouble
with NAT as a security tool if no static translations exist (but see
disclaimer below).

Todd said: "Static translations offer no security. 
Hosts behind the NAT device can be scanned/probed
just the same as if they were directly connected."

That was my thought, too, and I was really just looking for third party
confirmation to show to someone else anyway, so that's perfect.

And then Todd said: "Dynamic translations are a bit more 
difficult, but are still susceptible to session hijacking 
and various timing issues on the NAT device. Packet mangling
may enable unauthorized inbound connections. And, depending on
the sophistication of the device (or lack thereof), unmangled 
out-of-flow inbound connections may also be possible."

Well said. And now it is time for my disclaimer: in *general* I have no
problem with NAT (really, PAT) as a security tool, but Todd's points are
true (although I don't know off the top of my head how his comments would
translate to real attacks). Nonetheless, I would not rely on it if I thought
my network might endure anything more than script kiddies looking for
targets of opportunity. Hence NAT is just fine for the most home/small
networks whose owners have never done anything to piss off a real hacker,
and who don't have anything that might qualify as a valuable target.

All that goes out the window when there are static address mappings, of
course. In that case, NAT is almost worse than useless as a security tool.

My question was really somewhat rhetorical. I knew the answer, but I wanted
to get it in writing from third parties.  In a week or so we'll be having a
meeting, and there will be some present who may think NAT offers some
security benefit even when static translations are in place. I wanted some
grist from the list to use as ammo to make my point to the contrary.

Now, to follow up on Mark's question. I understand how session hijacking
works. I would not say that a dynamically NATed host is any more or less
susceptible to it than a statically translated one, or even one that is
protected by a stateful ACL. All depends on whether the attacker can
arp-poison his way into a middle position. I am very curious, however, as to
what sorts of packet mangling Todd is talking about, and how mangled packets
could be used to leverage an unauthorized inbound connection. (Not saying it
cannot be done, I just don't see how off the top of my head.)

Here, I'll provide a notional NAT table to work from. In this case, a user
has connected to yahoo, cnn, and weatherbug in the course of less than a
minute. How can NAT be fooled into permitting an inbound connection to the
Inside_Source?

        Inside_Source           Translated_Source               Destination
Age
        -----------------               --------------------
---------------         ------
        192.168.1.50:2345               216.210.201.58:35112
66.94.230.36:80         30s
        192.168.1.50:2346               216.210.201.58:35517
64.236.16.84:80         21s
        192.168.1.50:2347               216.210.201.58:35529
206.204.187.12:80               8s

--Eric

> -----Original Message-----
> From: Mark C. Ballew [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 05, 2004 2:34 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [RLUG] NAT as a Security Tool
> 
> 
> On Fri, 2004-03-05 at 14:25, Hector E. Urtubia wrote:
> > Todd is right, NAT is not really a security measure, just a 
> clever way to
> > overcome the shortage of IPv4. This paper shows a technique 
> to count the
> > hosts behind a NAT.
> > 
> > http://www.research.att.com/~smb/papers/fnat.pdf
> > 
> > wow.. hadn't posted to the list in a while...
> 
> Hector lives!
> 
> Could someone describe an attack that could happen to a NAT, 
> other than
> "it is bad, don't do it"? So far we can count how many hosts 
> there are,
> but now what?
> 
> Mark
> 
> _______________________________________________
> RLUG mailing list
> [EMAIL PROTECTED]
> http://www.rlug.org/mailman/listinfo/rlug
> 
_______________________________________________
RLUG mailing list
[EMAIL PROTECTED]
http://www.rlug.org/mailman/listinfo/rlug

Reply via email to