At DrupalCONCEPT operations, our intrusion detection system recently notified us that it found a rootkit in the directory /dev/shm on one of our servers. This directory is writeable by the Apache webserver, so attackers that find a vulnerability in the installed software are able put hostile content (aka rootkits) there.

Of course, the vulnerability shouldn’t be there in the first place. We’re doing security updates all the time, but only on the OS and hosting infrastructure level. Since the actual web applications running on our infrastructure (in our case, Drupal) are maintained by our customers, we don’t have the same kind of tight control here as we have on the OS level.

Okay, we may not be able to prevent attackers from deploying their scripts. But we can prevent those scripts from doing any harm. This is where the noexec filesystem option comes in handy. Files on filesystems that have this option enabled can’t be executed even if they have their execution permissions (“x” ) set.

We use a Chef recipe to modify /etc/fstab accordingly. The first execute resource does a remount of the /dev/shm filesystem, but only if triggered by another resource. Namely, the following bash resource that modifies /etc/fstab if it’s not already hardened:

[gist id=1550976]

Since we include this recipe in our base Chef role, it’s applied to every server we set up.