Plesk for Linux – PCI Compliance


Weak SSL Ciphers and SSLv2

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


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

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:


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


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.


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


Testing with openssl is highly recommended:

openssl s_client -ssl2 -connect localhost:25 -starttls smtp


Disable TRACE and TRACK

Upgrade Plesk to version 8.6.0, it’s as simple as that. Previous fixes presented here did not work in all situations and therefore have been removed.

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

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:

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 test:

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


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, TRACK and TRACK methods, UserDir, and ServerTokens capabilities:

UserDir disabled
ServerTokens Prod
SSLProtocol -ALL +SSLv3 +TLSv1

RewriteEngine on
RewriteRule .* – [F]

SSLEngine on
SSLCertificateFile “/usr/local/psa/admin/conf/httpsd.pem”
SSLVerifyClient 0
SSLVerifyDepth 0
RewriteEngine on
RewriteRule .* – [F]

A standard service restart is required to apply the changes.

Additional 26/02/2010 – It seems PCI scans are getting a little stricter and object to many more things, including the outdated version of Apache that Plesk uses.

Adding the following to /usr/local/psa/admin/etc/httpsd.custom.include will resolve the “Apache HTTP Server 413 Error HTTP Request Method Cross-Site Scripting Weakness” and “Expect Header Cross-Site Scripting Vulnerability” isssues:

ErrorDocument 417 “Expect not supported”
ErrorDocument 413 “Error 413 – Request Entity Too Large”
UserDir Disabled


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.

Thanks to linux-advocacy for this info.

You can leave a response, or trackback from your own site.

Leave a Reply