On 8/9/07, Richard van den Berg <richard@vdberg.org> wrote:
Doug Nordwall wrote:
max_checks and max_hosts are both set to 2.
this will make scanning even one machine pretty slow. 2 checks at a time
:)
The reason I set them so low is because the high load on my scan engine
caused a lot of false positives. Mostly checks that try to kill a
service and then wait for 1 second to see if the service still responds.
With a highly loaded system, that 1 seconds is spent waiting for CPU
cylces. :-/
seems like here is a chicken and egg issue there somewhere.
while totally unscientific (otherwise known as in my experience), I've
seen nmap run via nessus be more resource intensive than the built in
tcp scanner.
I am doing the nmap scanning *first*.
I wondered, I wasn't completely certain however.
So all nessus has to do is load
the open ports from the gnmap file. This is essentially 65536 greps
which cannot be an issue. This is confirmed by the nessj progress meter
which shoots up to 100% for the port scans rather quickly.
Did you click on the consider unscanned ports as closed checkbox? It sounds
like from this description you are running the nmap greps and the regular in
nessus scans as well.
I'm not familiar with nessj, although i've heard of it. Only so many hours
in a day and all
does the host have any countermeasures on it? firewall with drop rules
or IPS? A very slow rate in my experience usually points to it not
getting responses back from the host.
No on both accounts. I am scanning across a WAN though, the RTT is
350ms. Tcpdump doesn't show any delays in the packet stream except for a
FIN of HTTPS connections. The FIN always comes more than 4 seconds after
the previous packet of that connection. Weird.
4 seconds per FIN on HTTPS? eesh. is that on every HTTP plugin? that would
take a very long time indeed.
Try tailing (tail -f) your nessusd.messages and nessusd.dump files and
see what portion of the scan it's at. You can also figure out some of
this with an ps -efwww
Nessj gives me that info with one glance. It has a 0-100 progress meters
for the port scan and attacks per target host. It's the attacks that are
slow.
ah, good. Is it hanging on the HTTP attacks then? if not, which ones?
I'm starting to think that the RTT is the reason that the scans take a
very long time to complete. However, this doesn't explain the 60-80% of
kernel CPU time. If this was lower at least I could run more scans or
scan more hosts at the same time. If anything, with slow responses from
a target the CPU usage should be lower, not higher.
Thanks for the suggestions.
Sincerely,
Richard van den Berg
--
Doug Nordwall
Unix, Network, and Security Administrator
You mean the vision is subject to low subscription rates?!!? - Scott Stone,
on MMORPGs
_______________________________________________
Nessus mailing list
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus
