5

We just ran an external security scan from 403Labs against one of our servers (RHEL 6.3 x86_64) for PCI compliance and the results appeared to mainly dictate that we had a hand full of applications that needed to be upgraded to pass the scan.

That having been said, the problem I am encountering is that the package manager (yum) and the use of the remi repo do not have the versions I need for Apache and OpenSSH. I have already performed the following:

yum update
yum --enablerepo=remi,remi-test install httpd mysql mysql-server php php-common

This resolved our critical and high risk results, but the medium level results are still stating that we need to further upgrade the following packages.

The upgrades we need are:

   Current            Required
Apache 2.2.15 to >= Apache 2.2.23
OpenSSH 5.3   to >= 5.7

So, since the package manager is not capable of letting me upgrade to those versions, how must I go about doing this? I'm currently under the premise that I will need to install from source. If there's a better alternative, please indicate that.

Also, if I have no choice but to install from source, can someone please help me identify what the proper source packages would be so that I know I am installing the correct versions for my OS?

Thank you very much for any help.

Improve this question

3 Answers 3

Reset to default
8

Don't do that !

Before you step outside the OS vendor's support structure you should verify that this is the right thing to do.

Some PCI compliance tests will report that an application has vulnerabilities because it's reported version number is too low. This does not take into account backporting of security and bug fixes that many vendors employ.

For example (from an old Nessus scan) it declares that Apache supplied by CentOS is vulnerable if the version is <2.2.14. If you dig into the detail about what the vulnerabilities are then you discover CVE-2009-3095, CVE-2009-3094 etc.

Looking them up you discover that they have been fixed in current versions of of Apache supplies buy RH and thus CentOS.

Improve this answer
9
  • Thank you, lain. So, if 403Labs is telling us that our site is not PCI compliant based on that exact scenario and I have applied all updates via yum update, then what coarse of action should I take to let my management know that we actually are fine? I'm not very versed in this sort of thing, so I want to make sure that his concerns have been addressed accordingly?
    – Skittles
    Jan 30, 2013 at 17:51
  • Tell them to cross-reference the exploit/bug against the vulnerability database to see if RHEL backported the changes.
    – ewwhite
    Jan 30, 2013 at 18:05
  • 1
    @Skittles: Yuu need a detailed list of the vulnerabilities which you can then cross reference against the fixes.
    – user9517
    Jan 30, 2013 at 18:10
  • @lain - I do have a detailed list as a scan report from 403Labs.
    – Skittles
    Jan 30, 2013 at 20:05
  • @ewwhite - I will try to see if we can do that. Thank you.
    – Skittles
    Jan 30, 2013 at 20:06
12

Push back...

Red Hat Enterprise Linux doesn't work that way. Installing from source to meet audit requirements opens you to additional security issues and more management overhead.

The approach Red Hat takes for its enterprise operating systems is to create a consistent target throughout the support lifecycle of the OS. Larger corporations and enterprise applications need to guarantee binary compatibility throughout the 7+ years that these operating systems are supported for. Red Hat will not change minor version numbers of a package, but will instead backport changes and security patches from newer versions into the older package.

E.g., you'll never see Apache 2.2.23 in RHEL 5, but you'll see the relevant security patches (and some functionality) ported from newer versions of Apache into the 2.2.3.

When I deal with auditors or security-focused people, I insist that they read through the package changelog to see if their specific concern is covered by existing security fixes or bugfixes...

Here's the EL Apache changelog.

Cross-reference the CVE-* numbers against the CERT/National Vulnerability Database. For instance, CVE-2011-3368 lists a vulnerability that affects Apache versions prior to 2.2.21. Obviously, RHEL only has 2.2.3 as a major version, so the security fix was developed, tested and ported to the old version.

Improve this answer
6

I ran into this with my PCI compliance implementation as well, though I knew about the back-porting of patches mentioned above. Our solution with apache was to set ServerTokens to 'Prod' and ServerSignature to 'Off' in /etc/httpd/conf/httpd.conf. This wise setting tells apache not to report its version numbers and spit out all the modules it is using. We then passed the scan.

As for SSH, the ideal setup is to firewall off access so that only your office can connect to the port. This way the scan won't pick it up.

If that's not possible, PCI auditors can be convinced you are secure if you prove you're patched up (usually via some screen sharing utility you show that a 'yum update' shows no updates available) and have a procedure in place for regular tests. I just showed that I was subscribed to RedHat's security mailing list and that we immediately schedule an update if a component we're using is vulnerable.

Barring all that, you should be able to appeal and get a proper penetration test.

Improve this answer
2
  • This is an extremely good answer and I have just implemented the changes that you noted and will fire off another scan to see if this takes care of the remain medium level risks that we had. 15 in all and I am in the process of requesting exemptions for many of them.
    – Skittles
    Jan 30, 2013 at 22:52
  • Awesome. Let me know how it goes.
    – chylarides
    Jan 31, 2013 at 19:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .