RE: some nmap tools

["Hasnain Atique" <hatique () hasnains com>]

> I am also looking at how I store the data.  As I mentioned before I 
> have looked at the nmapsql, but the database design does not scale
well 

The database was intentionally kept small so that the portstat table
alone can provide pretty much all the scanning results. But .. You're
right .. It may not suit your purpose. 

> for my needs and if I am spreading the nmap processes out  to multiple

> hosts anyway, I don't want them writing directly to the DB.  The hosts

> will not have access to the core server, but the core server will have

> access to the scanning hosts.  

That's easily done, too. If you have a local nmap box in each location,
they can have their local nmapsql instances which you can collect and
consolidate into the central db. This would definitely save you the
outrageous bandwidth required to complete the scan. You'll fire up a
storm on each subnet, but not snowstorm the WAN links.

> Also with the DB design, from the last 
> time I looked at it, it did not allow for Version scanning and I plan 
> on adding that is very soon.  I am presently tweaking the 
> nmap-service-probes for my needs and environment.

I'm assuming by "Version scanning" you're referring to the -A option in
nmap 3.48. If so, nmapsql completely supports that. If nmap can find the
version, nmapsql will log it.

-- Hasnain


---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to 
nmap-dev-help () insecure org . List archive: http://seclists.org