Plesk PCI Compliance

PCI Compliance Scans are becoming more and more common as more credit card processors require them. Most of the scans use a tool like Nessus and the scan results often contain many false positives. For example, the scans do not take into account practices such as back porting security fixes. Distributions such as Red Hat Enterprise Linux have very clear policies regarding backports.

The open source nature of Linux makes it relatively easy to maintain PCI compliance. When commercial control panel software such as Plesk is installed on a server, maintaining compliance can be more challenging. Plesk takes control of the e-mail and web services. Changes can be introduced to the configuration to make a Plesk server compliant as long as they are done the "Plesk way." If they are not introduced with a Plesk-compatible format, the next time a domain is added or modified through the control panel the changes may be lost.

Disclaimer

This document should not serve as a comprehensive source for PCI compliance advice.  The reader is expected to have some basic systems administration experience.  Do not copy and paste examples directly from this document without first understanding their implications.

All examples provided within apply to Redhat Enterprise, CentOS, and Fedora Linux.

This guide applies to Plesk versions up to and including version 9.5.2.  Parallels has published their own guides for Plesk 9.x and 10.x:

Plesk 9 (Opens in a new window)

Plesk 10 (Opens in a new window)

The above documents are the recommended sources for Plesk PCI compliance information.  The author of this article no longer works with Plesk on a daily basis; however, this document will remain online for legacy use.

Courier

Weak SSL Ciphers and SSLv2

The most common flaw uncovered by a PCI compliance scan is a service allowing SSL connections using weak SSL ciphers. Disable SSLv2 in Courier by adding the following to both /etc/courier-imap/imapd-ssl and /etc/courier-imap/pop3d-ssl:

TLS_CIPHER_LIST="HIGH:MEDIUM:!SSLv2:!LOW:!EXP:!aNULL"

After restarting Courier, test with openssl to confirm SSLv2 has been disabled properly:

openssl s_client -connect localhost:995 -ssl2

Test that weak ciphers have been disabled with the following:

openssl s_client -connect localhost:995 -cipher EXP:LOW

Plain Text Authentication

Some PCI scans will also raise a red flag if plain text authentication is enabled on non-encrypted connections. This should not be an issue on Plesk versions later than 8.3.0. Look for the following line in /etc/courier-imap/imapd:

IMAP_CAPABILITY="IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA AUTH=CRAM-MD5 AUTH=CRAM-SHA1 AUTH=PLAIN IDLE"

And in /etc/courier-imap/pop3d look for this line:

POP3AUTH="LOGIN CRAM-MD5 CRAM-SHA1"

Remove AUTH=PLAIN from /etc/courier-imap/imapd and LOGIN from /etc/courier-imap/pop3d to disable these authentication methods. Restart courier to apply the changes.  Please note that disabling plain text authentication may prevent some e-mail clients from authenticating.

qmail

Weak SSL ciphers can be disabled in qmail by adding the following to /var/qmail/control/tlsserverciphers and /var/qmail/control/tlsclientciphers:

HIGH:MEDIUM:!SSLv2:!LOW:!EXP:!aNULL

Testing with openssl is highly recommended:

openssl s_client -connect localhost:25 -starttls smtp

SSL Certificate Signed using a Weak Hashing Algorithm

Tenable has a description posted on the Nessus website.  Please reference CVE-2004-2761 for specific vendor responses.  This vulnerability is not a configuration error on the server and only affects older versions of Plesk.

There are two paths to resolution:

1. Create a new self-signed certificate for use with qmail

2. Use an existing SSL certificate that has been signed with a more secure algorithm.

A certificate can be tested for compliance as follows:

openssl s_client -in certificate.pem -text -noout

A certificate signed with a weak algorithm will have a string similar to the following:

Signature Algorithm: md5WithRSAEncryption

If the certificate has been signed with a secure algorithm the signature will appear as follows:

Signature Algorithm: sha1WithRSAEncryption

Postfix

