Blogging Techstacks

The PCI Compliance Paradox

Systems Administration can be frustrating at times, especially in the area of security compliance and vulnerability management. For all my development readers with friends in operations who are wondering why their sysadmins seem so cranky the first couple of weeks into the new quarter, it is most likely due to the sysadmin recently receiving the most recent pci quarterly vulnerability scan results from a scanning vendor.

PCI Compliance is a set of guidelines organizations handling credit card data need to achieve and is defined by the Payment Card Industry Data Security Standard. PCI has a number of problems associated with it; the most notable being outside of the security folks and the sysadmins who need to remediate the vulnerabilities, no one cares about PCI compliance. This isn't to say that PCI compliance isn't important because it is very important and the penalties and fines that can be levied against an organization for non-compliance can be quite heavy and, in some cases, business disrupting. It's just that no one cares about PCI compliance. Your development and business partners care more about releasing new functionality or fixing bugs. They don't care if you need to upgrade to a new version of apache as long as it doesn't interfere with their release dates or break their apps. Development does not care how you implement workarounds to their input handling bugs as long as they don't have to fix the code themselves. (If they do need to fix it, it will always take 6 to 9 months.) The security team doesn't care if there is no remediation for a particular vulnerability—just mitigate it. Dealing with these is part of the job and does not aggravate the sysadmin too much. What frustrates the sysadmin is what I call The PCI Compliance Paradox. The paradox is simple to express:

If you were certified PCI Compliant and suffer a breach, you were not PCI Compliant

This is Number 5 of my Unofficial Laws of General Systems Administration, by the way. The PCI Compliance Paradox leads to systems administrator frustration simply because one begins to think that an awful lot of time, effort, and money is going toward a sisyphean endeavor that one can never truly achieve because of the frequency of the appearance of new vulnerabilities or because you are one 0-day away from losing that certification.

Luckily, what helps me is a popular phrase the business world has coined to aid in combatting these feelings of helplessness: "It is what it is". To all my systems administration friends and colleagues out there reading this, how do you deal with the PCI Compliance Paradox and the organization-wide apathy?

Mitigating the Apache Range Header DoS on Ubuntu Apache 2.2

If you are running apache 2.2 (the current version in Ubuntu Server on my recently created VM being 2.2.17) and you wish to mitigate your web server against exploitation by the Apache Range Header Denial of Service vulnerability and the killapache exploit, below is the mitigation steps that worked best for me.

Ubuntu's Apache 2 implementation utilizes httpd.conf for user specific server configuration changes. The mitigation suggestion from the Apache Software Foundation that had the most favorable impact was scrubbing the Range Header if an incoming request contains more than 5 ranges within that specific request. Please note that this fix may not help with future versions of the exploit.

The workaround makes use of mod_headers, which, on a stock ubuntu server apache2 installation, is not enabled. You can enable it using the command line:

sudo a2enmod headers

Once that is complete, modify your servers httpd.conf and add the following directives:

SetEnvIf Range (?:,.*?){5,5} bad-range=1
RequestHeader unset Range env=bad-range

If you want to enable logging of hosts sending you those range requests, modify the configuration file for your virtual server—if you add it to the httpd.conf, the log file will get created but nothing will get logged. For example, if you are using the instance, modify the /etc/apache2/sites-available/default configuration file and add the following line somewhere that makes sense:

CustomLog /var/log/apache2/range-CVE-2011-3192.log common env=bad-range

That's all you need to do. Pretty straightforward workaround but hopefully a more formal fix will be made available by the Ubuntu Server team soon.

Apache Tomcat 7.0.21 Released

The Apache Tomcat team released version 7.0.21 today, which fixes some bugs and addresses some security issues.  Some of the more important changes in this release, which were summarized in the release announcement, include:

• A fix for CVE-2011-3190 that allowed an attacker to inject requests when Tomcat was configured behind a reverse proxy using the AJP protocol.
• Multiple additions and improvements to the memory leak detection/prevention features.
• Improved validation of received AJP messages.

The changelog lists all of the changes in this release and you can download a copy from a mirror near you.