Will my secure site pass credit card PCI compliance scans?

This answer is customized for cohousing.org. (change domain name)

If you accept a large volume of credit cards, your site may be required to pass a PCI scan or a similar “security vulnerability” scan.

Our servers are configured to help you pass these scans. We have many customers who are regularly scanned without any problems, and our own www.tigertech.net Web site passes PCI scans from Trustwave.

However, you may need to ask us to make some minor changes to the way your site is set up before a scan.

On this page:

SSL certificate

First of all, you’ll need your own dedicated SSL certificate. The certificate includes a dedicated IP address.

Disabling telnet, NTP, FTP, SSH and remote MySQL connections

Most scanning companies require your site to reject telnet and NTP connections. To help you pass the test, we can disable access to telnet and NTP (ports 23 and 123) at the firewall level for your IP address if you contact us.

Some scanning companies also require that we reject FTP connections to www.cohousing.org. We can do that if you wish.

Finally, if you don’t use remote MySQL connections or SSH connections, we can also disable MySQL access (port 3306) and SSH access (port 22) from outside our network at the firewall level. We recommend doing this.

MySQL version numbers

If you do require remote MySQL connections, things are more complicated. You’ll have to convince your PCI scanning company that you don’t store credit card numbers in your database so it’s not a security risk.

They’ll either accept that, or claim that your site still fails the test because we use an “outdated version of MySQL”. This is not the case, though.

Like almost all hosting companies, we use a Linux distribution that includes “backports” of security patches, including MySQL. This means the Linux “distribution” (in our case Debian Linux) provides an initial stable version of MySQL (such as 5.1.49). When new versions of MySQL are released, the security fixes from those new versions are added to the MySQL packages (although the brand new features of the new versions aren’t).

This allows us to run a version of MySQL with a known set of features, while keeping it secure. Our customers wouldn’t like it if we were constantly upgrading to full new versions of MySQL, with all the bugs and changes that come from new software — stability is important.

So checking just the “5.1.49” version number of MySQL doesn’t tell the scanning company how secure the actual software is. You can tell them this:

“We’re using Debian Linux MySQL version 5.1.49-3, which has all security patches applied.”

Explaining this to the scanning company has allowed our customers to pass this part of the test, even though they continue to use MySQL remote connections.

SSH version numbers

Similarly, if you do require SSH connections, we’ve received reports that at least one scanning company claims our version of SSH (“5.5p1-6+squeeze1”) is vulnerable to security issues CVE-2008-5161 or CVE-2011-0539.

This is not the case, though. These vulnerabilities were fixed in the Debian Linux version of SSH that we use, which can be confirmed here:

You should be able to successfully “appeal” this to your scanning company based on that (just show them this Web page).