Just Host Web Hosting Help
PCI Compliance
Summary
Just Host 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 Just Host 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.
Just Host 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:
- http://www.cpanel.net/support/docs/notes/pci-falsepositives.htm
- http://twiki.cpanel.net/twiki/bin/view/AllDocumentation/PCIComplianceInfo/ScanningSoftware#mod_frontpage
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
161,029 views
bookmark
share
E-mail
Twitter
Google Bookmarks
Facebook
MySpace
Digg
Reddit
Delicious
LinkedIn
StumbleUpon
tags: