[I continue an old thread because I just ran into this kind of troubles recently] Javier Fernandez-Sanguino <[EMAIL PROTECTED]> writes:
> What if the scan host running Nessus gets black listed throughout the > test? That might be reasonable for Nessus to cross check and warn the > user if that happens. If Nessus is black listed then check_ports.nasl will report some closed ports. If all ports are closed, it will print the message that you suggested (Renaud implemented it); if many ports are closed, then you can suppose that you were temporarily blacklisted by some "anti port scanner" during the execution of check_ports.nasl That's what I got when I ran into Firewall/1 "rule 0". I patched nessus-libraries/libnessus/network.c to open only one connection at a time and slow down SYN rate in a single script. This is far from perfect unfortunately. (to enable the ugly patch, define NESSUS_CNX_LOCK in network.c) Of course, a good network connection is necessary for a reliable audit. But when I go on a customer's site, I cannot rebuild their network :-\ Last time, the target machines were on a token ring network and we did not have a card for our laptop computer. So we plugged on the Ethernet network and the gateway was... a Firewall/1 with its nasty "implicit rules". Another time, we had to run on a WAN which was fast but unreliable. I suppose that there is no real solution. Increasing the timeout _might_ be a fix against network glitches. Another idea could be to ping the target before every plugin is run. In case of blacklist, the waiting time after each unsuccessful ping must be increased.
