Nmap Development mailing list archives
Re: Defeating a Nmap decoy scan using statistics
From: Brandon Enright <bmenrigh () ucsd edu>
Date: Mon, 21 Jul 2008 23:31:53 +0000
-----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
Current thread:
- Defeating a Nmap decoy scan using statistics Brandon Enright (Jul 14)
- Re: Defeating a Nmap decoy scan using statistics Kris Katterjohn (Jul 14)
- Message not available
- Message not available
- Re: Defeating a Nmap decoy scan using statistics Brandon Enright (Jul 21)
- Re: Defeating a Nmap decoy scan using statistics Kris Katterjohn (Jul 21)
- Message not available
- Re: Defeating a Nmap decoy scan using statistics Kris Katterjohn (Jul 14)
- Re: Defeating a Nmap decoy scan using statistics Brandon Enright (Jul 21)