Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Nessus-Users
[Top] [All Lists]

Re: Nessus performance on Linux

Subject: Re: Nessus performance on Linux
Date: Thu, 09 Aug 2007 18:58:24 +0200
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. :-/

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*. 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.

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.

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.

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
_______________________________________________
Nessus mailing list
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus

<Prev in Thread] Current Thread [Next in Thread>