Moving Towards PCI Compliance with cPanel

See also:

Those of you who are server admins or use certain merchant services know what I’m taking about — it’s that dreaded security scan that picks apart your server to tell you everything that it thinks is wrong, assuming you have the knowledge or access to fix it: yes, the PCI scan. PCI compliancy is a somewhat new procedure used by security companies and financial institutions to measure the security of a webserver that collects and stores sensitive information. The reasons for getting a scan vary, but are most commonly for legal reasons or just the assurance that your server is subject to certain vulnerabilities.

After dealing with 2-3 PCI scans a week for the last year, I’ve put together a common procedure for how to make your server compliant to current PCI standards. Note that each scan company is different and may report other issues, and if you’re using ControlScan then, well, I feel sorry for you. I’m also assuming that you are on a Linux server running cPanel and LAMP.

Step 1: Make sure you have a firewall

PCI scans are nazis about unjustified open ports, so only open the ones that you need in order for services to run effectively. Manually configuring iptables is a pain in the ass, so I recommend using APF or CSF (if you have cPanel) and then configuring the allow rules to only allow ports for active services.

Note that both indicate the opening of cPanel ports 2082, 2095, and 2086, but some scans will complain about these being nonsecure. If that is the case you can configure within WHM to only use the secure ports, then remove the nonsecure ones from the firewall so they can’t be accessed. You should also close MySQL port 3306 for external hosts and allow them on a per-IP basis to anyone other than localhost has to be allowed.

Step 2: Update your system

This is an obvious one, but you’d be surprised how many people still have old packages installed on the server. With cPanel, running /scripts/upcp will usually update the vital system software as long as you have your update configuration in WHM set to allow it, but otherwise I would recommend doing a yum update, up2date, or whatever else you use to manage packages to make sure everything is up to date.

Nowadays old versions of MySQL, PHP, and Apache are no longer squeezing through either, so you need to upgrade to at least MySQL 4.1.22, PHP 5.2.5, and Apache 1.3.39 (some scans will want Apache 2.0.x).

Step 3: FIx OpenSSL

If you did a package update this was probably already taken care of, but if you installed via source you need to make sure you’re using at least 0.9.7j, which is the oldest version that most PCI scans allow. You can get your sources from here, and it may require a recompile of Apache and other services that use it. To check your OpenSSL version, type ‘openssl‘ from your SSH prompt and then type ‘version‘.

Note to Redhat/Fedora/CentOS users: If you’re running a somewhat recent version of your OS your openSSL version probably is something like 0.9.7a, but due to Redhat backporting this may be a false-positive. If you’re on any Redhat-based distribution, just tell your scan company and they’ll bypass OpenSSL checks.

Step 4: Check your SSL certificates

In order to pass a PCI scan your server must have at least one SSL certificate signed by a recognized certificate authority, and any services using SSL need to be using a certificate as well. Go cough up $30-$100 and buy a decent 264-bit SSL certificate and install it not just for Apache, but also for all of your active services. WebHost Manager has a section for installing service SSL certificates to make this process easier.

Step 5: Disable SSLv2 and other weak encryption methods

This one always gets me, because there is no way to disable SSLv2 for everything at once, at least not one that I know of. What makes this part the worse is that not all services support the choosing of SSL protocols and ciphers, but luckily unless you are using ControlScan the ones that don’t are probably not going to show up. Here’s how you do it for common services that are reported:


Add these lines to your httpd.conf (you may to add them to each secure vhost as well):

SSLProtocol -ALL +SSLv3 +TLSv1

POP3 and IMAP:

Edit the following files:


Comment out the existing TLS_CIPHER_LIST line and replace it with the following and restart courier-imap:



Add the following to exim.conf:

tls_require_ciphers = ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM:!SSLv2

For other services that might be on your system, take a look at this guide.

Step 6: Disable mod_userdir (or whatever cPanel is calling it nowadays)

