stanlemon

If you do any credit card processing on your website you have to deal with PCI Compliance. I equate the pain of this task to putting your hand into a meat grinder. Yeah, it just is that bad.

I'm a big fan of Braintree as a Credit Card processor for web apps, it's got a really rock solid implementation, the SDK's are done by Braintree for developers and it really reduces the stress of being PCI Compliant. That said... I hit a snag recently.

Braintree set me up with an account at Security Metrics for PCI Compliance scanning. The idea is that Security Metrics scans my server and evaluates our compliance based upon a variety of criteria. Most of those criteria are bunk, but this is what the industry does, so these are the rules we play by. One of the issues that I've run into over and over again is with Apache version numbers. Security Metrics does a HEAD request on port 80 and uses the Server Signature of Apache to peel out the version number and check it against known vulnerabilities. I happen to sport CentOS 5.7, which ships with the latest and greatest security fixes of Apache back ported to Apache 2.2.3. Back porting is common practice in the Linux world, it ensures that you have the most secure version of a piece of software without breaking compatibility via features. Here lies the problem.

When Security Metrics scanned my server they saw Apache 2.2.3, which does not have a security fix for 2.2.18 (in their opinion) and so the scan fails. This is flat out wrong. The truth is I have the fix, but the scanner just isn't intelligent enough to discern this. Some other products in the PCI Compliance world (ie. McAffee for example) provide ways to object to a test and prove that it's a false-positive. Security Metrics unfortunately does not provide an easy route for doing this.

So what's a guy to do? Do you have roll Apache in order to get the right version number? I don't recommend it, that just makes for a lot of work down the road. You can try e-mailing the Security Metrics folks, but I'll tell you that from experience this was mostly a frivolous task. When I e-mailed them I spent three days arguing about nmap's response for a scan of UDP port 1434. Ridiculous! So here's what I discovered last night... If Apache does not return a version number, Security Metrics passes your server on that test. I haven't decided if this is a good thing or not, but it definitely made life easier in a frustrating situation. If you're running into this issue I suggest setting "ServerSignature" to 'off' and setting "ServerTokens" to 'prod' in your httpd.conf. Restart Apache and re-run your test and you should be able to spare yourself the frustration of a wonky PCI scanning test.