Trustwave PCI Complaince scan fails for fully patched CentOS 5.5

All PCI scans do a version check based on headers and then they complain about the thirty or so problems you've got. What they don't take into account is that security fixes are backported to RHEL packages. As long as you're running the latests packages you should be fine. What you have to do after a failed scan is open a ticket to contest the results. Then you have to show what version is really installed

rpm -q httpd

Then you have to dig through the rpm changlog to find each CVE instance they mentioned.

rpm -q --changelog httpd

Where you're find things like this:

 * Thu Dec 03 2009 Joe Orton <[email protected]> - 2.2.14-1
 - add partial security fix for CVE-2009-3555 (#533125)

Finally you should link to the relevant link on Redhat's site to show it's been addressed since no one on the PCI scan side is actually going to look at an RPM.

https://www.redhat.com/security/data/cve/CVE-2009-3555.html

You'll probably go back and forth a few times and then finally you'll get a clean bill of health if you are actually updated. Once you've finished make sure to put all the support docs on your wiki since the PCI scan will reset every quarter or so and remove any mention of the information you provided and you'll need to do this again.

Back-porting fixes seems to be the preferred route for a lot of distributions. It's not a solution but you should suppress server identity by setting "ServerTokens Prod" and "ServerSignature Off" in your httpd.conf.

It may be controversial for me to say this but I don't think scraping the banner counts for a vulnerability scan as it often results in a lot of false positives. I think the scanner should actually be trying to see whether the known vulnerabilities for a particular version of a library actually exists and not making simple assumptions. In some cases, they actually do make some effort to see whether a vulnerability exists. An example would be the ssl cipher and protocol portions of the scans.

Of course, the problem one runs into when suppressing server identity is that many vulnerabilities previously reported are no longer reported and the administrator runs the risk of becoming lax in patching duties. It is a bit of a paradox however because other types of vulnerability scans complain about the Information Disclosure issues when not setting ServerTokens to Prod.

You should compile everything from source, essentially creating your own custom apache distribution but with the frequency of updates, you'll be compiling new builds frequently and not everyone has the time to do this.