Plesk versions 9.0 and newer can now use Postfix as an alternative to qmail. A few changes are necessary to make Postfix PCI compliant. Add the following to /etc/postfix/main.cf:

smtpd_tls_protocols = SSLv3, TLSv1 smtpd_tls_ciphers = medium smtpd_tls_exclude_ciphers = aNULL smtpd_sasl_security_options = noplaintext

Apache

Disable TRACE and TRACK

Upgrade Plesk to at least version 8.6.0, it's as simple as that.  The following directive can be added to /etc/httpd/conf/httpd.conf for the same effect:

TraceEnable Off

The above assumes Apache is at the most recent patch level available from Redhat.

Weak SSL Ciphers

Disabling weak SSL ciphers can be accomplished by introducting /etc/httpd/conf.d/zz050-psa-disable-weak-ssl-ciphers.conf into /etc/httpd/conf.d.  Place the following directives into this file:

SSLProtocol -ALL +SSLv3 +TLSv1 SSLCipherSuite HIGH:MEDIUM:!SSLv2:!LOW:!EXP:!aNULL

Standard testing methodology applies.

UserDir and ServerTokens

Disabling UserDir and changing the Apache ServerTokens directive lowers the profile of the web server software through obscurity.  As a result, the attacker will have a more difficult time targeting attacks against.  See below for an example of how these directives can present a security risk to your server.

The attacker begins requesting URLs from the server in the following format:

http://www.example.com/~joedoe

An error code of 403 is presented to the attacker indicating the directory exists but access is restricted.  The error pages also contains an interesting string of text:

Apache/2.0.53 (Linux)

It has now been determined by the attacker that a user named joedoe is present on the target.  The target is a Linux server running Apache 2.0.53.  Attempts can now be made to guess the password for the joedoe user. The attack may escalate if the user account becomes compromised. For example, if joedoe has been granted shell access the attacker may be able to obtain root access if a privilege escalation vulnerability exists in the underlying operating system. With shell access to the server an attacker can initiate denial of service attacks against other hosts or begin spamming and phishing activity.

This can be prevented by some degree by modifying the  UserDir and ServerTokens directives. These directives can be found in /etc/httpd/conf/httpd.conf. Change them to the following:

UserDir disabled ServerTokens Prod

After restarting Apache the server will present generic software version information to the public. Any request for UserDir URLs will receive a 404 result code.

expose_php

It is becoming increasingly common for PCI scans to fail a server if expose_php is enabled. Like UserDir and ServerTokens above, this falls into the category of security through obscurity. There are two easy ways to disable expose_php. It can be disabled in php.ini:

expose_php = Off

It can also be disabled if PHP is being called through Apache mod_php at the virtual host level:

php_admin_flag expose_php 0

Information Disclosure

Other information disclosure vulnerabilities are often flagged, most frequently Etags and directory indexes. Make sure the FileEtag directive does not expose the inode of modified files:

FileETag MTime Size

Directory indexes can be disabled by using Options -Indexes. This directive can be used in the Apache configuration or .htaccess files.

Testing

Make sure to test any configuration changes before restarting Apache:

httpd -t

ProFTPd

ProFTPd is frequently flagged for multiple vulnerabilities. If access to ftp services can not be restricted then the control panel should be updated to version 9.5.2 or higher. There is no fix available for older versions of Plesk.

Plesk Control Panel

Additional configuration may be required if a firewall is not installed to limit access to the Plesk service ports.  Modifications to the Parallels supplied Apache are added to /usr/local/psa/admin/etc/httpsd.custom.include. Adding the following directives to this file will disable weak SSL ciphers, UserDir, ServerTokens and expose_php up to Plesk 8.6.0:

UserDir disabled ServerTokens Prod SSLProtocol -ALL +SSLv3 +TLSv1 SSLCipherSuite HIGH:MEDIUM:!SSLv2:!LOW:!EXP:!aNULL php_admin_flag expose_php 0

Expect Header Cross Site Scripting Vulnerability

