Advanced Linux Hardening Guide for SysAdmins

1. Introduction

Linux hardening is an essential process within modern system administration, as current environments exhibit a level of complexity and exposure far superior to that of just a few years ago. Linux systems today run across a huge variety of scenarios: bare-metal servers, virtual machines, containers, multi-tenant environments, cloud platforms, edge computing, and industrial IoT devices. This diversity broadens the attack surface and demands much stricter and more controlled security measures.

The purpose of this document is to provide a comprehensive guide oriented toward high-level professionals—systems specialists, cybersecurity experts, DevOps engineers, and infrastructure teams—with the goal of establishing a set of advanced Linux hardening best practices. The approach is deeply technical and aims to serve as a practical reference for real production environments.

Throughout this guide, we dive deep into:

• base system hardening
• extreme attack surface reduction
• advanced privilege restriction mechanisms
• kernel and memory security
• critical service protection
• access control policies
• auditing, logging, and tracking
• automation in DevSecOps pipelines

Although hardening is often perceived as a one-time activity during the initial deployment of a server, the reality is that it is a continuous process. Threats change, attack vectors evolve, and configurations drift over time. Therefore, hardening must be integrated into the complete system lifecycle: design, deployment, maintenance, auditing, incident response, and decommissioning.

A solid security posture requires a combination of best practices, tools, configurations, control mechanisms, and a defensive mindset. No isolated technique is sufficient on its own; it is the sum of layers, controls, and policies that provides resilience.

2. Strategic Hardening Principles

Effective hardening must be grounded in a set of strategic principles that guide all design, configuration, and operational decisions. These principles apply not only to Linux, but to any modern security platform.

2.1 Principle of Least Exposure

This principle establishes that any component, resource, service, or system binary should be present only if it fulfills a strictly necessary function. Unnecessary exposure is one of the primary risk factors.

A system with fewer packages, fewer available binaries, fewer services listening on open ports, and fewer loaded modules is inherently more secure. Minimization reduces exploitation possibilities and facilitates integrity audits.

2.2 Principle of Least Privilege

Every process must execute with the minimum level of privilege necessary to perform its function. This implies:

• eliminating unnecessary SUID permissions
• replacing elevated privileges with granular capabilities
• isolating processes with sandboxing mechanisms
• strictly restricting service accounts
• defining tightly scoped roles and access policies

The goal is to prevent the exploitation of a service from automatically resulting in total system control.

2.3 Principle of Separation

Separation is a key mechanism to limit the impact of attacks. It is achieved through:

• user and group separation
• network and segment separation
• separation of services into containers or namespaces
• separation of the operating system from the application runtime
• permission separation using SELinux/AppArmor

When boundaries between processes are clear, a security failure in one component does not compromise the entire system.

2.4 Defense-in-Depth

This principle implies that multiple layers of defense must always exist. You cannot rely on a single mechanism because it:

• may fail
• may be misconfigured
• may be overcome by new attack vectors

Defense layers can include firewalls, access controls, audits, kernel restrictions, encryption, sandboxes, integrity systems, etc.

Effective hardening incorporates multiple barriers to prevent an attacker from easily escalating privileges.

3. System Preparation and Minimization

Before applying any advanced measures, it is essential to prepare the base system. Preparation includes selecting the appropriate regulatory framework, reducing installed packages, controlling privileged binaries, and managing kernel modules. The smaller the attack surface, the more effective the rest of the hardening will be.

3.1 Policy Selection and Regulatory Framework

Each organization can base its efforts on different standards or guides. Some of the most common include:

• SELinux: ideal in RHEL, Rocky Linux, AlmaLinux, and Fedora environments. Provides very granular mandatory access control.
• AppArmor: widely adopted by Ubuntu. Simple, effective, and comes with predefined profiles.
• Landlock: available in kernels 5.13 and higher, enables user-space sandboxing.
• CIS Benchmarks: offer widely recognized recommendations for Linux environments.
• ENS, NIST, ISO 27001: frameworks that may mandate specific regulatory configurations.

Defining a framework before starting avoids configuration inconsistencies and enables more effective audits.

3.2 Package Minimization

Eliminating unnecessary components reduces risk. Recommendations:

• avoid compilers (gcc, clang) if the server does not compile code
• uninstall debugging tools (gdb, strace) in sensitive environments - remove unused shells (zsh, csh)
• eliminate legacy daemons: telnet, rsh, tftp, talk, finger
• avoid graphical interfaces on servers
• remove drivers for absent hardware

