Mailing List Archive: scan fails with no privileged ports

Hi guys,
I recently rewrote the firewalls for 5 of the servers at my company. 2 of those have world accessible services that run on privileged ports (smtp, http(s) to be specific). The other 3 have no services open to the world under 1023, although one of them does run an accessible flash communication server on port 1111 and 1935. The scans work great on the first two machines, taking the normal 15-20 minutes. The other 3, however, finish within 10 seconds and I cant even view the report.
As a test, I opened ssh access to anyone and retried the tests, and they work. My question: is this known/intended/approved behavior? If yes, why? Is this server or client related?

We are using Nessus 2.0.10 for Linux on a RedHat 7.3 system. The client is nessuswx-1.4.4 and the error when trying to view the report on a failed test is "this scan result file has no records and cannot be viewed".

thanks,
Jay

Jay Wineinger wrote:

> Hi guys,
> I recently rewrote the firewalls for 5 of the servers at my
> company. 2 of those have world accessible services that run on
> privileged ports (smtp, http(s) to be specific). The other 3 have no
> services open to the world under 1023, although one of them does run
> an accessible flash communication server on port 1111 and 1935. The
> scans work great on the first two machines, taking the normal 15-20
> minutes. The other 3, however, finish within 10 seconds and I cant
> even view the report.
> As a test, I opened ssh access to anyone and retried the tests,
> and they work. My question: is this known/intended/approved
> behavior? If yes, why? Is this server or client related?
>

A common cause for super-fast scans is that nessus does a ping, receives
no response and determines that the host is dead. You can spot evidence
of this in the nessus.messages log file, usually found in
/usr/local/var/nessus or thereabout.

It's easy to fix, find the Plugin config named "Ping the remote host"
and disable the tcp/icmp pings, provided that this is the reason the
scan fails...

--
Jan Fredrik Leversund <jfl@phalanx.no>
Phalanx Security Services <URL:http://www.phalanx.no/>