1. bluehost knowledge base

PCI Compliance


Bluehost supports PCI compliance on all accounts for A and B compliance.

When doing a PCI scan, occasionally the scanning company finds problems with certain things. The purpose of this article is to address some of these things to inform that company and to provide account owners with peace of mind.

Weak Ciphers

First, here is an example of what a problem report might read like:

  Protocol: TCP 
  Port: 443 
  Program:  https
  Synopsis: The remote service supports the use of weak SSL  ciphers. 
  Description: The remote host supports the use of SSL ciphers that offer either weak encryption or no encryption at all. 
      See also http://www.openssl.org/docs/apps/ciphers.html
  Solution:  Reconfigure the affected application if possible to avoid use of weak ciphers. 
In this case, this is NOT cPanel related, but a problem with the Apache .conf file. We can identify this by the port number that was reported. If the port had been 2095, 2082... etc, then it is cPanel and a Bluehost administrator will need to fix the ciphers. But if the port is 443, it means the cipher line in the apache .conf file is missing for that domain.

Bluehost technical support can simply run a rebuild on Apache and it should add the cipher line into the Apache .conf file.

UserDir options for a domain

Again, here is an example:

  Protocol: TCP
  Port: 443/80 
  Program: https/http 
Some distributions of Apache, especially in Red Hat 7.0, allow an attacker to probe a system for user names via requests for user home pages (e.g., http://host/~username).

Disabling the UserDir directive in the Apache configuration file (httpd.conf) will prevent this, although it will also prevent users from providing their own web pages. Alternately, specify ErrorDocuments for both 403 (Forbidden) and 404 (Page Not Found) Responses. We can disable UserDir on an account.Contact Technical Support to have this changed.

Currently, when disabling it, it will update /var/cpanel/userdata/username/somedomain.com however it will not update /var/cpanel/userdata/username/somedomain.com_SSL. Technical support may need to be reminded to check both locations and be sure userdirprotect is changed from -1 to 1.
We intend to fix this so both locations are updated automatically in the future when requests like this are made.


Most people know this is just a false positive on the PCI scan, however the Patch information we have on Mod_frontpage that makes it secure will be provided for comfort's sake.

The version that is running is frontpage-2002-SR1.2 and poses no security threat. Also, reference this article for more info:

Also, with Apache 2.x or 2.2.x compiled through EasyApache, fpexe is replaced by /scripts/fp-auth which is never setuid root and therefore poses no security threat.



Sometimes a PCI scan will yield something like:

  Unencrypted Login Information Disclosure for the following link: http://example.com/mailman/admin/mailman
Unfortunately, the mailman alias is a global httpd.conf alias, so there is no way to turn if off on a per user basis. We use suexec and that anything with mailman is run as a different user on the server, as like with Anonymous FTP, than a customer's scripts.

We are aware that mailman does allow unprotected passwords, but any compromise to that system will NOT compromise a customer's account. We are aware some of the PCI scans are flagging this and are looking into a possible fix.

Vulnerability in /scgi-bin

This will come up as a false positive. /scgi-bin/ is aliased to the scgiwrap binary which is a common patch for cPanel and Suexec. This script can only be ran by the nobody user (and thus can't be ran from an http request) as demonstrated below:

$ curl boundlessether.com/scgi-bin/namazu.cgi

scgiwrap: Caller must be the nobody user

$ curl boundlessether.com/scgi-bin/non_existant_script.cgi
scgiwrap: Caller must be the nobody user