If you are able to go to http://yourserverip/~yourusername, then you have mod_userdir enabled and the scan will probably complain. You can disable this in WHM under Security Center > Apache mod_userdir Tweak, or in httpd.conf add “userdir disabled user1 user2 user3 …etc”

Step 7: Put Apache in incognito mode and disable the bad stuff

If you try to get an Apache error (like a 404 error), the footer of that page probably contains more information that you may want to share about your Apache setup. You can disable this in your httpd.conf by adding these lines:

ServerSignature Off
ServerTokens Prod
FileETag None

You can read more about these here.

Another thing that some scans report is the use of 413 errors. You should add this line to httpd.conf as a workaround:

ErrorDocument 413 /index.php (or any other file)

Just about all scans will complain if the ‘trace’ and ‘track’ apache methods are enabled on your server. You can fix this by adding these lines to your Virtualhost entries or .htaccess files:

RewriteRule ^.*$ - [F]

You should also disable directory indexes, which can be done most easily in your cPanel’s index manager. Directory indexes allow the listing of files inside folders that do not have an index page. You can also disable these in your .htaccess files:

Options All -Indexes

Ending notes

Really, it doesn’t matter how secure your server is if your web application scan is poorly programmed, so your server should not be the ending point in security. Some PCI scan companies are able to detect common vulnerabilities in web applications, but you should take the extra steps to stay ahead of the game and update your site software on a regular basis.

Be Sociable, Share!

14 thoughts on “Moving Towards PCI Compliance with cPanel

  1. This is like, a godsend. I got PCI scanned a few weeks ago, and they were like, “Well?” and the first thing I found when intending to update OpenSSH was that failing it will SCREW THINGS UP.

    No pressure of course 8)

    Great post, I’ll be using this for my cpan installs 8)

  2. Hi,

    When making the Weak cypher changes for apache SSL, consider making the similar updates to:


    for future sites on your cpanel server. Otherwise they will get the same weak cypher directive in the virtual host section.

    Thanks for the PCI compliance post.


  3. Hi,

    Sorry, These files should be updated too:

    /var/cpanel/templates/apache2/ssl_vhost.default /var/cpanel/templates/apache2/ssl_vhost.local


    SSLProtocol -ALL +SSLv3 +TLSv1

  4. Did anybody try to include

    ServerSignature Off
    ServerTokens Prod
    FileETag None

    via the Include Editor in WHM > Apache Setup? There are tree possible places to include it Pre Main Include, Pre VirtualHost Include and Post VirtualHost Include.Is it ‘Pre VirtualHost’?

  5. How do you keep secure cpanel ports from using weak ciphers? Here is a sample of tls1 supporting weak cipher:

    New, TLSv1/SSLv3, Cipher is EXP-RC2-CBC-MD5
    Server public key is 1024 bit
    Protocol : TLSv1
    Cipher : EXP-RC2-CBC-MD5

  6. Actually, having cpanel set to running native ssl is still a problem. The weak ciphers and sslv2 are enabled on the cpanel ssl ports, and the hackeralert scans flag this. I am looking for a way to disable this without having to run stunnel. I cant seem to find any solution other than to install and run stunnel. There must be some way to fix this.

  7. Actually, I heard from a post in the cPanel forums from one of the developers that cPanel 11.24 will include the disabling of weak ciphers for all services.

  8. I have a system that keeps getting flagged by McAfee Secure’s PCI scan and failing as a result of weak SSL ciphers for cPanel/WHM.

    Have you done an upgrade to cPanel/WHM 11.24, and if so, did it resolve the weak SSL cipher issue?

  9. I have returned to this website again and again. I cannot thank you enough! Steve’s post, from 11/3/08, asks if the most recent version of cpanel, using native SSL resolves the issue. Well, I’m using cPanel 11.24.4-R34548 – WHM 11.24.2 – X 3.9 and McAfee is unhappy.

    I’m working with the most excellent folks at, who continually tolerate my noobness, and I’ll post back if we find out anything.

    Again, thank you, thank you, thank you!

Leave a Reply

Your email address will not be published. Required fields are marked *