Secure a Linux server, the complete path

A Linux server installed with default settings is functional, not secure: over-permissive accounts, SSH open to everyone, no firewall, services running as root without confinement, no usable trail. This part of the Linux path shows how to harden it layer by layer, without breaking production and while keeping a fallback access at every step. It gathers 26 guides spread over 8 layers: identities and sudo, SSH, permissions, firewall, kernel and boot, service confinement with systemd, SELinux and AppArmor, audit logging, then compliance auditing with Lynis, OpenSCAP, CIS and ANSSI. It is also the hands-on foundation of the RHCSA certification. The 15 lessons of the training module are available in English; the other guides are linked in French.

Why harden a Linux server, and against what?

Each hardening setting answers a precise attack technique: it is not a standard's requirement, it is an answer to a known modus operandi. The table below reads from left to right: a situation you may run into, then the mechanism of the path that neutralises it. If a single row speaks to you, start with the matching layer.

Real situation	Answer from the path
An attacker has console access and edits the boot line to get a root shell	GRUB password
A compromised service account attempts an escalation through a setuid binary	hardened sudo, nosuid on mounts
A script dropped into /tmp is executed	noexec on /tmp and /dev/shm
A hacked web service wants to read /etc/shadow or write anywhere	systemd sandboxing, SELinux/AppArmor
A CVE in an unused network protocol (dccp) becomes exploitable	Disabled kernel modules
Source address spoofing on the network	rp_filter and sysctl hardening
After an incident, "who modified this file, with which account?"	auditd
A customer audit requires proof of compliance	Lynis, OpenSCAP, CIS, ANSSI

Swipe to see more

Recommended prerequisites

This path assumes you are comfortable with the basics of the Fundamentals path (users, permissions, services) and with systemd operations. Always work on a test VM or with a fallback access (KVM/IPMI console): a badly set network setting or GRUB password can cut off your access.

The 26 hardening guides, layer by layer

Hardening is built in layers, from identity up to proof. Follow them in the order below for a new server, or pick the missing layer if the rest is already in place. Links marked "in French" lead to guides outside the training module, not yet translated.

Accounts, sudo and authentication

An attacker's first way in is the identities. You start by mastering local accounts, plug in the directory when the fleet grows, then delegate privileges cleanly and strengthen authentication upstream of the login.

Administer users and groups covers creating, managing and auditing local accounts and password policies. When the fleet grows, an LDAP directory with SSSD centralises the accounts: a departure is handled in the directory, not server by server. Delegate privileges with sudo organises everyday delegation, and hardening and logging sudo (in French) goes further: use_pty, session recording with sudoreplay, controlled NOPASSWD and sudoedit, after ANSSI recommendation R44. Finally, PAM (in French) enforces password policies and account lockout before the login even happens.

SSH remote access

SSH is the most exposed service of a server, hence the number one target of brute-force attacks. Hardening it closes the most visible door, and it is the setting with the best effort-to-gain ratio of the whole path.

The guide to harden SSH access (in French) enforces key authentication, forbids root login, restricts the allowed users and the accepted algorithms.

Permissions and file system

Beyond classic rights, you refine permissions with ACLs, you take back control of sensitive files of the system, and you neutralise execution vectors at the level of the mount options.

ACLs go beyond the owner, group, others trio to give fine-grained per-user rights. Harden file permissions and ownership takes back control of sensitive files, setuid binaries and the umask. Harden mount points (in French) sets noexec, nosuid and nodev on /tmp, /dev/shm and the relevant partitions.

Firewall and network exposure

Reducing what is reachable from the network is one of the fastest gains. You first understand the filtering model, then choose your distribution's tool, and if needed go down to nftables, the common engine.

The introduction to firewalls explains the netfilter model before any choice of tool. Then come the two distribution tools: firewalld, the zone-based firewall of RHEL and Rocky with its rich rules, and UFW, the simple firewall of Debian and Ubuntu. nftables shows the common engine underneath, and NAT and port forwarding turns a server into a gateway without opening more than the required port.

Kernel, modules and boot

Hardening goes all the way down to the kernel and the boot: you tune the parameters of the network and memory stack, remove unneeded modules, can recompile with the KSPP options, and protect the boot loader.

Harden the kernel with sysctl tunes ASLR, ptrace, rp_filter anti-spoofing and ICMP redirects. Disable kernel modules (in French) neutralises rare file systems and protocols. Build a KSPP-hardened kernel (in French) recompiles the distribution kernel, as .deb or .rpm, for compile-time protections. Protect GRUB with a password prevents editing boot entries without blocking the boot.

Confine services

A compromised service must not be able to touch the rest of the system. Three isolation mechanisms, from the simplest to the strictest: the sandboxing options of a systemd unit, then the mandatory access control (MAC) of your distribution.

