Re: False positives scanning Red Hat servers running Apache

[Bill Ogle <info () COMPLYGUARDNETWORKS COM>]

Your Linux admin is 100% correct regarding back porting as common practice.
It is done for more reasons than he indicates.
At the same time is he partially correct regarding the scanner and his
declaration of false positive.

Firstly, the scanner did accurately identify the environment. Further, it
recognized a version of Red Hat that is the correct information communicated
by the software. The scanners from most vendors  function the same in this
regard because they all draw on the common knowledge body like NIST, OVAL,
Mitre.org, CERT and others. Please note there is a lag time between when a
patch becomes public record and the knowledge bodies are updated.

Sometimes, depending on the quality of the scanner, further down in the
report will be a "low" or "info" discovery that may well articulate the
correct version of the software.

Certainly the scanner report indicated that that port or IP needed some
attention. It accomplished its task. If you are running a configurable
scanner, add a script to cover the discovery. If not, recognize this will
happen each time to scan.

One final suggestion: if you need a good commercial scanner that is approved
by the financial services industry, check our the scan vendors at
http://www.pcisecuritystandards.org. or do a Google for " PCI testing".


  -----Original Message-----
  From: Clifford Collins [mailto:Collinsc () FRANKLIN EDU]
  Sent: Thursday, April 26, 2007 10:41 AM
  To: SECURITY () LISTSERV EDUCAUSE EDU
  Subject: [SECURITY] False positives scanning Red Hat servers running
Apache


  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"