Re: Nmap notes from a few conferences

[Ron <ron () skullsecurity net>]

Brandon Enright wrote:
> * Overall the public perception that Nmap is just a port scanner is
>   slowly changing.  Beyond OS and Service fingerprinting, people are
>   starting to become aware of --traceroute, NSE, Zenmap, and some of
>   the other features we've worked so hard on.
I've noticed that too.

> * There are several people that want to release some tool
>   disk/tarball/distribution but are holding off because they want to
>   integrate a new stable Nmap with all of the great features we've
>   added recently.  It's great that we're gearing up for a major
>   release, a lot of people are waiting for one.
I talked to at least one person who's waiting to include Nmap in his
pen-testing course... more in a second.

> * Nmap+NSE is making its way into hacking/pentesting/security course
>   material.  The more examples and documentation we provide about some
>   of Nmap's cooler features the faster instructors are going to add
>   more Nmap to their curriculum.
... and the second is up. I talked to Ed Skoudis (author of SANS 504 and
SANS 560, to name a couple) and told him about some of the cool scripts
I wrote. He said he'll definitely include that in his material, once the
stable version is out.

> * NSE is being presented in a very good light.  The people that are
>   aware of it seem to love it.  Leading the way seems to be
>   smb-check-vulns.  Obviously people don't think Nmap is a direct Nessus
>   competitor but smb-check-vulns and NSE are starting to get Nmap
>   mentioned alongside Nessus when discussing vulnerability scanning.
Glad to hear it!

I'm more than willing to write other vuln checks on short notice, if the
documentation is available. So if you or anybody has info or requests,
don't hesitate to hit me up (or even post to nmap-dev). I'm not always
"in the know" (the WebDAV thing was brought to my attention by one of my
co-op (intern) students, for example)

> * People don't seem to know about nbstat.nse and are still talking
>   about nbtscan.  Ron did some very good work with nbstat.  I don't
>   think people know how scan a very large network for UDP/137 quickly.
>   In our documentation I think we should try to highlight how to use
>   nbstat.nse really quickly.
Oh yeah? That's too bad, it's a useful replacement. In response to this
email, I threw together a quick blog about it. I'll wait till you
resolve the issue with massive scanning before I post it (would rather
give *working* usage example :) ).

> <snip>
> * I have now seen some *really crazy* bash command lines for grabbing
>   NSE script data out of scans.  Things like "$ nmap | sed | awk | cut |
>   egrep | sed | perl | awk | tr | sort | xargs ..." and in general I
>   think people love NSE but don't think the output is very machine
>   readable.  In fact, it is very hard to really grad NSE output from a
>   normal -oN scan.  XML makes it easy to get the script output but
>   since script output is mostly free-form people are having trouble
>   parsing it.  I don't know what the solution is but we might think
>   about working on NSE output.  Perhaps giving script the option of
>   outputting XML so that we aren't embedding -oN script output inside
>   of XML.  Also, we might think about adding a new script output format
>   like -oC that is "grepable" or "machine readable" script output.  We
>   should think about NSE script output before we have too many scripts
>   to add or change the output format.
I really think that, in the future, and before we get too deep in
scripts, we should look at another way of returning output from scripts.
My thought is to return the result as a table and leave formatting up to
Nmap. That'd let us put it into XML or user-friendly or whatever.

Right now, like you said, output is pretty freeform. Having a consistent
output format (even including meta-data like, potentially, risk level,
associated CVE, things of that nature). Dunno what would be the most
useful, but it's worth thinking about.

> * Most people don't know about Ndiff and wish out-loud that a tool like
>   Ndiff existed.  Others used a very old version of Ndiff and felt like
>   it had a lot of deficiencies.  A lot of work was put into improving
>   Ndiff and we need to make sure the public knows about Ndiff and these
>   improvements.
Is there a good source for documentation on Nmap-derived tools (Ndiff,
Ncat, etc)? I've never used them, but would love to give them a test
drive at some point.

> <snip>

> * People love Nmap and the new stuff we're adding is only making it
>   better.  We're doing a great job.
I totally agree -- I'm impressed at the different things Nmap is able to
do, and how it does them without that creeping feeling of having too
much in one tool. That's one of the big advantages of scripts and
libraries.

> Brandon

Ron

-- 
Ron Bowes
http://www.skullsecurity.org/

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