Hardening the /tmp Directory to Prevent Malware Execution

Most web applications and system services need a place to temporarily store files, such as PHP session data, cache fragments, or uncompressed image uploads. In Linux, the /tmp directory serves this exact purpose and is configured to be world-writable by design, meaning any user or service on the system can write data there.

However, this completely open access makes /tmp the primary landing zone for hackers. If an attacker finds an exploit in your web application (such as a vulnerable WordPress plugin), their very first move is usually to use wget or curl to download a malicious payload directly into /tmp and execute it. By altering how this directory is mounted to your VPS, you can physically strip the system's ability to run any programs from within that folder, stopping malware dead in its tracks.

The Power of Mount Options

When you attach a file system or partition in Linux, you can pass specific security flags that restrict exactly what operations are permitted within that space. To secure a temporary directory, you must apply three specific flags:

• noexec: This is the most critical flag. It explicitly prevents the Linux kernel from executing any binary files or shell scripts located in the directory. Even if an attacker successfully downloads a rootkit into /tmp, they cannot run it.

• nosuid: Prevents the execution of SetUID programs. This ensures that even if an attacker drops a binary into the folder designed to escalate privileges to root, the system will ignore the request.

• nodev: Prevents the creation or use of character and block special devices inside the directory, which attackers sometimes use to interact directly with server hardware or kernel memory.

Securing /tmp Using systemd (Modern Ubuntu/Debian)

Historically, administrators created dedicated hard drive partitions for /tmp and configured them in /etc/fstab. On modern systems running systemd, it is much cleaner to mount /tmp directly into your server's RAM as a tmpfs (temporary file system). This not only allows you to apply security flags, but it also dramatically speeds up application read/write times and automatically wipes the folder clean upon every server reboot.

• Connect to your VPS via SSH as a user with sudo privileges.

• Copy the default systemd mount template to your local system configuration directory to override the defaults: sudo cp /usr/share/systemd/tmp.mount /etc/systemd/system/

• Open the newly copied file using your text editor: sudo nano /etc/systemd/system/tmp.mount

• Locate the Options= line under the [Mount] section. It usually looks like Options=mode=1777,strictatime.

• Update this line to include your strict security flags: Options=mode=1777,strictatime,noexec,nodev,nosuid

• Save the file, then instruct systemd to reload its daemon configurations and restart the mount: sudo systemctl daemon-reload sudo systemctl restart tmp.mount

• Verify that the flags were applied successfully by running the mount command and filtering for /tmp: mount | grep /tmp (You should see noexec,nosuid,nodev listed in the output).

The Fallback Threat: Securing /var/tmp

Hackers write clever scripts. When their malware attempts to execute in /tmp and fails because of your new noexec rule, the script will immediately look for an alternative world-writable directory. The most common fallback is /var/tmp.

If you lock down /tmp but leave /var/tmp exposed, your security posture is incomplete. Instead of creating a separate RAM disk for /var/tmp, the most efficient method is to "bind" it directly to /tmp, forcing them to share the exact same strict security rules.

• First, clear out any existing temporary files in the directory: sudo rm -rf /var/tmp/*

• Open your system's file system table: sudo nano /etc/fstab

• Add the following line to the absolute bottom of the file to link the two directories together: /tmp /var/tmp none bind 0 0

• Save the file and apply the binding immediately without needing to reboot the server by running: sudo mount -a

• Now, any file written to /var/tmp is actually subjected to the noexec restrictions of /tmp, completely eliminating the attacker's fallback option.