Here are a couple of reasons why your scan may be very slow:
Point (3) will not slow down the TCP scan, only UDP. Point (4)
will slow down only TCP (currently, RST throughput limitation is
not implemented in many OS).
(1) & (2) may slow down any scan. IMHO scanning a firewall target is not very wise.
You have several options:
This is probably not a good idea, as you may miss some services.
This is a good compromise, as most services run on top of TCP. The plugins which do not know the state of an UDP port will be launched, so you risk few false negative. But who knows...
You may mix a full TCP port scan with a short UDP scan by selecting two scanners, nmap & the internal nmap TCP scan, and setting the fast scan or default scan option in nmap. So, nmap will ignore the port range and only scan what is in its services file (fast or default scan) and privileged ports (default scan only), while the TCP scanner will test the full range.
This only works against badly configured target: a snmpwalk may
give you the open ports. I just wrote a snmpwalk wrapper plugin
that does this. The source code is now in the CVS repository.
If it works, it is very quick, but I would not recommand you to
install a SNMP agent just to be able to scan your machines!
Maybe pen-testers will use this??
This is the best solution. In 1.1.x, Nessus can read a nmap
So, if you need to run Nessus several times, you're only run nmap once.
The simplest and slowest way to get this file is to run nmap:
nmap -oN output_file -sT -sU -O .... target1 target2 ...
To speed this up, you may run nmap locally on your targets, edit the files to change localhost to the external name & IP, then concatenate them and feed the full report into Nessus.
Another trick is to generate it from someother source,
nessus-tools/contrib/netstat2nmap.pl does this.
You need to get the open "inet" ports, in numbers (no symbolic name,
e.g. "telnet" instead of 23). The command varies.
It may be netstat -a -n or netstat -a -n --inet or netstat -a -n -AF inet ...
Save each result to a file that has the same name as the machine. This is IMPORTANT! netstat2nmap.pl uses the file name to know the origin of the information. The directory does not matter.
Then run :
netstat2nmap.pl target1 target2 ... > full_report.nmap
Some IP filter limits the rate of connections in direction of the protected machines to protect them against floods. Either the filter will just drop the incoming SYN packet, or send back a RST (=> connection refused).
If the firewall drops the incoming connection, nmap can handle this. As far as Nessus is concerned, increase plugins_timeout, that should do it, as TCP will try sending its SYN for a while. Maybe you should also change delay_between_tests.
If the firewall sends back a connection refused, you have no
choice. If you really want to use nmap, you'll have to play with
the timing options, e.g. set it to polite or
sneaky; but you'd better use netstat.
For Nessus, increase delay_between_tests and hope this will work.
Anyway, the best thing is to scan targets directly, not through a firewall!