PCI Compliance And Back Ports

I was recently hired to do a PCI compliance scan and complete the remedial work to bring it up to standard. This was on a CentOS5 box. The tool I was using to do the scanning was pretty good, but like all scanning tools plays “the numbers game.” This means it simply looks at the versions of certain services and flags it if that version is known to be vulnerable. In my case, Apache and PHP were causing the most red flags. There were some XSS (cross-site scripting) vulnerabilities addressed in Apache 2.2.8 and my server header was showing 2.2.3. PHP was the same story, with several DoS and code execution vulnerabilities fixed in 5.2.7, and I was apparently running 5.2.6. Obviously vulnerable, right? No and yes. I’ll explain why this is the case, and how you can tell what you’re really vulnerable to.

Linux distributions such as Red Hat (RHEL, Fedora, CentOS) sometimes rely on “back ports” or patching the existing version of the service, fixing the hole without updating the version number. This means a lot of false positives on the scan, which you can clear up with the rpm tool, grep and a web browser. Let’s start with Apache – the scanner says I am running 2.2.3, which is obviously vulnerable to some cross-site scripting (XSS) attacks. Being vulnerable to XSS is a PCI compliance fail. So I checked out the changelog for Apache 2.2 and saw that CVE-2008-2939 was fixed in version 2.2.10. We then run:

[root@steve ~]# rpm -q --changelog httpd | grep CVE-2008-2939
- add security fixes for CVE-2008-2364, CVE-2008-2939 (#468840)

This shows that someone from RedHat applied the patch to fix this vulnerability, but the version number wasn’t updated. This is a clear false positive. If you don’t find the CVE number listed in the changelog, pipe the output to less and look for anything mentioning the affected module or an upgrade to a version that includes the fix. For example, in my case, PHP 5.2.7 fixed a bunch of security problems in prior versions, some of which are a PCI fail.

When I looked through the PHP rpm changelog, the last thing I found was the update to 5.2.6 with no mention of 5.2.7 or patches for the issues addressed. Checking out the PHP changelog showed a lot of security fixes for 5.2.7. I ended up using a PHP 5.2.8 rpm from atomicrocketturtle.com which included the fixes. Using a third-party repository isn’t particularly ideal, but given the choice between that and either building from source or applying patches to a source rpm, I picked the third-party.

A few final thoughts:

  • You may find it easier to disable a module or service than patch it. If a module or service isn’t required, then disable it. This is good security practice.
  • For those services that are only required locally, such as database and mail services, bind them to the localhost interface and firewall them.
  • Don’t put all your faith in automated scanning – they are a tool, not an absolute solution. You will need to go through the results yourself, or hire someone to help you.

If you’re looking to hire someone to set up a PCI compliant LAMP stack or audit an existing one, please contact me for an estimate.

External DNS at 1and1

If you have your DNS hosted in one place (say DNS Made Easy) but host your content on 1and1.com. 1and1 allows you to do this without transferring the domain to them. The problem is they appear to not set the DirectoryIndex directive for hosts using external DNS. This can be overcome with either creating or adding to the .htaccess file in your site’s root directory:

DirectoryIndex index.php

That’ll work for WordPress, or most other PHP-based sites. You can always change it to index.html if that’s what your site’s index page is.

How to Start sshd On Plesk

I had a client machine reboot today and ssh wasn’t configured to come up on boot. This was a CentOS Plesk machine at my least favorite hosting provider, Media Temple. Secure shell isn’t mentioned in the services section in Plesk, and Media Temple doesn’t have a remote console feature. So in order to avoid submitting a ticket and waiting for Media Temple’s slow support, I managed to restart sshd using Plesk’s web interface to cron (Scheduled Tasks) to start it. Here’s what I did:

  • Got the current server time (it might not be in your timezone) by going to Server > Time
  • Went to Server > Scheduled Tasks and created a new scheduled task 2 minutes ahead of the current server time. The task should run /etc/init.d/sshd start.
  • Wait.

Hopefully within 2 minutes sshd is started. Don’t forget to remove the scheduled task, and ensure that sshd is configured to start on boot (chkconfig –levels 345 sshd start or whatever your distro uses.) Honestly I think Media Temple should have a backend console similar to how other VPS providers such as Slice and Linode do it. You’re paying enough.

Apache restarts with vlad

Often when deploying a new web application you need to restart the apache process. If you’re deploying the application with vlad the deployer as a non-root user (which you should be doing) and you need to restart apache, this can be a little tricky. Luckily there’s a Linux command called sudo which allows you to run commands from a non-root user’s account as though you were root. We’ll limit the commands to just controlling the apache process. It’s a bad idea to give open access with sudo since the user can simply run “sudo su -” and become root.

In order to edit the configuration file that sudo uses (/etc/sudoers btw) we use the visudo command, which edits the file in a safe way by checking for simultaneous users editing the file, parse errors, etc. The idea being to minimize the number of mistakes that can be made. You’ll need to be root (or have sudo permission!) to edit the file:

  # visudo

This brings up an editor screen, whatever you have configured as your default editor. The example below is for Ubuntu, so if you’re using a different distro or web server you’ll need to change the location of the init scripts accordingly (i.e. Ubuntu uses /etc/init.d/apache2 but your distro may use /etc/init.d/httpd or /etc/init.d/lighttpd if you’re running Lighttpd.) I’ll also assume you’re calling the deployment user deploy.

Here are the lines you want to add:

Cmnd_Alias     APACHE = /etc/init.d/apache2 start, /etc/init.d/apache2 stop, /etc/init.d/apache2 restart, /etc/init.d/apache2 reload
# Allow the deploy user to control apache

Now save the file, and log in as your deploy user. You should be able to restart apache with the above commands by running:

deploy@steve:~$ sudo /etc/init.d/apache2 restart

Now in your vlad tasks, use the sudo version above to kick the webserver over when you do a deploy:

         # desc "Starts Apache"
         remote_task :start => :settings do
             run 'sudo /etc/init.d/apache2 start'

         # desc "Restarts Apache"
         remote_task :restart => :settings do
             run 'sudo /etc/init.d/apache2 restart'

         # desc "Stop Apache"
         remote_task :stop => :settings do
             run 'sudo /etc/init.d/apache2 stop'