Example to list installed packages:

rpm -qa | sort
apt list --installed

The goal is to ensure only software with a clear purpose exists.

3.3 SUID and Capabilities Control

SUID binaries can represent an enormous risk because they execute with root permissions. They must be reviewed periodically:

find / -type f -perm -4000 2>/dev/null

In many cases, it is possible to replace SUID with Linux Capabilities.

Example: removing SUID from ping and assigning only CAP_NET_RAW:

chmod u-s /usr/bin/ping
setcap cap_net_raw+p /usr/bin/ping

This approach reduces the potential for privilege escalation.

3.4 Kernel Module Control

Modules are pieces of code dynamically loadable into the kernel. Preventing unauthorized modules from loading is critical.

Recommendations:

• maintain a blacklist of unused modules
• enable mandatory module signing (module.sig_enforce=1)
• in critical environments, completely disable dynamic loading
• create a custom kernel with only necessary support

Blacklist example:

echo "blacklist firewire-core" > /etc/modprobe.d/blacklist-firewire.conf

4. Kernel Hardening

The kernel is the foundation of operating system security. Properly configuring its parameters and protecting its memory and internal operations is essential to prevent privilege escalation, information leakage, and vulnerability exploitation.

4.1 Advanced Sysctl Configuration

Kernel parameters control a large part of system behavior. It is recommended to create a file:

/etc/sysctl.d/99-hardening.conf

with settings such as:

# Anti-spoofing
net.ipv4.conf.all.rp_filter = 1

# Disable source routing
net.ipv4.conf.all.accept_source_route = 0

# Block ICMP redirects
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

# Strengthen ASLR
kernel.randomize_va_space = 2

# Restrict dmesg
kernel.dmesg_restrict = 1

# Restrict ptrace
kernel.yama.ptrace_scope = 1

These settings harden the network stack, improve privacy, and hinder vulnerability exploitation.

4.2 Memory Protection

Essential measures:

• ASLR enabled and set to strong mode
• NX (No-Execute) to prevent code execution in unauthorized memory
• Stack protector (-fstack-protector-strong)
• Fortify Source to prevent vulnerabilities in unsafe functions
• SLAB freelist randomization

All these measures hinder attacks such as buffer overflows or ROP.

4.3 Kernel Lockdown Mode

Available since Linux 5.x, especially on systems with Secure Boot.

Available modes:

• Integrity: prevents kernel modifications.
• Confidentiality: prevents internal kernel reading.

Enabled by adding:

lockdown=confidentiality

to the bootloader.

4.4 Mandatory Access Control (MAC): SELinux, AppArmor, and Landlock

Implementing a MAC mechanism is critical:

• SELinux: extremely robust, oriented toward enterprise environments.
• AppArmor: easy to configure and maintain.
• Landlock: modern sandbox, application-oriented.

Example to view active AppArmor profiles:

aa-status

5. Critical Service Hardening

Critical services are the most common entry points for attackers. Hardening them is fundamental to reducing the likelihood of exploitation and reinforcing the overall server security posture.

5.1 OpenSSH

OpenSSH is typically the primary administrative access point, requiring extremely careful configuration.

Recommended configuration in /etc/ssh/sshd_config:

Protocol 2
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
AllowUsers admin devops
ClientAliveInterval 300
LoginGraceTime 20

KexAlgorithms sntrup761x25519-sha512@openssh.com
Ciphers chacha20-poly1305@openssh.com
MACs hmac-sha2-512-etm@openssh.com

Isolation with systemd:

[Service]
PrivateTmp=true
ProtectSystem=strict
ProtectHome=yes
NoNewPrivileges=yes

Limit attempts via rate-limiting:

systemctl edit sshd

And in the override:

[Unit]
StartLimitIntervalSec=60
StartLimitBurst=4

5.2 Web Servers

For Apache, Nginx, or Caddy, recommendations include:

• disabling unnecessary modules
• enabling TLS 1.3 and disabling 1.0/1.1
• service isolation via systemd or lightweight containers
• security headers (CSP, HSTS, X-Frame-Options, Referrer-Policy)
• running under a dedicated account
• restricted log access
• removing sensitive information from server banners

Nginx example:

server_tokens off;
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;

5.3 Databases

Databases require a special level of protection.

Best practices:

