Re: NATs are NOT Firewalls

On Thu, 19 Jun 2003 03:57:40 EDT, Daniel Senie <dts(_at_)senie(_dot_)com>  said:

> Maybe YOU should read it, and explain how this is useful for attacking the 
> hosts behind a NAPT box. The technique described in this paper uses 
> variations in the IPid field as evidence of more than one host generating 
> packets. Fine. So you plunk a box just upstream of the NAT box, and now you 
> can determine how many ACTIVE hosts are talking to sites outside the NAPT box
*sigh*. OK. You're correct.  *BY ITSELF*, there's not much of an attack
vector here.  On the other hand, every hacker who has graduated from the
ranks of the ankle-biting script kiddies knows that target recon is something
that you want to do if feasible.

Information leakage makes it a lot easier....

Let's pretend you're a hacker.  You've found a box that you suspect is a NAT.
What's the FIRST thing you want to know? Yep - verify that it IS a NAT.  And lo
and behold, if you can enumerate more than one host behind it, it's probably a
NAT.

What's the second thing you probably want to know?  What techniques are likely
to work, of course.  And your choice of attack tools will quite likely be
swayed dramatically if you suspect there's only 3-4 boxes behind the NAT
because the NAT is a front end for a SOHO or similar, or if there's only 3-4
boxes because there's a DMZ behind it, or if you suspect there's hundreds back
there.

And all sorts of info leaks out in the oddest ways.  For instance, I save the
rfc822 headers from my mail.  So far in June, I've caught 38,836 Received:
lines from off-campus hosts, with 12,211 unique sources.  Of these, 2,597, from
409 different sources, contain an IP address literal from 1918 space.  Those
often give (a) a target IP inside the 1918 space and (b) the clue (dependent on
the MTA) that perhaps the site doesn't have care/clue enough to get PTR records
set up....

pgpoUthZUhC4U.pgp
Description: PGP signature