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.