systemd sandboxing (in French) confines a unit with ProtectSystem or SystemCallFilter, and measures the gain with systemd-analyze security. Mandatory access control then depends on the distribution: SELinux on RHEL and Rocky, with its modes, contexts and troubleshooting, AppArmor on Debian and Ubuntu, with its per-application profiles.

Logging and traceability

Hardening is not enough: you must keep a resilient trail of what happens, to detect during the incident and to investigate afterwards. It is the layer you regret not having set up the day the question "who did this?" comes up, and auditd is its tool.

The guide to log and trace with auditd (in French) traces at kernel level the access to sensitive files, the use of sudo and the loading of modules: who, what, with which account.

Audit and compliance

Finally, you measure and prove the hardening with two audit tools and the two reference frameworks. This is what turns invisible work into a document you can present to a customer or an auditor.

Lynis (in French) scans a server's hardening and prioritises the gaps, systemd services included. OpenSCAP (in French) assesses compliance with a CIS or ANSSI profile and produces a usable report. On the framework side, the CIS Benchmarks (in French) apply by L1 or L2 level, and ANSSI-BP-028 (in French), the French framework, organises the 80 recommendations of its version 2.0 by requirement level.

SELinux or AppArmor, firewalld or UFW: what does the distribution change?

Only two building blocks differ depending on the distribution family, the mandatory access control and the firewall; the rest of the path is common. Better to decide from the start, because going back on these two choices is costly.

• Mandatory access control: SELinux is native and enabled by default on RHEL, Rocky and AlmaLinux; AppArmor is the standard on Debian and Ubuntu. You do not run both.
• Firewall: firewalld (zone-based filtering) on the RHEL side, UFW (simple rules) on the Debian/Ubuntu side. Both drive nftables underneath, which explains why a rule set by one is visible in nft list ruleset.

Everything else (accounts, sudo, SSH, sysctl, kernel modules, GRUB, systemd, auditd, Lynis) is common to all distributions, sometimes with a command that changes, such as apt versus dnf or update-grub versus grub2-mkconfig.

In what order should you harden a new Linux server?

The safe order starts with identities and ends with measurement: identities, remote access, surface reduction, confinement, traceability, measurement. It maximises the security gained at each step while minimising the risk of locking yourself out. Always keep a root session open during network and SSH changes.

1. Identities first: clean accounts, hardened sudo, PAM. It is risk-free and it closes the main door.

2. Remote access: harden SSH (keys, no root), then set up the firewall while keeping the SSH port open.

3. Surface reduction: mount options, kernel modules, sysctl parameters. Test connectivity after each network setting.

4. Confinement: enable SELinux or AppArmor depending on the distribution, then harden the exposed services with systemd sandboxing.

5. Traceability and boot: deploy auditd, protect GRUB.

6. Measurement: run Lynis or OpenSCAP, fix the gaps, and align with CIS or ANSSI depending on your requirement.

Which principles make hardening hold over time?

Four principles are enough, and they apply whatever the distribution: least privilege, defence in depth, a prepared rollback, proof rather than intuition. They explain most of the choices made in the guides above.

• Least privilege everywhere: each account, service and rule only has what it strictly needs. One (root) or ALL too many in /etc/sudoers is a debt.
• Defence in depth: no layer is enough on its own. A service behind a firewall, confined by systemd and by SELinux survives the failure of one layer.
• Always a rollback: before each setting that can lock you out (SSH, firewall, GRUB, mounts), keep a fallback access and know how to go back.
• Prove, do not assume: a Lynis score or an OpenSCAP report beats an intuition. But a high score is not absolute proof: the value lies in the relevant settings, not in the number.

How do you validate what you have hardened?

Validation happens on a disposable VM, by measuring before and after with a Lynis audit. This part is aligned with the identities, permissions and security block of the Linux path, and with the RHCSA specifics that are SELinux, firewalld and recovery mode.

The method has three stages. You run a Lynis audit on a freshly installed machine and note its starting score. You then apply the guides of this part, checking each setting with the control command the guide gives, sestatus, firewall-cmd --list-all or systemd-analyze security depending on the layer. Finally you run the audit again and compare. A server you know how to harden, audit and restore is a server you master; the three verbs matter, and the third is the one people forget.

Key points

• A default server is functional but not secure: hardening is done in layers, here 26 guides spread over 8 layers
• The safe order: identities → remote access → surface → confinement → traceability → measurement
• Always a fallback access before settings that can lock you out (SSH, firewall, GRUB)
• Least privilege and defence in depth are the two common threads
• SELinux on the RHEL side, AppArmor on the Debian/Ubuntu side: choose according to the distribution
• Lynis, OpenSCAP, CIS, ANSSI turn hardening into auditable proof

×

See in the glossary →