Re: Defeating a Nmap decoy scan using statistics

[Brandon Enright <bmenrigh () ucsd edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sorry for letting this sit for so long.  Comments are inline.

On Mon, 14 Jul 2008 19:48:07 -0700
Fyodor <fyodor () insecure org> wrote:

> On Mon, Jul 14, 2008 at 10:57:48PM +0000, Brandon Enright wrote:
>
>
> > Up until I think it has been generally accepted that
> > if the attacker does everything "right" there isn't a way to
> > determine the real attacker.
>
> Well, I wouldn't make a claim that strong.  The Nmap man page says of
> decoys: "while this can be defeated through router path tracing,
> response-dropping, and other active mechanisms, it is generally an
> effective technique for hiding your IP address."

You right.  It's dangerous to make such broad claims.

> They are generally effective, but there are some weaknesses.  The
> biggest is perhaps that the true Nmap host still calculates timing and
> retransmission information, while of course the decoys don't.  So if
> you're in the process of being scanned by 5 IPs and want to know which
> ones are decoys, you could try firewalling off one of them, then the
> next, and so on.  When you get the right one, it will likely slow down
> and increase retransmissions because it is not getting responses any
> more.
>
> From a pcap file of a 65K port scan, you also might be able to figure
> out which one is the true scanner if you carefully analyze drops and
> timing very carefully.
>
> Nmap could ignore drops and timing for scans with decoys, but that
> would slow things down dramatically.

For the TTL averaging technique I was assuming that the victim would
only have access to logs after-the-fact.  That is, maybe netflow,
syslog, or other firewall logs.  The resolution of such logs is often
much lower that the actual packet data and so estimating drops and
retransmissions could be very hard.

Also, analyzing logs after the scan precludes active detection like
firewalling hosts in sequence.

All very good points though.

> > The heart of the problem is with this code:
> >
> > /* Time to live */
> > if (ttl == -1) {
> >   myttl = (get_random_uint() % 23) + 37;
> > } else {
> >   myttl = ttl;
> > }
> [...]
> > Statistically though we know that
> > Nmap sent a TTL of 48 _on_average_.  All the victim has to do now is
> > compute the average TTL for incoming packets.  48 - <computed
> > average> is the distance the attacker is away from the victim.
>
> That's a good point.  One option would be for Nmap to just select a
> ttl once per run and always use that.  I haven't thought mouch about
> whether that would have any disadvantages to Nmap.  It would be
> trivial to implement and might help performance, but probably not in
> any material way.

I like this idea a lot more than mine.  It is basically the same
suggestion I came up with but it eliminates the confusion of the other
randomness which doesn't help much anyways.  The new PRNG is so fast
that the performance change wouldn't even be measurable.

> If you pick your own --ttl when you launch the scan, that might
> resolve the random ttl issue.

Probably.  As long as you pick a "random" initial TTL I can't think of
a way to use the TTL to find the right attacker in the decoys.

> Alternatively, we could make the numbers 37 above more random (and
> then keep it the same throughout the scan).  Then you don't know what
> number to subtract in order to get the real hop number.

Sure.  This is just "pick your own --ttl" only Nmap does it for you and
in a good range.  The only problem I see with this is that if people
know what range Nmap uses than if Nmap gets unlucky and picks a TTL
at the top of the range it will place a maximum on the distance.

Suppose the range is now 50-200.  If you get TTLs from a host with a
value of 195 then you know the host can't be farther than 5 hops away
(or the attacker used --ttl >200).

> Cheers,
> -F

Overall I think we can reduce this "ttl problem" down to almost zero
but we can't make decoy's perfect.  I'd like decoys to be nearly
perfect from a netflow/firewall log perspective but we'll never get
them perfect when the victim can interact with the scan as it happens.

Brandon


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkiFHHoACgkQqaGPzAsl94IlXACfRIAqAXdpndYxfASgTmxcUx/S
RnMAoLGwGP8Ut1yDz7TiGU4yi7SVyDIf
=lAko
-----END PGP SIGNATURE-----

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org