Creating a proper partition structure during Linux installation is one of those steps that lays the foundation for overall system stability. Beginners, and sometimes even experienced sysadmins, often limit themselves to creating a single large root partition, throwing all data into one place. However, dividing the system into logical parts is an essential part of configuring a server or even a workstation; exceptions to this rule should only be made for temporary testing environments.

The first reason for partitioning that comes to mind is protection against disk space exhaustion. Knowingly or unknowingly, an unprivileged user can write too much data to /home/. Similarly, a server might come under attack, or a software malfunction could cause a program to incessantly write messages to log files (/var/log), filling up all available space.

Let us look at a partition layout that incorporates the recommendations of the CIS Benchmarks security standard (What is CIS). CIS requires isolation not just to prevent disk space exhaustion, but also to apply specific mount options (nodev, nosuid, noexec) that block malicious script execution and privilege escalation.

Partition Layout#

EFI System Partition (ESP)#

A dedicated partition on the storage drive formatted with the FAT32 filesystem. It stores bootloaders and hardware drivers invoked by the motherboard firmware before the Linux kernel itself starts. This partition is mounted at /boot/efi.

  • Size: General best practices recommend allocating 250–512 MB. This is more than enough to store multiple bootloader versions and EFI applications.
  • Mount Options: umask=0077,fmask=0177,dmask=0077. This restricts access to the EFI content to the root superuser only, preventing ordinary users or compromised services from analyzing or modifying boot files.

swap (Swap Space)#

Swap space is virtual memory used by the operating system as an extension of physical random-access memory (RAM). Features:

  • Data Leak Protection: Since raw pages of RAM are flushed to swap, passwords, session keys, auth tokens, or personal user data can end up there in plaintext. Security standards require that swap space in critical infrastructures be encrypted (for example, using dm-crypt / LUKS). In this scenario, the encryption key is regenerated at every system boot, making it impossible to read data from swap after the server is shut down or rebooted.
  • Swappiness Parameter: The aggressiveness of swap usage can be managed via the vm.swappiness kernel setting (/etc/sysctl.conf). On highly loaded database servers, it is often reduced to minimal values to prevent the system from slowing down due to sluggish disk I/O operations by hitting swap unnecessarily.

/ (root)#

The core of the system. If all critical paths are mounted on separate partitions, root becomes almost static. A minimal set of utilities, /etc, and /boot (if not separated) remain here.

  • Mount Options: Default (defaults).

/usr (User System Resources)#

Contains all system programs, binaries, and libraries. According to CIS, separating /usr allows for a clear segregation of system software from dynamic data.

  • Security: Since users and services do not need to write anything to this directory during runtime, paranoid security modes allow it to be mounted as ro (read-only), permitting write operations only during package updates.
  • Mount Options: Default (defaults).

/var (Variable data)#

The general storage for dynamic data generated by system services.

  • Security: Isolation protects the root partition from overflowing if a service starts generating temporary files uncontrollably.
  • Mount Options: nodev (prevents the creation of device files).

/var/log (System Logs)#

The heart of system auditing. CIS insists on placing logs on a separate partition from the rest of the /var data.

  • Security: If an attacker attempts a DoS attack to flood the disk with logs and hide their tracks, they will only fill this specific partition. The system will continue running, and other services in /var (such as databases) will remain unaffected.
  • Mount Options: nodev, nosuid, noexec.

/var/log/audit (Audit Logs)#

A dedicated directory for the auditd daemon. This is a critical CIS requirement (e.g., CIS RHEL Benchmark).

  • Security: Audit logs record security events (who logged in, which files were edited). If standard logs (/var/log/syslog or /var/log/messages) overflow, security audit logs must be guaranteed to survive. If space here runs out, auditd can be configured to halt the system, keeping it secure as long as records are maintained.
  • Mount Options: nodev, nosuid, noexec.

/tmp (Temporary files)#

A storage area for temporary files, accessible for writing by absolutely all users and processes in the system.

  • Security: A primary entry point for many exploits. Attackers frequently download malicious scripts here.
  • Mount Options: nodev, nosuid, noexec. The noexec option prevents the execution of any binaries or scripts from this partition, disrupting hacker plans. A common choice is to mount this as tmpfs (in RAM). However, be careful with noexec; unfortunately, not all third-party software is compatible. For instance, an antivirus or a database engine might need to run its scripts from /tmp, so verify this before applying.

/home (User Directories)#

The space allocated for user home directories.

  • Security: Users always represent a risk. A separate partition prevents a user from filling the entire server disk with movies or backups.
  • Mount Options: nodev, nosuid (and sometimes noexec if users are forbidden from running their own executable files). This prevents the creation of files with the SUID flag (such as a copy of /bin/sh with root privileges) inside home folders.

/opt (Optional Software)#

The directory for installing third-party proprietary software (e.g., monitoring agents, Jira, specific databases not distributed via standard repositories).

  • Security: Isolates third-party software, which often updates frequently and grows in size, from the core operating system.
  • Mount Options: nodev, nosuid.

Summary Mount Table#

If you are building a secured server, the /etc/fstab configuration for these partitions should look like this:

Mount Point / Type Critical Options / Security Parameters FS Size Role in the Overall System
/boot/efi umask=0077,fmask=0177,dmask=0077 512Mb Secure system startup via UEFI.
swap Encrypted (dm-crypt), low swappiness 2Gb Insurance against OOM (Out of Memory) without data leak risks.
/ defaults 1Gb Stability of the kernel and core system.
/usr defaults (or even ro) 3Gb Protection of system binaries from modification.
/var nodev 2Gb Blocking the creation of rogue block devices.
/var/log nodev,nosuid,noexec 1Gb Log isolation, preventing code execution from logs.
/var/log/audit nodev,nosuid,noexec 1.5Gb Guaranteed retention of auditd security logs.
/tmp nodev,nosuid,noexec 1Gb Full neutralization of downloaded malicious scripts.
/home nodev,nosuid 1Gb Protection against privilege escalation attempts by users.
/opt nodev,nosuid 1Gb Control over third-party software behavior.

The table also specifies the initial filesystem sizes suitable for a minimal generic server.

Implementation Advice#

Implementing such a detailed scheme on “bare” disk partitions (sda1, sda2…) is administrative suicide. You will almost certainly miscalculate the size needed for /var/log/audit or /opt, forcing you to resize partition boundaries later.

The only proper way to fulfill these requirements is by using LVM (Logical Volume Manager). You create one large Volume Group on the disk and then carve out Logical Volumes inside it for each mount point. This allows you to allocate a minimal volume initially (e.g., 2 GB for audit) and expand it on the fly as needed without server downtime.