Linux Server Security Hardening: A Complete Enterprise Guide
Linux servers run the majority of enterprise cloud workloads, web applications, databases, and container hosts. Default Linux installations are configured for compatibility and usability, not security. Systematic hardening reduces the attack surface available to attackers who gain initial access and limits the damage they can do. The CIS Benchmarks for Linux provide the most widely adopted hardening standard; this guide translates those recommendations into a practical implementation sequence.
Hardening Sequence: Highest Impact First
Linux hardening spans dozens of configuration areas. Prioritize in order of risk reduction impact:
SSH hardening
SSH is the primary remote access path to Linux servers and the most commonly attacked service. Harden immediately: disable root login (PermitRootLogin no), disable password authentication and require key-based auth only (PasswordAuthentication no, PubkeyAuthentication yes), change the default port from 22 only if this reduces automated scan noise for your environment (does not provide meaningful security against targeted attackers), restrict SSH to specific user groups (AllowGroups ssh-users), set an idle timeout (ClientAliveInterval 300, ClientAliveCountMax 0), and disable unused authentication methods (KerberosAuthentication no, GSSAPIAuthentication no).
Unnecessary services and packages
Every running service is an attack surface. Remove packages that are not required (apt purge / yum remove for: telnet, rsh, rlogin, tftp, xinetd, finger, talk, ypbind). Disable services that are not needed (systemctl disable and stop: avahi-daemon, cups, nfs, rpcbind, bluetooth). Use systemctl list-units --type=service to audit running services and document justification for each.
User and privilege management
Lock or delete unused system accounts (passwd -l username). Ensure root is the only account with UID 0 (awk -F: '($3 == 0) { print $1 }' /etc/passwd). Set password aging policies (/etc/login.defs: PASS_MAX_DAYS 90, PASS_MIN_DAYS 7, PASS_WARN_AGE 14). Configure sudo to log all commands (Defaults logfile=/var/log/sudo.log) and require password for each sudo invocation (Defaults timestamp_timeout=0). Remove unused user accounts and disable accounts of departed employees immediately.
Filesystem hardening
Mount /tmp with noexec, nosuid, nodev options to prevent execution of malicious binaries placed there. Apply the same to /var/tmp and /dev/shm. Enable filesystem integrity monitoring (AIDE, Tripwire) on critical directories (/bin, /sbin, /usr/bin, /etc) to detect unauthorized file modifications.
Mandatory Access Control: SELinux and AppArmor
Mandatory Access Control (MAC) enforces security policies that limit what processes can do beyond standard Unix permissions, containing the impact of exploited vulnerabilities. Linux provides two MAC implementations:
SELinux (Security-Enhanced Linux)
Default on RHEL, CentOS, AlmaLinux, and Rocky Linux. Operates in permissive mode (logs policy violations without enforcement) or enforcing mode (blocks policy violations). Always run in enforcing mode: setenforce 1 and set SELINUX=enforcing in /etc/selinux/config. Use targeted policy (the default) which applies MAC to specific high-risk daemons rather than the entire system. Never disable SELinux to resolve application errors: use audit2allow to generate policy exceptions that allow the specific required operation without disabling enforcement entirely.
AppArmor
Default on Ubuntu and Debian. Profile-based: each application has a profile defining what files it can access and what system calls it can make. Run in enforce mode: aa-enforce /etc/apparmor.d/*. Check profile status with aa-status. Create profiles for custom applications using aa-genprof to learn the application's access patterns. Ubuntu installs AppArmor profiles for common services (nginx, mysql, cups) by default; verify they are loaded and in enforce mode.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Kernel Security Features
Modern Linux kernels include security hardening features that should be explicitly enabled:
Sysctl hardening
Configure /etc/sysctl.conf or /etc/sysctl.d/99-hardening.conf with: kernel.dmesg_restrict=1 (restrict dmesg access to root), kernel.kptr_restrict=2 (hide kernel pointer addresses), net.ipv4.conf.all.rp_filter=1 (enable reverse path filtering), net.ipv4.conf.all.accept_redirects=0 and net.ipv6.conf.all.accept_redirects=0 (reject ICMP redirects), net.ipv4.tcp_syncookies=1 (SYN flood protection), kernel.randomize_va_space=2 (full ASLR).
Secure Boot and UEFI
Enable Secure Boot to prevent loading of unsigned kernel modules and bootloader tampering. Verify Secure Boot status with mokutil --sb-state. Protect GRUB with a password to prevent boot-time parameter modification: grub2-setpassword.
kernel.modules_disabled
After system configuration is complete, set kernel.modules_disabled=1 to prevent loading of additional kernel modules. This prevents attackers from loading malicious kernel modules for rootkit installation. Requires that all needed modules are already loaded; test thoroughly before enabling in production.
Process accounting
Enable process accounting (acct package) to maintain a record of all executed commands for forensic purposes: accton /var/log/pacct. This provides command execution history even without shell history logging.
Audit Logging with auditd
The Linux Audit daemon (auditd) provides fine-grained logging of system events for security monitoring and forensics. Essential audit rules:
Privileged command execution
Log all executions of privileged commands: find / -xdev -perm -4000 -o -perm -2000 to identify SUID/SGID binaries, then add watch rules: -a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged.
File modification monitoring
Monitor critical configuration files: -w /etc/passwd -p wa -k identity, -w /etc/shadow -p wa -k identity, -w /etc/sudoers -p wa -k sudoers, -w /etc/ssh/sshd_config -p wa -k ssh_config.
Authentication events
Log all authentication events: -w /var/log/lastlog -p wa -k logins, -w /var/run/faillock -p wa -k logins. Ensure pam_faillock or pam_tally2 is configured to lock accounts after failed authentication attempts.
System call auditing
Log sensitive system calls: -a always,exit -F arch=b64 -S ptrace -k tracing (detects debugging/injection), -a always,exit -F arch=b64 -S init_module,finit_module -k module_insertion (detects kernel module loading).
Network and Firewall Hardening
Linux firewall configuration is essential for server hardening. Use nftables (modern) or iptables (legacy) to enforce a default-deny inbound policy with explicit allow rules for required services only. A minimal web server example: default DROP for INPUT and FORWARD chains, ACCEPT for established connections (conntrack), ACCEPT for SSH from specific management IP ranges only, ACCEPT for 80/443 from anywhere, DROP everything else. Use firewalld (RHEL/CentOS) or ufw (Ubuntu) as management layers above nftables/iptables for ease of administration. Disable IPv6 if not required (net.ipv6.conf.all.disable_ipv6=1) to reduce attack surface from a less-monitored protocol stack.
Automating Compliance Assessment
Manual hardening is error-prone and difficult to maintain at scale. Automate compliance assessment with: OpenSCAP and the SCAP Security Guide (SSG) provide automated CIS Benchmark and DISA STIG assessment with remediation scripts. Lynis is an open-source hardening auditor that runs locally and generates a prioritized finding list. Chef InSpec, Ansible security roles, and Puppet hardening modules allow infrastructure-as-code hardening that can be applied consistently at provisioning time. CIS-CAT Pro provides official CIS Benchmark assessment with detailed remediation guidance. Run hardening assessment at server provisioning (golden image validation) and on a scheduled basis (monthly at minimum) to detect configuration drift.
The bottom line
Linux hardening is not a one-time project: configuration drift, new services, and package updates continuously change the security posture. Automate baseline hardening into your golden image build process using OpenSCAP or Ansible, enforce mandatory access control (SELinux or AppArmor) without exception, and ship auditd logs to your SIEM from day one. Start with SSH hardening, service reduction, and auditd configuration: these three deliver the most risk reduction per hour of effort.
Frequently asked questions
What is the CIS Benchmark and how do I use it?
The CIS (Center for Internet Security) Benchmark for Linux is a prescriptive configuration guide that documents specific settings for securing Linux systems. It is divided into Level 1 (broad applicability, minimal performance impact) and Level 2 (defense-in-depth for high-security environments, may impact functionality). Download the benchmark for your specific Linux distribution from cisecurity.org. Use OpenSCAP or CIS-CAT to automatically assess your system against the benchmark and generate a compliance report with pass/fail results for each recommendation.
Should we use SELinux or AppArmor?
Use whichever is the default for your distribution and do not switch: SELinux is the default and preferred for RHEL-family systems (RHEL, CentOS, AlmaLinux, Rocky Linux). AppArmor is the default for Debian-family systems (Ubuntu, Debian). Both provide effective mandatory access control when properly configured. The most important thing is running in enforcing/enforce mode, not which system you use. Switching MAC systems requires significant policy work and expertise that is rarely justified.
How do we handle SELinux denials for legitimate applications?
When SELinux blocks a legitimate application operation, the denial is logged to /var/log/audit/audit.log and /var/log/messages. Use audit2why to explain why the denial occurred, and audit2allow to generate a policy module that permits the specific operation. Workflow: ausearch -m avc -ts recent | audit2allow -M my-policy && semodule -i my-policy.pp. Never disable SELinux or set it to permissive mode to resolve application errors: this removes protection for all processes, not just the problematic one. Creating targeted policy exceptions is the correct approach.
What SSH key management practices should we follow at enterprise scale?
Enterprise SSH key management: use a certificate authority (HashiCorp Vault SSH secrets engine, AWS SSM, or Teleport) to issue short-lived SSH certificates rather than managing long-lived authorized_keys files. Short-lived certificates (4 to 8 hour validity) eliminate the authorized_keys sprawl and key rotation challenges that make SSH key management operationally difficult at scale. Audit all authorized_keys files across your fleet quarterly. Remove keys for departed employees immediately. Never allow key forwarding (ForwardAgent no in SSH client config) as it enables attackers to use your keys from a compromised intermediate host.
How do we maintain Linux hardening across a large fleet?
Configuration management tools are essential for hardening at scale: Ansible hardening roles (ansible-lockdown, dev-sec.io Linux baseline), Chef InSpec profiles, and Puppet hardening modules apply consistent configuration across hundreds or thousands of servers. Build hardening into your golden image: create a hardened base image using Packer with an Ansible playbook, then use that image as the base for all new server deployments. Run OpenSCAP or Lynis assessments on a schedule via your configuration management tool and alert on drift from baseline. Treat configuration drift as a security finding requiring remediation, not a normal operational condition.
What is the DISA STIG and how does it differ from CIS Benchmark?
DISA STIGs (Security Technical Implementation Guides) are US Department of Defense hardening standards that are mandatory for federal government systems and defense contractors. They are more prescriptive and restrictive than CIS Benchmarks in some areas and map to specific NIST 800-53 controls for compliance documentation. DISA STIGs are publicly available at public.cyber.mil. For non-government organizations, CIS Benchmarks are generally the preferred reference: they are well-maintained, broadly adopted, and have tooling (OpenSCAP, CIS-CAT) that automates assessment. Government contractors and organizations processing classified information should use STIGs where contractually required.
Sources & references
- CIS Benchmark for Ubuntu Linux 22.04 LTS
- CIS Benchmark for Red Hat Enterprise Linux 9
- NSA Linux Security Technical Implementation Guide (STIG)
- NIST SP 800-123 Guide to General Server Security
- Linux Kernel Security Subsystem Documentation
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.