On Thu, Jul 17, 2003 at 04:10:17PM -0700, Fyodor wrote:
> I am not trying to bash Nessus at all here. I hightly recommend it as
> the best free vulnerability scanner around. I am just pointing out
> that the Nmap integration is substandard (to say the least). Perhaps
> that will change someday. I feel the most desirable improvements
> would be to pass multiple IPs to each Nmap instance,
... which would totally break the current architecture I have.
Roughly, nessusd is something like :
while(next_host_to_scan)
{
scan_host_in_background(some_host);
}
What you are asking for is to create a new category of plugin which
would be in charge of multiple IP addresses, and handle aggregated IPs.
By the way Nessus is designed, that would do something like :
while(next_host_to_scan)
{
hosts[i++] = some_host;
if(i >= MAX_HOSTS_PER_SPECIAL_PLUGIN)
{
scan_host_in_background_with_special_plugins(hosts);
for(i=0;i<MAX_HOSTS_PER_SPECIAL_PLUGIN;i++)
scan_host_in_background(hosts[i]);
}
}
This is starting to look non-pretty. But wait, we usually want to ping
the hosts before scanning them. I prefer Nessus's ping to nmap's ping,
which means I have to use another plugin and create a category ACT_PING.
I can not just sequentially ping the hosts, that would be a waste of
time, so I need to launch the plugin in background, read its input,
and see if I need to continue the scan.
So my code now becomes :
while(next_host_to_scan)
{
hosts[i++] = some_host;
if(i >= MAX_HOST_PER_SPECIAL_PLUGIN)
{
scan_host_with_ping_plugins_in_background(some_host);
/* Wait for the ping of that cluster to complete */
wait_for_ping_plugins_to_complete();
/* Remove the dead hosts from the queue */
for(i=0;i<MAX_HOST_PER_SPECIAL_PLUGIN;i++)
if(is_not_alive(host[i])) host[i] = 0;
scan_host_in_background_with_special_plugins(hosts);
for(i=0;i<MAX_HOST_PER_SPECIAL_PLUGIN;i++)
scan_host_in_background(hosts[i]);
}
}
Which starts to be a bit more complex than my initial three lines of
code. And this code is suboptimal :
- We block the scan with a cluster of 64 hosts. Meaning that
if one host is very slow to ping and portscan and to scan,
the whole scan will wait for that guy to complete before
going on.
- scan_host_with_ping_plugins_in_background() will be tricky
to write with the current architecture. The process in charge
of distributing the work among the hosts must not directly
launch plugin, so that does not simply my job
- is_not_alive() is also a bit costly to write, especially at
that location in the code (the process in charge of
distributing the work among the hosts does not know if a host
is dead or not. It simply knows that the process in charge of
scanning a given host is finished).
- Finally, the original code I was talking about is actually in
nessusd/attack.c and in real life is slightly more than three
lines (~300).
So the code would be bloated, bug-prone, suboptimal and more importantly
it would totally break the architecture around which nessusd was
designed. That's not something I want to do, even if that opens
more possibilities than "just" better supporting nmap. That breaks the
architecture which has been highly tuned and debugged over the last five
years and which is ultra sensitive (one bug in it and it means the whole
scan goes bersek).
Now, to offer better nmap support, if you could write a 'nmapd' which
reads the IPs it needs to scan from a Unix socket (or even a tcp socket,
that might open interesting possibilities), we might reach some kind of
agreement. However, 'nmapd' would need to make sure that as soon as a
host enters its queue, it starts to be scanned, except if it knows for
sure that the bandwidth is clogged.
> and to interpret
> the Nmap XML output instead of the human-readable or "grepable"
> formats. The XML output is designed for this and almost never changes
> in incompatible ways.
That would require the linking of libxml. Or libxml2. Nice support
issues in perspective for very little benefits compared to the use of
the human-readable format.
The real point with the use of the human-readable output is that people
can do a scan and upload it to nessusd at the same time they can read
it. And the human beings I know actually prefer to read a text file than
an XML file. I don't know why.
And to get back to your original statement : yes, the nessus download
page used to recommand nmap when installing Nessus. I still recommand
nmap to people who want to "pen-test" a single host. To people who want
to scan a whole network, I do not recommand Nmap, because it uses too much
memory (more than 25MB per host), which in turns makes Linux crash
(linux does not handle OOM conditions very well - to say the least).
And the 25MB of memory are pure bloat - nmap-os-fingerprints takes
300kb on disk - how come it becomes a 25MB monster once loaded ?
The fact is that I have numerous reports of people who went to
nessus.org, saw that Nmap was "mandatory", cursed about the huge list of
dependencies, installed it anyway, ran nessusd, and lost their nice
three figures uptime because they asked to scan 30 hosts in parallel
with 128mb of ram. We talked of that matter privately, I offered to
modify the Nessus FAQ to reflect this statement, and I'm still open to
discussing with you other ways to make sure people who hardly read
download instruction will understand that Nmap is not mandatory but
recommended only if they scan a couple of hosts, as my last e-mail to
you is still unanswered.
-- Renaud
