“Defense in Depth” is a key concept of information security; if an attacker can get through one security control, there should be others waiting to thwart him. Mount options are an oftentimes overlooked way to implement defense in depth which are easy to implement, simple to understand, and widely applicable to many situations.
The directory holding web content (hosted by a web server, such as Apache or nginx) should never allow executables to be run, should not respect suid files, and should not contain device files. Therefore, instead of just assuming that none of those things will happen, mount options can be used to enforce those rules. For example, with the mount option “noexec” set, Linux will not allow any executable files within that mount point to be executed.
Implementing these restrictions is a powerful security hardening tool. With these mount options set, for example, if a malicious actor does manage to upload an executable (such as by using incorrectly configured WebDAV or a WordPress exploit), he will not be able to execute it (such as by using another exploit). Mount point options can be used to limit the harm an attack can do, or at least make things harder for them. For example, when implemented for a WordPress site, these restrictions can stop automatic attack bots (which typically gain access by guessing passwords) from being able to execute their malware payloads.
This approach can be applied to many other directories as well. For example, on a source code repository server running Git, executables shouldn’t be run from the repository directory. So use mount options to make sure that never happens.
If the mount already exists (such as if it’s a hard drive), edit fstab to add the mount options, for example:
LABEL=www /var/www btrfs nodev,nosuid,noexec 0 0
If the directory to be restricted isn’t its own mount point, make it one with a bind mount then remount with restrictive mount options:
mount -o bind /var/www /var/www
mount -o remount,bind,nosuid,nodev,noexec /var/www /var/www
See the mount man page for more details.
I’ve implemented in this security measure in VersionPress on AWS. The commit where I did so demonstrates a technique for setting the nodev,nosuid,noexec options when mounting an EFS file system from both a regular EC2 instance and instances running in Beanstalk.