• avoid network access if possible, use UNIX sockets
• separate the system user from the database user
• encrypt tablespaces with LUKS/fscrypt
• automated credential rotation
• enable auditing (PostgreSQL: pgaudit, MariaDB audit plugin)
• limit dangerous commands
• block remote access except from explicit hosts

PostgreSQL pg_hba.conf example:

local all all peer
host  all all 192.168.10.0/24 scram-sha-256

6. Filesystem Security

Filesystem security is one of the most underestimated layers in hardening. Despite this, it remains one of the most exploited vectors in real intrusions: misconfigured permissions, exposed mount points, accessible sensitive files, and a lack of immutability policies are extremely common flaws. This section delves into how to shield the storage layer to reduce risks of privilege escalation, unauthorized code execution, and manipulation of critical files.

6.1 Essential Mount Options to Reduce Attack Surface

Choosing the correct mount options in Linux is one of the simplest and most effective control elements. These options prevent unauthorized execution, misuse of SUID, and the presence of special devices in improper locations.

noexec

Prevents the execution of binaries located on the mount point.

Recommended uses:

• /tmp
• /var/tmp
• /home
• network-mounted systems (NFS, CIFS)
• external partitions

/etc/fstab example:

tmpfs /tmp tmpfs defaults,noexec,nosuid,nodev 0 0

nosuid

Prevents the use of SUID/SGID bits, blocking privilege escalations based on manipulated binaries.

Ideal application:

• directories accessible to untrusted users
• shared partitions in multi-tenant environments
• containers and virtual machines

nodev

Prohibits the presence of special devices on the mount point.

Fundamental for:

• /home
• /srv
• /tmp
• untrusted filesystems

This prevents an attacker from creating device nodes that allow direct access to hardware or pseudo-devices.

6.2 Protecting /boot

/boot is one of the most sensitive directories: it contains the kernel, initramfs, bootloader, and kernel signature. Manipulations here allow the installation of virtually undetectable persistent rootkits.

Separation into a dedicated partition

Allows applying specific mounts without affecting the rest of the system:

UUID=xxxx /boot ext4 ro,nodev,nosuid,noexec 0 2

Read-only mounting (ro)

Guarantees that no process can modify the kernel or initramfs unless the administrator remounts it manually.

Secure Boot and kernel signing

Recommended if UEFI is used.

• Enable Secure Boot in BIOS
• Use signed kernels
• Disable unsigned modules

This greatly reduces the possibility of bootkits or malicious payloads during boot.

6.3 Immutability with chattr

chattr +i marks files as immutable:

Files recommended for immutability:

• /etc/passwd
• /etc/shadow
• /etc/sudoers
• critical boot scripts
• security binaries (ssh, sudo, etc.)

Example:

chattr +i /etc/shadow

With +i, not even root can modify the file without first removing the attribute, which leaves clear traceability and reduces the risk of silent alterations.

7. Encryption and Cryptographic Management

Encryption is not optional today, especially in cloud environments, multi-tenant setups, and mobile systems. Protecting data at rest and in use is one of the main pillars of regulatory compliance and exfiltration mitigation.

7.1 Full Disk Encryption

LUKS2

The standard encryption method in Linux.

Best practices:

• Use LUKS2 (not LUKS1)
• Robust PBKDF such as Argon2id
• Enable auto-reencrypt if keys are updated
• Require 256-bit key lengths

TPM Integration

Allows secure unlocking without exposing keys in scripts or files:

• Use of clevis + tpm2
• Allows combined policies: “TPM + passphrase”

Ideal for servers without manual intervention.

7.2 File Encryption

fscrypt

Advantages:

• Native kernel integration
• Filesystem independent
• Perfect for multi-user setups

Typical usage:

fscrypt setup /home
fscrypt encrypt /home/user

Kernel Keyrings

The kernel manages keys temporarily without exposing them in user space.

7.3 Key Management and HSMs

Secure key management is fundamental to prevent information leaks, spoofing, and unauthorized access. In professional environments, keys must never be stored in plain text or depend solely on operating system security.

Using HSMs (Hardware Security Modules)

HSMs allow master keys to be stored in hardware such that:

• They cannot be extracted directly
• They cannot be copied or cloned
• They allow cryptographic operations without exposing the key

Ideal for:

• PKI infrastructures
• Authentication servers
• Banking systems
• Digital signatures

TPM 2.0

The TPM is an integrated chip that stores hardware-bound keys.

Advantages:

