GSoC feature creeper ideas

[Brandon Enright <bmenrigh () ucsd edu>]

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

Here is a miscellaneous list of ideas it would be nice to see worked on
during the GSoC.  Most of these are feature-creeper type projects.

* Currently tcpip.cc:resolve() calls getaddrinfo() or gethostbyname()
  which are both blocking routines.  This makes forward resolution of
  targets specified by name exceptionally slow.  Nmap (probably
  nmap_dns.cc)  should be expanded to handle fast, parallel, forward
  DNS resolution.

* Right now when a host times out all data already collected about that
  host is discarded.  Oftentimes though, the host has already passed
  the portscan, service fingerprinting, and OS detection phase and most
  of the NSE scripts have finished.  A single lingering NSE script will
  cause all information to be lost.  It would be nice to see hosts that
  timeout at least have all of the information already collected
  printed and then a note at the bottom of the scan reporting the the
  host timed out and the information may be incomplete.

* Sometimes a host starts out responsive during the portscan phase but
  stops responding.  It would be nice to allow any phase to be aborted
  via runtime interaction.  Only information collected would be
  reported.  This is similar to retaining and reporting information in
  the case of host timeouts as described above.

* NSE scripts should be able to produce XML-formatted output.  Right
  now they are available in XML like ...<hostscript><script id="nbstat"
  output="...">...  The normal script output is too free-form and
  difficult to parse.  Also, output can vary based on verbosity and
  debugging level which requires a parser for each script's output to
  handle all sorts of special cases.

* Sometimes you start Nmap with parameters that are just too slow to
  get the job done while you're sitting there.  It would be nice to
  allow adjusting the --min-rate parameter with runtime interaction.
  Of course this is likely to hurt accuracy but sometimes it is worth
  it to finish job done in 5 minutes rather than 15 when you think you
  already have interesting results.

* Once in a while a misbehaving host will appear to have tens of
  thousands of ports open.  This causes the service fingerprinting
  phase to take forever.  It should be possible to specify limits like
  --max-fingerprint-ports 200 and Nmap will just pick the first 200
  ports (in any random order) rather than trying to fingerprint
  thousands.


I may follow up with more ideas as I think of them.

Brandon

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

iEYEARECAAYFAkuw/DIACgkQqaGPzAsl94JtAACcDa4FBmvbS+ME44vbqQ98v5nk
pgIAn2i7SdtVBpQ4A9rQ75+v3l8IyP0U
=2BZy
-----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/