Re: Idlescanning when a zombie increases IPID by 2 - patch

[Fyodor <fyodor () insecure org>]

On Mon, Jul 16, 2007 at 02:37:36PM +0100, Jirka Vejrazka wrote:
>  Lately, my friends and myself found a significant number of network
> devices that increase IPID by 2 for every packet.

Hi Jirka.  What sort of devices are these?  It would be very
interesting if you could do some -iR scanning or other sort of
sampling to determine what percentage of machines fall into this
class.

>  I modified NMAP 4.20 (stable) to support these zombies correctly,
> diff attached. Unfortunately, I'm not a C programmer (in fact, I'm not
> a programmer at all) so this code is likely to have bugs as it was a
> quick-n-dirty solution I've created quicky after seeing NMAP's code
> for the first time. I can especially see problems around OS detection
> when this modification is applied - I did not pay any attention to
> this area. I only tested the idlescanning and it was working fine.
>
>  Anyway, sharing the diff just in case somebody finds it useful and
> can use it to produce a production-quality patch :)

Hm ... you don't show a lot of confidence in your patch here :).  I
like that it is short, but I'm concerned about false positives.  This
patch appears to count any machine as an IPID_SEQ_INCR_DOUBLE if any
of the increments are 2.  But even a normal IPID_SEQ_INCR will look
like that if any single packet is sent by the machine between our
probes.  So I think it should probably test all of probes increments
to make sure they are all factors of 2.  Also, this patch looks like
it only handles 1st generation OS detection, whereas we would need a
patch which handles 2nd generation too.

If you can send an updated patch against Nmanp 4.22SOC5, and test it
thoroughly such that you have more confidence that it won't cause
problems, please do!

And in any case, thanks for the contribution.

Cheers,
-F

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