Yesterday, I commented on how hardening host.conf file provides very little security. Today, I want to focus on another item often found on “server hardening” checklists: TMP directory hardening. While TMP directory hardening still has its place, I feel it has lost its effectiveness in today’s threat landscape.
Before TMP Directory Hardening
After applying these changes to your /etc/fstab file, you will end up with something like this:
/dev/sda2 /tmp ext3 defaults 1 1
After TMP Directory Hardening
/dev/sda2 /tmp ext3 rw,nodev,nosuid,noexec 1 1
What’s being done?
TMP directory hardening involves restricting activities on the /tmp and /var/tmp directories by use of mount options. The motivation for this on web hosting servers is to prevent attackers from executing code within the /tmp directory. Since /tmp is world writable, if an attack can gains access to the system, they can store and execute files from within /tmp.
For filesystem hardening, the CIS benchmarks focus on three key restrictions:
nodev – prevent devices from being created on the filesystem
nosuid – ignores the suid bit on the filesystem
noexec – do not execute files on this filesystem
These restrictions should be used of various directories, such as /tmp, to restrict activity on the server. It is also recommend that you symlink /var/tmp to /tmp to prevent hardlinks from within /tmp to data contained in /var.
cPanel has a script called securetmp that can be ran on boot to secure the tmp directory (but it does not apply a nodev restriction).
Analysis of TMP Hardening
While I still recommend this step when hardening a server, I think the usefulness of it has been lost. Attackers used to dump files into /tmp via a web application exploit. They would then try to execute these files. Switching to using noexec on /tmp directories prevented this type of attack.
Unfortunately, there is an easy way around these restrictions. You can simple call your scripts via a perl, php or similar program instead of putting an executable in /tmp.
For example, if you put a hello.pl script into /tmp and try to run it directly with the noexec option enabled, the script will fail. However, if you simply run it as perl /tmp/hello.pl it will work.
More recently, most web application exploits have involved XSS exploits which directly runs code from within the script. As a result, the /tmp hardening procedures do little to protect you from these attacks.
Conclusion
While I still recommend doing /tmp hardening, I place little value in it. I’ve seen numerous incidents where /tmp was secured but attackers still ran code from the directory through various wrapper approaches. I’ve also seen situations where /tmp was hardened but /var/tmp and /dev/shm left open. The latter two directories are popular targets as well.
So while this step certainly does not hurt, I find it does little to improve security on a web hosting sever. I often find it listed in the laundry list of items included in server hardening checklists.
Currently, I recommend securing /tmp only when your server already has a dedicated /tmp partition. Given the low value of this technique in today’s threat landscape, I do not feel it necessary to use workaround approaches, such as cPanel’s securetmp script, to get /tmp hardened.