Re: Defeating a Nmap decoy scan using statistics

[Kris Katterjohn <katterjohn () gmail com>]

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

Brandon Enright wrote:
> Fellow developers and port scanning geeks,
>
> I've been giving some thought to how to detect the real scanning host in
> a sea of decoys.

Cool stuff.

Like a lot of things, I find statistics to be fascinating, but unfortunately I
know very little beyond what can be considered common knowledge.  So you'll
have to bare with me :)

> So how do we "fix" this so that decoys don't leak information about the
> attacker?  This is what I propose:
>
> For each decoy, we generate a decoy-specific TTL offset.  We then
> change the TTL generation code to look like this:
>
> /* Time to live */
> if (ttl == -1) {
>   myttl = (get_random_uint() % 23) + 37 + decoy_offset;
> } else {
>   myttl = ttl;
> }
>
> At the very startup of Nmap, we generate a random decoy_offset for each
> decoy host that persists for the remainder of the scan.  I propose a
> random decoy offset range of [0,16) which should be good enough unless
> you pick decoys that are more than 15 hops different to the victim --
> something that is very unlikely on the current Internet.
>
> Note that the above system can also be broken but it would require that
> the attacker scanned the victim with the same set of decoys many times
> until the victim could average the decoy_offset per host to be 7.5 --
> no stealthy Nmap user would do this...

Does adding another number from a uniform range really affect the ability to
find the attacker in the decoys?  You'll have to forgive me for my lack of
knowledge in this area, but it seems like you're just making a bigger range to
work with: instead of [37, 59], you have [37, 74].  Is this not the case?

If not, and I'm wrong about the exact behavior of the range, does the offset
really need to be persistent for the decoys?  If you're just adding another
number from a range, why not keep it mixing up and change the code to just add
get_random_uint()%16 instead of the persistent decoy_offset?

Or what about even something like this:

tmp1 = 24 + (get_random_uint() % 12)
tmp2 = get_random_uint() % tmp1
myttl = tmp1 + tmp2

I just picked semi-arbitrary numbers, but you get the general idea.

> Comments welcome.

Interesting! :)

> Brandon

Thanks,
Kris Katterjohn


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBSHv+Vf9K37xXYl36AQIUvRAAq4gyUpug2gcx3BNxrtdZrVN4sAhcrafm
sfvFIPOKCsmbpYlcPT4ra1a+dxMllZvqjHG3rdPQ1XBCb/fyDVglpZvF1UsXp8BF
SY82MbvCWfxJ3ZppFYrdH+85CGt8o/QV1hdjcFkDEpebRyMyR8IeawdztuqNoQL/
71Juk6OwCJqlpzIOodNsJRRBk7DwK7GGjvVFHtyv2sF5D2D48Ty4E7e8NqwTfUSL
pJH8hMlgPlv6KMZM0VmnCfhouEfi2Oy00L50xJrRGaFJ8S6Q9fqx7nNEtm1o9nb4
0GhV/2C5IoYJfiJIrrAw0qIyKN0GnqQdNEtiNPH2YPJp/85v2AyiMuMek7O2sRL3
2Yv7xs18chNmI/PynjmD7m4CtHHhR0/ug7JrJWa+E7xL+DFKcxb1GugrJUgAk/0O
Xi6TgUKb6sB9KYpI8nBl8rb1ZjWkutMGJL4i4UsUJhA7lPc8GcY4yX//f27wtVdM
R+3Tbpc8e9kgoH6hIGpYdSKSc5bcIq8gvVQ0i6VAAEcJFNLrImjrigY/wx++muXM
/pHy2K9dI4cKi4xbD3W3tBjfn3AOj2MqytmmWVyO5Uz5e4VuVD6BstRNliFH+Laj
UCEIEcieT7ZdyajjDOLwLHZROD+tP8r0vDnOGMPtHg0wA2TPgFP5saD5X10ZaTa3
cjhASGo456M=
=T7/b
-----END PGP SIGNATURE-----

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