Re: False positives scanning Red Hat servers running Apache

[Wyman Miles <wm63 () CORNELL EDU>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nessus?

This has been my long-standing gripe about the direction Tennable is headed
with that product.  I suspect other vulnerability scanners are in the same
boat, but I'll just point at Nessus.

Once upon a time, Nessus was a door-kicking vulnerability scanner.
Provided you balanced the induced DoS risk with the need to find
vulnerabilities, it was accurate and powerful.

Now, it's mostly version checking.  Which, as you've noted, is inherently
unreliable.  In the linux world, in particular, you've got three
dimensions: distro, distro version, application version.  With Sun,
reported sendmail versions don't align with Sendmail's own distributions,
so we false positive there.

And admins who customarily suppress application version reporting make
matters worse -- no false positives, but an unknown number of false
negatives.

If you're willing to supply login credentials to your scanner, it'll
invariably be much more accurate.  But, now you've introduced a maintenance
issue and potentially a security risk.

I'd like to see a return to door-kicking vulnerability scanners.  It's not
significant change to most of the modular tests (Nessus/ISS/WebInspect for
example) to have a dangerous/benign logic fork.  Provided we understand and
properly handle the risks, a vulnerability scanner that does a little
prying, kicking, and banging is going to be much more accurate than one
that simply looks up version numbers.

Let's face it, the bad guys have no restraint about sending over an exploit
to see what sticks.

Wy

- --On Thursday, April 26, 2007 10:41 AM -0400 Clifford Collins
<Collinsc () FRANKLIN EDU> wrote:

> I've recently been scanning some servers on our campus that have returned
> known vulnerabilities for Apache. I forwarded the results to our Linux
> systems administrator. He investigated the claims and declared them as
> false positives. His explanation was that Red Hat "backports" patches to
> stable versions rather than deploying the newer version because newer
> versions can introduce new features or changes that render an existing
> server non-functional.  He was also critical of the scanner for failing
> to detect the patches and relying on the reported version number from a
> web query.
>
> Has anybody encountered this problem? Is there a solution or a product
> that can detect undeclared patches on a Red Hat server without actually
> doing a penetration test? Is there a query that will yield the patch
> level? Your suggestions and comments are welcome!
>
> Clifford A. Collins
> Network Security Administrator
> Franklin University
> 201 South Grant Avenue
> Columbus, Ohio 43215
> "Security is a process, not a product"



Wyman Miles
Senior Security Engineer
Cornell University, Ithaca, NY
(607) 255-8421
-----BEGIN PGP SIGNATURE-----
Version: Mulberry PGP Plugin v3.0
Comment: processed by Mulberry PGP Plugin

iQA/AwUBRjC/dcRE6QfTb3V0EQLhmwCdF1ZE6IPU1kZkpyZhqX9kYTFThJAAnR9/
f6f0On+XwQqCS3Zm4GD3ryTo
=tSKk
-----END PGP SIGNATURE-----