-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 One of my biggest complaints about nessus today is that it hangs. It often gets stuck nmap'ing a host and I have to kill the nmap process for nessus to continue. I'll take the next oportunity to capture some debug for this event.
Somewhat related, nessus refuses to respect my nmap output. It will continue to scan a host even after loading nmap's .nmap output from that host. If I disable the portscan plugins, nessus attacks every port on that host: <snip> begin(SCANNER_SET) 10180 = no 10277 = no 10278 = no 10331 = no 10335 = no 10841 = no 10336 = yes 10796 = no 11219 = no end(SCANNER_SET) begin(SERVER_PREFS) max_hosts = 1 max_checks = 5 log_whole_attack = yes report_killed_plugins = yes cgi_path = /cgi-bin:/scripts port_range = 1-65535 optimize_test = yes language = english per_user_base = /var/nessus/users checks_read_timeout = 15 delay_between_tests = 1 non_simult_ports = 139 plugins_timeout = 320 safe_checks = yes auto_enable_dependencies = no unscanned_closed = yes <snip> On Fri, Mar 21, 2003 at 11:17:08AM +0100, Renaud Deraison wrote: > Date: Fri, 21 Mar 2003 11:17:08 +0100 > From: Renaud Deraison <[EMAIL PROTECTED]> > To: "Nessus List (E-mail)" <[EMAIL PROTECTED]> > Subject: Re: New nmap v3.20! > X-Spam-Status: No, hits=-3.0 required=5.0 > tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, > USER_AGENT,USER_AGENT_MUTT > version=2.43 > > On Thu, Mar 20, 2003 at 06:58:18PM -0800, Fyodor wrote: > > > - g++ is not installed everywhere > > > > Hi Renaud. This concerned me as well, so I waited patiently for many > > years before switching to C++. Then during one release I accidentally > > pasted in some autoconf code which checked for g++ and bailed out if > > unavailable. There were many thousands of downloads of that Nmap > > release and the number of compilation problem reports due to no C++ > > compiler can be counted on one hand. The last 3-6 months of betas > > have required C++ as well, and I haven't had more than 2-3 reports. I > > expect that the Nessus userbase has much in common with Nmap users. > > Having the g++ compiler does not imply that it works. I don't know if > your autoconf test also checked that it could produce executables, but I > have various examples of cases where g++ is not installed or is > installed but can't link libraries (mostly when working with cross > compilers). > > > > - libpcap 0.7.1 : I did some testing of libpcap 0.6.x (the "post lbl > > > libpcap") on Linux, and when you have a great number of processes each > > > having a different filter on their own pcap filter, > > > > Well, you already know my opinion of running many Nmap instances in > > parallel. Nmap will scan faster if you run just one with many hosts > > on the command line. I recently (last couple weeks) put substantial > > effort into improving the SYN/connect() scan timing, especially > > against firewalled hosts. The -T4 (same as "-T aggressive") option > > also now offers improved performance. I gave a real-life example in > > my 3.15BETA3 announcement ( > > http://lists.insecure.org/lists/nmap-hackers/2003/Jan-Mar/0005.html ) > > -- A firewalled host which took 556 seconds to scan with older > > versions takes only 40 seconds with 3.15BETA3 and -T4. It would be > > even faster with -T5, and that would still be less aggressive than > > your dozens-of-nmap-instances-at-once approach. > > > This does not really fit well architecture-wise, for the following > reasons : > > (a) The Nessus engine is not really network-aware by itself, it's just a > small program which obtains a list of IP adresses by calling > hg_next_host() multiple times. ie: it never loads the whole list of IP > adresses in ram at the same time in memory and has no "global view" of > the targets. If I were to implement a way to call nmap with all the IP > adresses first, I would need to break this architecture to handle a > special case, something I'd rather avoid. There is also the problem of > passing the IP adresses to nmap (Nessus has a subtly different target > notation than nmap [ie: 10.163.156.1[www.nessus.org] for virtual hosts), > so I'd need to write a filter which would expand then factorize the IP > addresses. > > > (b) Nessus is written in such a way that there is no single point of > failure. It means that if one plugin crashes, it won't crash the whole > scan of the network. Ergo, if one port scanner crashes or hangs, it > won't prevent the completion of the whole scan. Having an external > process first scanning all the IPs scares me, because it's like putting > all my eggs in one basket - what if there is a bug in Nmap which "locks" > the scan ? Or if _one_ host on the list is down, preventing the whole > scan to start at all ? > (I don't doubt about your code, but I don't want to multiply possible > points of failure. There is one process manager in Nessus, and if ever a > problem is being reported I know where to look) > > > What scares me is really point (b) - having the whole scan being stuck > because of one host. For the record, there is a vulnerability scanner > out there which hangs (totally) if it scans a host whose open ports are > all redirected to the discard port. It does a blocking recv() with no > timeout, and this hangs the whole scan. In real life, it means that a > single user can hang the scan of the whole network (and drive the admin > nuts) with two lines in /etc/pf.conf. I'd hate to see that happen with > Nessus. > > > -- Renaud > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (SunOS) iD8DBQE+fPKyq4kCqmVQQvgRAkMuAJ4jZmY/KESzb3L8nFrbq32NAkFQiwCghN10 7BjzZeEo2FCnjGkS1/iArNQ= =HHPr -----END PGP SIGNATURE-----
