PCI Compliance

Bluehost does not support PCI compliance on all accounts.  

• Shared Hosting accounts will not be PCI-compliant on their own.
• Shared Hosting customers can achieve PCI compliance with a full CDN solution (meaning DNS will only be fully pointed through the service), such as Cloudflare.

Customers on VPS and Dedicated servers will be able to achieve PCI compliance; however, this is ultimately up to you. If you are able to provide a valid PCI scan, we can help review and/or advise on the output for better understanding. 

When doing a PCI scan, occasionally, the scanning company finds problems with certain things. The purpose of this article is to resolve typical problems and offer account owners reassurance. 

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 run a rebuild on Apache, and it should add the cipher line to 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. However, 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 ensure the 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. 

Mod_frontpage

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, with Apache 2.x or 2.2.x compiled through EasyApache, fpexe is replaced by /scripts/fp-auth, which is never suited root and poses no security threat. 

Mailman

Sometimes, a PCI scan will yield something like the following:

Unencrypted Login Information Disclosure for the following link: http://example.com/mailman/admin/mailman

Regrettably, the Mailman alias is a global httpd.conf alias, making it impossible to disable it for individual users. Our use of suexec means that any process related to Mailman runs as a separate user on the server, similar to how it works with Anonymous FTP rather than a customer's scripts.

While we acknowledge that Mailman allows unprotected passwords, it's important to note that any security breach in the Mailman system will NOT compromise a customer's account. We are aware that some PCI scans are flagging this issue, and we are actively exploring potential solutions.

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 run by the nobody user (and thus can't run 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