Re: GSoC feature creeper ideas

[Ron <ron () skullsecurity net>]

On Tue, 30 Mar 2010 19:43:59 -0700 Fyodor <fyodor () insecure org> wrote:
> On Mon, Mar 29, 2010 at 07:14:52PM +0000, Brandon Enright wrote:
> > 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.
>
> Thanks Brandon!  This sort of thing is very useful, especially coming
> from someone who scans even more ports than I do!
>
> > * 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.
>
> One issue is that getaddrinfo/gethostbyname are generally going to be
> more reliable than having Nmap parse host configuration files such as
> resolv.conf and sending the raw DNS requests.  After all, if
> gethostbyname() generally works on a host or else web browsers and the
> like won't work either.
> ...
One thing I noticed about gethostbyname() recently, while doing DNS work, is that, at least on Windows, it queries both 
your primary and secondary dns server multiple times, in fairly quick succession sometimes. It's pretty good at trying 
a couple times before giving up. 

> > * 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.
>
> I'd love to see more details from you on how this might work (e.g. the
> API for scripts to use, maybe a few examples of the output scripts
> might use, etc.)  Also, if scripts were able to define their own tag
> and attribute names, we might run into validation issues unless we add
> them to the DTD.  And that could be a major pain.
I wrote a function in stdnse awhile back called "format_output()". Scripts pass it a table of values, and it formats it 
using spaces (you'll recall our discussion on using "|  " versus plain spaces). It could fairly easily be modified to 
output XML data. It would definitely be a trick to figure out what to output, though. 

I definitely agree, however, that this would be great to have if we could figure out a clean way to do it. It ties in 
with integrating scripts into zenmap more cleanly, too. 

> Maybe + could speed things up and - could slow them down in terms of
> timing level.  But the thing is that we have so many performance
> options it's not clear which one(s) we'd want to let the users
> control.  And there are potential issues with changing such things at
> runtime.
I agree that this is required. More than once (including today, actually), I'll start a scan and a few minutes realize 
that, thanks to all ports scanned so far being filtered, it's getting bogus timing data (or something) and is sending 
at 1 packet/second. I'll usually stop the scan and add  --min-rate, but it'd be great to change it during the scan. I'd 
say min-rate and max-rate would be the best ones to let the user change. 

It'd also be good to have access to more data during the scan, especially the different timing datas, so an advanced 
user can figure out exactly what a scan is doing and perhaps why it's going slower than it should. I really like how 
the stacktrace is printed out if you hit <space> during the NSE phase -- something with similarly detailed information 
during the scanning phase would be cool. 

Ron

-- 
Ron Bowes
http://www.skullsecurity.org
http://www.twitter.com/iagox86
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/