Educause Security Discussion mailing list archives
Re: False positives scanning Red Hat servers running Apache
From: Wyman Miles <wm63 () CORNELL EDU>
Date: Mon, 30 Apr 2007 11:30:31 -0400
-----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-----
Current thread:
- Re: False positives scanning Red Hat servers running Apache, (continued)
- Re: False positives scanning Red Hat servers running Apache Wyman Miles (Apr 26)
- Re: False positives scanning Red Hat servers running Apache Aaron Lafferty (Apr 26)
- Re: False positives scanning Red Hat servers running Apache Allison Henry (Apr 26)
- Re: False positives scanning Red Hat servers running Apache Wyman Miles (Apr 26)
- Re: False positives scanning Red Hat servers running Apache Steve Brukbacher (Apr 26)
- Re: False positives scanning Red Hat servers running Apache Russell Fulton (Apr 26)
- Re: False positives scanning Red Hat servers running Apache Clifford Collins (Apr 26)
- Re: False positives scanning Red Hat servers running Apache Bill Ogle (Apr 26)
- Re: False positives scanning Red Hat servers running Apache Mark Rogowski (Apr 26)
- Re: False positives scanning Red Hat servers running Apache Chris Green (Apr 30)
- Re: False positives scanning Red Hat servers running Apache Wyman Miles (Apr 30)