Re: False positives scanning Red Hat servers running Apache

[Wyman Miles <wm63 () CORNELL EDU>]

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



- --On Monday, April 30, 2007 8:13 AM -0500 Chris Green <cmgreen () UAB EDU>
wrote:

> Wyman Miles wrote:
>
> > 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.
>
> While griping about Tenable, I seem to recall a day when they did write
> the scripts that did a lot more than version checking. They still seem
> now and then.   I spend a LOT more time filtering out the remote patch
> check scripts which just are not useful to me in the distributed
> organization.  Unfortunately, I don't think other vendors are much
> better in this regard.

It dawned on me this ought to be a presentation for the recent conference
in Denver, but only a week before the conference.  I was going to call it,
"Why your vulnerability scanner sucks"

I went through the plugins in my old 2.0 copy of Nessus and looked for
various NASL socket handling code, hex, that sort of thing, with an eye
toward sorting the plugins into exploit vs. version check.  Back then, the
balance was overwhelmingly in favor of exploit.

Compare that to our current production scanner (3.0.x), where the balance
is quite dramatically reversed.

In fact, some of the tests we once used on Resnet have since become
worthless -- an exploit has been replaced with a check of PE headers or a
reg key, which invariably is a no-go.

We don't bother filtering plugins.  We just throw the works at each host
and see what sticks.  Nessus is smart enough these days to skip anything
that depends on credentials.

What I think Tennable, ISS, and the rest are up against is the anti-virus
vendor phenomenon.  They're judged to some extent on the basis of speed.  A
vulnerability is discovered and vendors who are slow to provide tests
simply look bad.  Version checking is quick, almost boilerplate on most
platforms.  Developing an accurate test that minimizes risk while being
functional across a range of conditions is much slower.


Wy


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/AwUBRjYLl8RE6QfTb3V0EQL+HACaAtDza06z4nxDYdrLoer0RCtH/IoAoKfL
PG7KnYsRZiXzGHatCCdzr7mx
=VfuR
-----END PGP SIGNATURE-----