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
