I am trying to use Nessus 1.2.2 to vet a proposed hardened configuration of IIS running on W2K Professional Server.
The network consists of the Nessus box and the target, connected to a hub, and isolated from all other networks. The Nessus box is a fresh install of RH Linux 7.1, with nmap2.54BETA36 installed from a rebuilt source rpm. "Rebuilt" as in "rpm --rebuild <source rpm>", wait for the binary rpm to finish building, then install from that. The target box is a W2K Pro. Server, with a basic install of IIS, running Compaq Insight Manager (on port 2301 of course). I have been through two installs now. Install 1 built and installed the files nessus-libraries-1.2.2.tar.gz libnasl-1.2.2.tar.gz nessus-core.1.2.2.tar.gz nessus-plugins.1.2.2.tar.gz in that order, exactly in the order specified in the documentation section at www.nessus.org. Between installs, Install 1 was totally ripped out. Fire and the sword. This was trivially easy, since there wasn't _anything_ else in /usr/local/. But I used the uninstaller anyway, then deleted the four files that survived the resulting expungement. Install 2 used nessus-installer.sh. After its download, the MD5 checksum was calculated and was found to match that given on the server. It was also checked, again, once the wrapper-and-archive were on the Nessus box. In both cases, the raw install was followed by creation of a certificate, addition of a user, and running of "nessusd -D" by root. In both cases, scans against the target produced completely unacceptable levels of false positives. The obvious ones, and their diagnoses, are summarized below. I used Nessus in a previous assignment, two years ago, and was extremely impressed. It performed much better than I expected a remote vulnerability scanner to do. Hence, my mind is running in the direction of some really stupid configuration or installation error. But I can't figure out what; use of the "install-nessus.sh" wrapper-and-archive to installNessus is so easy that plankton could manage it. The most recent failure, during which the "cgi abuses" tests as well as the brute force login tests, were _specifically_ disabled, included the following: "The Cart32 e-commerce shopping cart is installed." This vulnerability was listed against port 2301, BTW, not port 80. But a search of the entirety of both system drives on the target failed to locate cart.cgi. "The file /ncl_items.html exists on the remote system." Port 2301. Again, the entire box was searched, and the file was absent. "Possible Backdoors: FireDaemon.exe" Port 2301. The entire box was searched, and the file was absent. "The CGI /_vti_bin/_vti_aut/fp30reg.dll is installed." Port 2301. The entire box was searched, and the file was absent. "The IIS server appears to have the .SHTML ISAPI filter mapped." Port 2301. We checked. It wasn't. "There may be buffer overflow in the remote cgi win-c-sample.exe." Port 2301. The entire box was searched, and the file was absent. Can some kind soul tell me what the blazes is going wrong? Thanks in advance, crypto_checksum __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
