RHEL 6.3 Upgrading OpenSSH & Apache

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.

Solution 1:

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.

Solution 2:

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.