• Protection against offline attacks
• Prevents key theft from disks
• Integration with kernel keyrings
• Combinable with LUKS and Secure Boot

Vaults and Cryptographic Managers

• HashiCorp Vault
• Azure Key Vault
• AWS KMS
• GCP KMS

Best practices:

• Automatic rotation
• RBAC access control
• Key usage auditing
• Periodic regeneration

8. Kernel and Module Security

The kernel is the most critical attack surface. A single unchecked loaded module can compromise the entire system. Therefore, hardening its behavior is imperative.

8.1 Module Loading Restrictions

1. Disable hot loading

echo 1 > /proc/sys/kernel/modules_disabled

Once done, modules cannot be loaded or unloaded without rebooting.

2. Blacklists in modprobe.d

echo "blacklist firewire-core" > /etc/modprobe.d/blacklist-firewire.conf

3. Avoid unsigned modules

Modern kernels may require digital signatures for all modules.

8.2 Sysctl for Kernel Hardening

Critical settings:

kernel.kptr_restrict = 2
kernel.yama.ptrace_scope = 2
kernel.dmesg_restrict = 1
vm.mmap_min_addr = 65536
kernel.sysrq = 0

Brief explanation:

• kptr_restrict: hides kernel addresses
• ptrace_scope: prevents cross-user debugging
• dmesg_restrict: limits access to the kernel buffer
• mmap_min_addr: prevents null mapping
• sysrq: disables dangerous key combinations

8.3 Stack and Heap Protection

Recommended protections:

• ASLR (Address Space Layout Randomization)
• NX bit (No-eXecute)
• PIE (Position Independent Executables)

Verification:

sysctl kernel.randomize_va_space

Recommended value: 2

9. Services and Daemons Hardening

Every running daemon increases the attack surface. This section outlines how to minimize that risk.

9.1 Removal of Unnecessary Services

List all services:

systemctl list-unit-files --type=service

Disable:

systemctl disable --now service_name

Commonly dispensable services:

• avahi-daemon
• cups (if there are no printers)
• rpcbind
• bluetooth (on servers)

9.2 Sandboxing with Systemd

Systemd can natively isolate services:

Secure configuration example:

[Service]
PrivateTmp=true
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
MemoryDenyWriteExecute=true

9.3 Limiting Capabilities

Linux capabilities allow granting minimum privileges.

Example:

CapabilityBoundingSet=CAP_NET_BIND_SERVICE

10. Network Security

One of the most attacked and exploited areas. This section defines techniques for port control, isolation, advanced firewalls, and protocol protection.

10.1 Basic and Advanced Firewalls

Options:

• iptables
• nftables
• Firewalld

Example with nftables:

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        tcp dport { 22 } accept
        iif lo accept
    }
}

10.2 Port and Traffic Filtering

Blocking SYN scans:

net.ipv4.tcp_syncookies = 1

Anti-spoofing defense:

net.ipv4.conf.all.rp_filter = 1

10.3 IPS / IDS

Recommended systems:

• Suricata
• Zeek
• Snort 3

Best practices:

• Deploy in inline mode
• Updated signatures
• False positive exclusions

11. Containers and Virtualization

Containers require a security approach distinct from traditional machines.

11.1 Docker Hardening

Best practices:

• Use rootless mode
• Limit capabilities
• Disable TCP socket daemon access
• Enable AppArmor/SELinux profiles

AppArmor example:

docker-default {
    # restrictions here
}

11.2 Kubernetes Hardening

Critical points:

• Strict RBAC
• Mandatory NetworkPolicies
• Non-privileged containers
• API server auditing

11.3 Virtualization (KVM/QEMU)

Best practices:

• Disable USB devices
• Use virtio whenever possible
• Isolate NAT and bridge networks

12. Logs, Auditing, and Detection

A system without logs cannot defend itself or reconstruct attacks.

12.1 Auditd

Essential rules:

-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k sudo

12.2 Journald

Increase retention:

SystemMaxUse=1G
SystemKeepFree=500M

12.3 Remote Log Forwarding

Recommended:

• Graylog
• Splunk
• ELK
• Wazuh

13. Hardening Automation

Automation prevents incomplete or inconsistent configurations.

13.1 Ansible

Common roles:

• CIS benchmark
• SSH hardening
• Kernel hardening
• Auditd

13.2 Terraform + Ansible

Widely used in cloud environments:

• Terraform creates infrastructure
• Ansible hardens it

