I just finished moving over an e-commerce website from a shared host to its own virtual private server and ran into a ton of PCI compliance issues. For those of you with experience dealing with PCI compliance scans, you know the headache dealing with your cases. If you’ve gotten a ton of flags for httpd (apache), openssl, or any other services running on CentOS, Red Hat, or other Linux variations, chances are they’re false positives.
Red Hat/REHL/CentOS Backporting
The most important thing to realize is that just because the version of the service you installed isn’t the most current, doesn’t mean it is vulnerable! Red Hat has the practice of fixing vulnerabilities and backporting them to the current version of the service. This means, if your PCI scan tells you that you need to update your version of httpd to a version not available, for example, you most likely don’t need to. The latest version available via yum will most likely have the fix in it, even if the version number seems old!
I suggest reading more about Red Hat’s policy for backporting, but I’ll give you an example I experienced.
As of this post, the current version of httpd (Apache) on CentOS7 is 2.4.6. After my PCI scan, I was told I have vulnerabilities and needed to upgrade to 2.4.16 or higher. The problem is, there is no version 2.4.16 of httpd available for CentOS7! So I did a little test to see if the vulnerability was already backported.
How Vulnerabilities are Tracked
Vulnerabilities are tracked via a CVE reference number. You can use these unique identifiers to search for a vulnerability online. It’s also easy to check your server to see if it has been patched for your specific service. So let’s run through an example with this CVE: CVE-2014-0231.
Finding a CVE reference online
A quick google search lead me to the following Red Hat page which goes into detail about the vulnerability: https://access.redhat.com/security/cve/cve-2014-0231
You can basically just plug in any CVE number at the end of that URL for a quick way to see if it’s addressed in Red Hat variations of Linux (CentOS, Fedora, etc).
The page made clear that this was addressed already in Red Hat Enterprise Linux 7 (REHL), so I was pretty confident that this was not a real issue for my server. There’s a little Bugzilla link (1120596: CVE-2014-0231 httpd: mod_cgid denial of service) on that page too which also gave me more information about the vulnerability.
Checking your server for a CVE patch
I needed to supply proof that the vulnerability was a false positive and so sshing into my web server was necessary. Once I was in there, it was fairly easy to find out if a CVE was applied to a specific service. Let’s go with CVE-2014-0231 again. I know this was related to httpd (Apache), so that’s all the info I needed to run the following command:
rpm -q --changelog httpd | grep CVE-2014-0231
And Bingo! I saw the following information come back to me:
- mod_cgid: add security fix for CVE-2014-0231 (#1120608)
So I knew that this security vulnerability was backported, even though from httpd’s (apache) perspective I would have needed a later version. Red Hat applied this patch to their version, so that’s why I didn’t need to upgrade.
Search for other CVE cases
You can easily find all the backported patches for httpd doing the following:
rpm -q --changelog httpd | grep CVE
Likewise, it works with any service you’re running, such as OpenSSL (which you’ll see flagged a lot during PCI Compliance scans):
rpm -q --changelog openssl | grep CVE
Resolving your PCI Compliance issues
Now that you have the proof, you can open a case to mark your compliance issue as a false positive. If you keep your services updated then most likely the majority of the vulnerabilities are already addressed, even if the version number of the service is lower than what the compliance scan recommends.
I hope this helps you next time you get freaked out over a PCI compliance scan. Don’t worry about version numbers, instead make sure to focus on the vulnerability itself and the backporting logs.
Keeping Your Services Up to Date
One last thing, make sure you’re using yum to keep everything up to date. Run this simple command:
sudo yum check-update
It’s worth reading through the list and applying all the updates on a staging environment to make sure your site works properly. Once you’ve confirmed, apply the same updates on your production environment. If you only have one environment, then… most likely you’ll still be ok 🙂
Best of luck getting compliant! Comment if you need help or have more recommendations.