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: Scanning - to fast

Subject: Re: Scanning - to fast
Date: Thu, 28 Feb 2008 17:32:28 +0800
short answer: no
long answer: if you do the initial scan using nmap and import the results,
yes. nmap has finer grained control than the default tcp scanner and you can
make it pretty stinking slow. You can also use the nmap plugin to put this
seemlessly together, but IIRC, the plugin doesn't let you access quite all
the switches that nmap can support (a bagillion, thanks Fyodor!)

longer answer yet: I asked this a couple of weeks ago, running into a
similar problem. Mr. Arboi responded back with

With Nessus3, you can limit the number of parallel TCP sessions. Apart
from this, nothing changed for nessus_tcp_scanner between Nessus2 and
Nessus3.
The maximum parallelism is mainly computed from max_checks (what you
called "Y"). safe_checks reduces it.
max_checks is clamped down to 5 for this computation.

Note that the maximum parallelism is only reached when you scan a
firewalled machine.


So, the short of it is that there is not nearly as fine grained control on
the scanner as a couple of us would like. Mr. Arboi have discussed this
before, and indeed, for most applications, the tcpscanner really does move
very well, but the price you pay is that you lose the configurability and
control. For my own work, the regular scanner is a good choice most of the
time, but I really like having the power on occasion.

What I might suggest in the meantime is making sure your pix is not running
in "debug mode", or tune your rules a bit. Last year I ran into pretty much
this exact problem with running the scan against a particular cisco product
that did virtual firewalls of a sort. Turned out I could bring the machine
to it's knees and DOS the thing with the scanner because it was trying to
log like mad and pegged the poor cpu. Turned down the logging and it stopped
DOSing it.

On Thu, Feb 28, 2008 at 5:05 PM, teknet8 <teknet8@o2.pl> wrote:

Hello

Everything worked fine for me, but i wanted to scan all ports, so i
changed it.
And it works but....to fast.

When i scan my whole network (16 networks, each class C) during network
scanning hundreds of packets per second
are being sent. My pix firewalls have 98% cpu.
I scan maximum 10 hosts at the same time with maximum 10 tests.

The problem is that i do not want to make fewer test (fewer maximum
hosts/fewer tests per host) because
after phase of network scanning everything works fine (other plugins works
fine without too much network overload). Can i in any way make network
scanning slower ?

Thanx
_______________________________________________
Nessus mailing list
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus




-- 
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
<Prev in Thread] Current Thread [Next in Thread>