Re: Defeating a Nmap decoy scan using statistics

[Fyodor <fyodor () insecure org>]

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."

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.

> 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.

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

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.

Cheers,
-F

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