Bluehost Web Hosting Help

PCI Compliance

Summary

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 let the account owner feel more at ease.

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.

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, 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.

Mailman

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
Knowledgebase Article 160,154 views bookmark tags: compliance pci


Was this resource helpful?

Did this resolve your issue?


Please add any other comments or suggestions about this content:





Recommended Help Content

TLS 1.0 PCI Compliance

This article will discuss how you might be affected by the removal of TLS 1.0 in the updated PCI Compliance Standards.

HIPAA Disclaimer

HIPAA Disclaimer

Reputation Monitoring

This article will explain the benefits of SiteLock in regards to reputation monitoring.

Related Help Content

India Service Tax

India imposes a 18% Service Tax on electronically supplied services sold by foreign entities to customers located in India.

SiteLock Lite

An overview of SiteLock Lite

Domain Privacy for .us Domains

The WHOIS database shows my personal information for my .us domain names. How do I get privacy for the .us domain?

GDPR

GDPR stands for General Data Protection Regulation. This law was proposed by the European Union (EU), and will go into effect May 25, 2018. What is GDPR, and what do you need to know to prepare for it

Office 365: Multi-Factor Authentication

Office 365 requires admins users to set up multi-factor authentication before they can use the account. If customers do not set up their multi-factor authentication within 48 hours, they may be locked out.

Registration Data Access Protocol (RDAP)

Starting on August 26, 2019, the Registration Data Access Protocol (RDAP) will be a new protocol available that provides WHOIS details for generic top-level domains (gTLDs) (e.g., .com, .net).

MySQL Repair and Optimize Tables in phpMyAdmin

How to repair and optimize your database using phpMyAdmin:

California Consumer Privacy Act

The California Consumer Privacy Act is a law designed to enhance consumer privacy rights for California consumers and encourage transparency regarding how businesses collect and use personal information.