14. Continuous Monitoring

A hardened machine loses security as soon as it stops being observed.

14.1 Continuous Detection

Solutions:

• Wazuh
• OSSEC
• Lynis (continuous mode)
• CrowdStrike Falcon
• SentinelOne

14.2 System State Supervision

• Filesystem integrity
• Binary changes
• Permission modifications
• Rootkit detection

14.3 Alerts and Response

Best practices:

• Email/Slack alerts
• Grafana dashboards
• SIEM integration
• Response playbooks

15. Advanced Hardening Checklist

This checklist summarizes the main hardening actions that a sysadmin or cybersecurity team must implement on a production Linux system. Each item has been chosen to cover everything from attack surface reduction to continuous monitoring and container management.

• System minimization: removal of unnecessary packages and services
• Elimination of SUID and unnecessary capabilities
• Application of SELinux/AppArmor in enforcing mode
• Reinforced sysctl with security parameters
• Firewall configuration (nftables / iptables) with default DROP policy
• Hardened SSH: key-only authentication, limited users, strong algorithms
• Integrity control: AIDE, Tripwire, IMA/EVM
• Robust encryption: LUKS2, fscrypt, TPM, and centralized key management
• Centralized logs: Syslog/TLS, ELK, Graylog, or Loki
• Kernel lockdown mode enabled
• Rootless containers with strict seccomp and cgroups
• Complete auditing with auditd and specific rules
• Strict access control: users, groups, permissions, and ACLs
• Immutability of critical files with chattr +i
• Network segmentation: VLANs, VRFs, network namespaces
• /boot protection with separate partition, read-only, and Secure Boot
• Mount options: noexec, nosuid, nodev on sensitive directories
• Network attack filtering and mitigation: rp_filter, SYN cookies, ICMP restrictions
• Service hardening: systemd sandboxing, capability limiting, disabling unused services
• Global cryptographic policies: OpenSSL, crypto policies
• Centralized key management: Vault, PKCS#11, TPM2
• Syscall, traffic, and memory monitoring with eBPF
• EDR integration: Falco, Wazuh, CrowdStrike, Defender for Endpoint
• Kubernetes hardening: PodSecurity, Network Policies, signed images
• Hardening automation: Ansible, Puppet, SaltStack, Terraform
• Automatic security profiles: OpenSCAP, Lynis, Osquery
• Periodic review of logs and audits
• Centralized alerts and notifications with SIEM
• Documented incident response procedures
• Updated security telemetry and dashboards
• Constant evaluation of attack surface and mitigations
• Periodic rotation of keys and certificates
• Execution control for unknown or modified binaries
• Resource restrictions in containers and VMs (cgroups, quotas)
• Validation of integrity of installed images and packages
• Review of privileged users and groups
• Disable legacy network services: telnet, rsh, rpcbind
• Endpoint protection: physical and remote access limitation
• Secure and encrypted backups
• Regular vulnerability scanning and patching
• Review of critical application configurations (web, DB, etc.)
• Database hardening: file encryption, auditing, dedicated users
• Script execution controls: disallow arbitrary execution in /tmp
• Prevention of local privilege escalations
• Maintenance of change and configuration logs
• End-user education and awareness
• Review of security logs and anomalous events
• Security policies aligned with norms and standards (CIS, NIST, ENS)
• Integration of security analysis and benchmarking tools
• Review of kernel modules and removal of unnecessary ones
• Application of specific security profiles for containers and VMs

16. Conclusion

Linux system hardening is a continuous and multidimensional process. It is not merely about applying rigid configurations, but about establishing a comprehensive approach combining:

• Attack surface minimization
• Privilege control and separation of duties
• Kernel, service, and network hardening
• Data encryption and secure key management
• Auditing, monitoring, and integrity control
• Container and virtualization security
• Automation and reproducible deployment
• Telemetry and early incident detection

Security is not static: new vulnerabilities, threats, and attack vectors continually emerge. Therefore, every hardening action must be regularly reviewed, updated, and audited.

Adopting a defense-in-depth approach, alongside automation tools, monitoring, and centralized control, ensures that Linux systems remain resilient against attacks, comply with regulations, and maintain the integrity of critical infrastructure.

With this advanced guide, sysadmin, cybersecurity, and DevSecOps professionals have a complete map of practices, tools, and configurations to implement solid hardening and keep it updated in modern production environments.

“The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room… and even then I have my doubts.” – Gene Spafford