3

I have a VPS running Ubuntu 14.04.3. The latest Ubuntu-supported version of Apache for this release is Apache 2.4.7.

But the company for which I configured the server is seeking PCI compliance, and has been denied due to security vulnerabilities patched in Apache 2.4.14.

The latest stable release of Apache is currently 2.4.17.

Would it be advisable/viable for me to install Apache 2.4.17 on the server - could I do it by using apt-get with another package repository, or would I need to build from source?

HBruijn
  • 72,524
  • 21
  • 127
  • 192
user548958
  • 31
  • 3
  • 3
    Was this determined by a scan from an ASV? If so, look at the details in the report to see what the failure reason is and the remediation steps. Many times, configuration changes are required, not just a patch. Disabling TRACE/TRACK is very easy in the config, but gets overlooked and that will be a failing grade if not disabled. – Gmck Nov 20 '15 at 18:39
  • Thanks for this. I've already done some configuration changes (tightening up on supported TLS protocol versions for a couple of services, not just Apache). I'll look into TRACE/TRACK. – user548958 Nov 23 '15 at 09:53

2 Answers2

5

From a security perspective you don't want to be running Apache httpd 2.4.14 or even 2.4.17 at all, you just don't want to be vulnerable to any known Apache (or other) security vulnerabilities.

In general you already achieve that by regularly applying the security updates on your supported Ubuntu LTS release.

A security scan probably detected your Apache version string 2.4.7, did a quick lookup in a database with known vulnerabilities such as https://nvd.nist.gov/ and found a list similar to this one on cvedetails.com and found that CVE-2015-3185 is but the most recent vulnerability that applies to your Apache version.

Then comes the ignorant conclusion: to be "secure and compliant" one must follow that CVE blindly and you must upgrade to a release Apache httpd 2.4.14 or newer.

That does not take into account the common practice in the "Enterprise" Linux distributions to "backport" security updates. The reasons for backporting and the process is pretty well described on RedHat.com but is similar for Ubuntu. (Please read that whole article.) The short of it is that older version number does not equate to insecure at all.

CVE-2015-3185 has been acknowledged by Ubuntu as USN-2686-1 and has been addressed.

If you have not already, simply install the normal security updates and despite remaining on Apache version 2.4.7 you're not vulnerable to CVE-2015-3185 nor any of the previous CVE's.

I'm not intimately familiar with the PCI compliance certification process so how to translate the above to getting certified...

What might help is this answer (and even that whole Q&A is interesting despite being focused on RHEL): use the following Apache Directives and set ServerTokens to Prod and set the ServerSignature to Off in your httpd.conf.

Community
  • 1
HBruijn
  • 72,524
  • 21
  • 127
  • 192
  • 3
    The Ubuntu 14.04 Apache package history can be viewed here - https://launchpad.net/ubuntu/trusty/+source/apache2 and it includes links to the patches that have been applied. Having gone through PCI at 2 different companies in the UK, its about talking to your auditor show them the update what security vulnerability they cover and see if they will accept it. Some do some don't. – Sam Nov 20 '15 at 21:08
  • Great explanation of PCI compliance and backported security updates. I have had minor interaction with PCI compliance certification, but knowing this makes me feel far more at ease if I do need to deal with it again. – TheGrandPackard Nov 20 '15 at 21:38
  • Thanks so much for this, it's really interesting stuff. HBruijn, that was especially helpful as it unpacks the automated nature of the scan. I'm going to stop Apache advertising itself as a target, then re-run the scan... if it still complains about the same issues, I'll try to convince the auditors that Ubuntu's backports mitigate the problems and if they don't go for it... well, there's another server I can temporarily host the apps on while we reconfigure the failing VPS more deeply. – user548958 Nov 23 '15 at 09:57
1

May I suggest you hire a PCI experiences consultant. This is a really important and hard to get certification. To do that at one of my clients, we where speaking in term of many 100K$ for a mid size infrastructure. As well, you need to look at the great picture. If you Apache server need to be PCI compliant, so as your OS, you DATABASE, you network infrastructure(IPS/IDS), WAF, FireWall, etc...

I do not know what is your setup and you client setup. But this need some serious analysis... That much, that even some big companies let it go to outside services that are expert in providing such services.

As well, you would also want to get some serious insurances, if there is something wrong (if your a consultant) and it goes back to you... Be prepared for bug time (shit hit the fan)...

Just my 2 cents. I know this does not help you technically speaking, but I think this is a fair input to you as for you should put energy in that or not...

On that, good luck.

yield
  • 731
  • 1
  • 8
  • 24
  • Thanks - but the annoying thing about this issue for me is, the company's very small scale and doesn't hold credit card details in its own applications at all: payments are handled by a 3rd party payment gateway.So there's not the budget there for a full-scale response, and morally I don't actually think there's a need; it just feels like my client's fallen foul of an automated test process. – user548958 Nov 23 '15 at 10:00
  • 1
    Here's the thing with PCI, it does not matter how big or small the company is. If Payment card data traverses your client's networks at all, they fall under compliance. Even if you use a third party gateway, it has to be a hosted or tokenized solution so the data does not touch their systems - that means no logs, no database bin logs, no payment card data anywhere in their systems. – Gmck Nov 23 '15 at 19:37