Re: Qscan in NSE: qscan.nse

[Brandon Enright <bmenrigh () ucsd edu>]

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


> Well, it already only goes against open and/or closed ports.
>
> Lowering the delay can certainly make it faster, but could cost
> accuracy depending on how far you go.
>
> A problem with making it faster is that it's a timing based scan, so
> I'm not too fond of making it parallel across ports.  We're trying to
> find differences in times between ports, but we could create (or also
> mask) this ourselves by probing many ports at once.  Maybe this can
> be shown to not cause problems?
>
> Cheers,
> Kris Katterjohn


I suppose now is not the time to suggest a different model since QScan
is Doug's creation and you've already done the hard work to port it.

QScan currently sends slowly and measures latency carefully one at a
time.  What if, instead it just blasted a constant stream of probes at
many ports at once and used statistics of large numbers rather than
"being careful" to factor out measurement jitter to classify ports?

If the stddev is large then a larger N counteracts that.  We could
probably blast a large N worth of packets at ports much faster and get
just as good (if not better) a confidence interval than we currently do
by going slow to keep N small and the stddev small.

I guess what I'm saying is, if we send 10 probes carefully we get one
confidence interval.  If we sends 100 probes very fast we get another.
I *think* 100 will trump 10 even if the 100 are sent in less time than
the 10.

Perhaps Doug investigate this when he designed Qscan initially?

Brandon

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

iEYEARECAAYFAku+a/IACgkQqaGPzAsl94LXFQCfQGvb4sqmgzU0LVuRla0QeT6l
jZ8AnjvpJvBYdSUhA0ihGtrZguxP1+PJ
=O7OI
-----END PGP SIGNATURE-----
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/