full-disclosure - Nessus experience

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <416D6A21.80508@sdf.lonestar.org>
From: bkfsec at sdf.lonestar.org (Barry Fitzgerald)
Subject: Nessus experience

If you're looking for optimized testing, you might want to try the 
following:

Allow Nessus to do your port scan and turn on optimized scanning.  This 
will tell nessus to not send attacks to services that it can't verify as 
being up.  If port 80 isn't open on the system, do you really want to 
test attacks against port 80?  This depends on your environment.  
Sometimes people set ports to not respond to sweeps and in those cases, 
setting nessus to optimized scanning will generate false negatives, but 
if you've got a standard network, this can cut down on the time it takes 
to scan, often dramatically.

Also, try playing with the host/connection thresholds.  If you're set to 
only make 5 concurrent contections to 5 hosts, you may be underutilizing 
your processor/memory.  On the other hand, overutilization of 
processor/memory can also slow the scan.  My suggestion: find a test 
subset that will take about 30 minutes with the default settings.  Then, 
monitor your system resources and run the scan.  If your CPU is running 
at 100% constantly, you're overutilized.  If you never get higher than 
50%, you might want to increase the number of concurrent connections 
that nessus can make.  Another issue is that if you're overutilizing 
your hardware, scans may get hung.  If they do, results may be lost.  
It's happened to me in the past, and it's fairly transparent (meaning 
you may not even know).

Playing with these settings will give you the options you need to cut 
the time it takes to do the scan.

             -Barry

Mr. Rufus Faloofus wrote:

>Greetings, full-disclosure!
>
>>From time to time I find myself needing to estimate the time it takes
>to run Nessus against various network ranges.  For some reason, it 
>always seems to take longer than I expect, and I'm wondering if:
>
>  1: I am doing something wrong (this is always a possibility)
>  2: Nessus has been getting slower over time 
>
>Specifically, with two laptops (each with 2GHz processor, and upwards
>of 600MB RAM), I recently tried to scan a range of two class C-size
>networks, to which I was directly connected via Ethernet.  I had already 
>done full nmaps of the hosts (this took about an hour), so I was not
>running nmap from within Nessus.  I found that after over three hours, 
>I had only been able to complete tests on 90-something hosts.
>
>This strikes me as unreasonably slow, for bulk automated testing, so
>first, I'd like to ask if these performance metrics are in line with
>others' experiences.  I'd also solicit any hints people might have
>to offer on how they optimize performance, any rules of thumb anyone
>might care to share about estimating times for Nessus runs.
>
>Thanks, in advance, to all helpful replies.
>
>--Foofus.
>
>
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.netsys.com/full-disclosure-charter.html
>
>
>  
>