The other day I had an old client forward me an email from their credit card processing company, saying that the server upon which their website was hosted failed their PCI Compliance security check. I had never heard of this and was wary that it might be a service they were being tricked into adding on, but upon further investigation, I learned that many credit card processing companies are now instituting this new security policy, which is designed to tighten up security on web servers in order to decrease the chances of credit card theft.
This sounded all well and good, and I figured that with my background in securing servers to meet Department of Defense standards it ought to be a breeze. Little did I know that the server in question would put up quite a battle for the lone reason that it was running Plesk, the web host management tool. I had written off Plesk long ago, having ditched the server I had it running on after many issues with it, and I thought I would never have to work with it again, but alas…
I started Googling, of course, and found some great resources out there which cover the tightening up of Plesk in order to meet PCI compliance.
One of the best articles I found was at linux-advocay.org, which explains how to fix issues with Courier, Qmail, Apache, SSL, and iptables in case you don’t have Plesk’s Firewall add-on.
Also, a fellow by the name of DrJermy writes of his solutions about dealing with Plesk and PCI Compliance.
For some general information about what PCI compliance is all about, check out pcicomplianceguide.org.
My Take
As I worked through the PCI issues with the client who contacted me, I started realizing that the standards by which the server was being scanned were presumptuous in that they didn’t take into account back porting, as implemented by RedHat, and that they were making me fix issues which seemed rather trivial in regards to credit card processing security.
If they really wanted to do something that mattered, they should have a look at the NSA’s hardening guides.