4

I have a fully patched CentOS 5.5 server that is failing the Trustwave PCI compliance scan. The items it is complaining about is openssl < 0.9.8.o.
rpm -q openssl shows: openssl-0.9.8e-12.el5_5.7

The apache header banner shows: Server: Apache/1.3.41 (Unix) PHP/5.2.14 mod_psoft_traffic/0.2 mod_ssl/2.8.31 OpenSSL/0.9.8b mod_macro/1.1.2

(note: that apache banner is not even showing the the installed version)

openssh and php have a similar situation (reported version is less than the minimum for PCI compliance).

Do I need to build all these libraries from source to get them on the latest version? Or is there a way to tell CentOS yum to install the new version instead of their back-ported patched version? I'd rather not go outside yum if possible so future maintenance will be simplified

John P
  • 1,679
  • 6
  • 38
  • 59

3 Answers3

9

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 <jorton@redhat.com> - 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.

kashani
  • 3,922
  • 19
  • 18
1

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.

mahnsc
  • 1,796
  • 13
  • 11
0

This isn't an answer to your question but I suspect apache is reporting the version of openssl it was compiled against, not the version it actually uses. On Fedora it is clearer:

[Fri May 13 03:45:05 2011] [info] mod_ssl/2.2.17 compiled against Server: Apache/2.2.17, Library: OpenSSL/1.0.0a-fips
[Fri May 13 03:45:05 2011] [notice] Apache/2.2.17 (Unix) DAV/2 PHP/5.3.6 mod_ssl/2.2.17 OpenSSL/1.0.0d-fips configured -- resuming normal operations

$ rpm -q openssl.x86_64
openssl-1.0.0d-1.fc14.x86_64
Mark Wagner
  • 18,019
  • 2
  • 32
  • 47