Linux Advocacy

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.  The following assumes the server being configured has Redhat Linux, or a variant, installed.

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.

Courier

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:

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

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:

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:

ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:!SSLv2:RC4+RSA:+HIGH:+MEDIUM

Testing with openssl is highly recommended:

openssl s_client -connect localhost:25 -starttls smtp

Apache

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
SSLCipherSuite HIGH:MEDIUM:!SSLv2:!LOW:!EXP:!aNULL:@STRENGTH

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

Plesk

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
SSLCipherSuite HIGH:MEDIUM:!SSLv2:!LOW:!EXP:!aNULL:@STRENGTH

<VirtualHost 192.168.10.210:8880>
RewriteEngine on
RewriteCond %{REQUEST_METHOD} !^(GET|POST|HEAD)$
RewriteRule .* - [F]
</VirtualHost>

<VirtualHost 192.168.10.210:8443>
SSLEngine on
SSLCertificateFile "/usr/local/psa/admin/conf/httpsd.pem"
SSLVerifyClient 0
SSLVerifyDepth 0
RewriteEngine on
RewriteCond %{REQUEST_METHOD} !^(GET|POST|HEAD)$
RewriteRule .* - [F]
</VirtualHost>

A standard service restart is required to apply the 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.

The server now be ready for a follow-up scan. 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.