This affects older versions of Apache, specifically the 1.3.x version shipped with Plesk versions 8.6.0 and older. Upgrading to Plesk 9 or newer is the recommended way to resolve this issue.  Parallels suggests adding the following to /usr/local/psa/admin/etc/httpsd.custom.include:

ErrorDocument 417 "Expect not supported"

A standard service restart is required to apply the changes.

Some scan providers will not accept this workaround.  In those cases a Plesk upgrade is necessary.

Plesk >=9.0

Weak SSL Ciphers

As of Plesk 9.0 the control panel no longer uses Apache. It now uses Lighttpd. Disabling weak SSL ciphers is just as easy as disabling them for older Plesk versions. Add the following:

HIGH:MEDIUM:!SSLv2:!LOW:!EXP:!aNULL

To /usr/local/psa/admin/conf/cipher.lst, then restart the control panel web server:

/etc/init.d/sw-cp-server restart

If single sign on is being utilized, the following should be added to /etc/sw-cp-server/applications.d/sso-cpserver.conf:

ssl.cipher-list = "HIGH:MEDIUM:!SSLv2:!LOW:!EXP:!aNULL" ssl.use-sslv2 = "disable"

This needs to be placed directly below both ssl.engine = "enable" directives.

expose_php

Create a file named php.ini in /etc/sw-cp-server containing the following:

expose_php = Off

Next, locate the following in /etc/sw-cp-server/applications.d/sso-cpserver.conf:

var.interpreter = "/usr/bin/sw-engine-cgi"

Change it to the following:

var.interpreter = "/usr/bin/sw-engine-cgi -f /etc/sw-cp-server/php.ini"

The control panel web server will need to be restarted to implement the above changes.

iptables

PCI compliance scans may highlight vulnerabilities in the operating system's ip stack. Certain icmp types may help an attacker determine the version of the operating system installed through a technique known as operating system fingerprinting.  The following iptables rules can be applied to mitigate this threat:

iptables -N OSFP iptables -A OSFP -i eth0 -p icmp --icmp-type redirect -j DROP iptables -A OSFP -i eth0 -p icmp --icmp-type timestamp-request -j DROP iptables -A OSFP -i eth0 -p icmp --icmp-type timestamp-reply -j DROP iptables -A OSFP -i eth0 -p icmp --icmp-type address-mask-request -j DROP iptables -A OSFP -i eth0 -p icmp --icmp-type address-mask-reply -j DROP iptables -A OSFP -j RETURN iptables -I INPUT 1 -j OSFP

This will create a new chain named OSFP (Operating System FingerPrinting) that filters the icmp types that may allow an attacker to determine the host operating system. This ruleset may to be added to any existing iptables firewall.

OS fingerprinting can be disabled using sysctl as well:

echo "net.ipv4.tcp_timestamps = 0" >> /etc/sysctl.conf

Run sysctl -p after editing to apply the change.

Notes

Medium SSL ciphers

Some PCI scan providers want to see medium SSL ciphers disabled along with the usual weak ciphers. Use the following to disable both weak and medium SSL ciphers:

HIGH:!MEDIUM:!SSLv2:!LOW:!EXP:!aNULL

Plain Text Authentication With Postfix

Disabling plain text authentication without having alternative methods enabled will cause Postfix to stop relaying mail. Please see this mailing list post for an additional caveat to disabling plain text authentication.

Updates

As with any web application, it is absolutely essential to keep Plesk updated. Parallels frequently releases microupdates and while they are getting better at announcing security updates, they still have some work to do. Also note that Plesk updates only apply to the control panel. Third party add ons and additional web applications that may be installed receive updates independently. Remember, security is more of a journey than a destination.  If a server fails to achieve compliance after following the above advice, a company that specializes in auditing and hardening servers should be consulted.

Questions

This is a living document and as such, it will never truly be completed. Please feel free to e-mail questions regarding this document, especially if you are a commercial entity referring clients here.

blogroll

social