Best practices
Linux server hardening in 2026: the CIS checklist explained
The 20 CIS controls that really matter, how to verify them automatically and what evidence to keep for audit.
Published · Updated · 5 min read
Key takeaways
- CIS Benchmarks are consensus-based configuration guides with a Level 1 profile (baseline, low impact) and a Level 2 profile (defence in depth).
- Around 20 controls — SSH, firewall, updates, logging, permissions, sysctl — cover most of the practical risk.
- Verification has to be automated and repeated: a scan done once proves nothing six months later.
- For audit, dated reports, justified exceptions and change records matter more than the score.
- CIS hardening maps directly onto NIS2 Art. 21(2) and ISO 27001:2022 A.8.9 (configuration management).
What CIS Benchmarks are and what Level 1 vs. Level 2 means
CIS Benchmarks are secure configuration guides published by the Center for Internet Security and built by consensus among practitioners. There are separate benchmarks for Ubuntu, Debian, Red Hat Enterprise Linux and its derivatives (Rocky, AlmaLinux), each with hundreds of numbered recommendations, including the risk explanation, the audit command and the remediation command.
Recommendations are grouped into profiles. Level 1 is the baseline: low-impact controls that almost any server can apply. Level 2 adds defence in depth — for example separate partitions for logs or stricter audit rules — at the risk of affecting some applications. For most organisations the realistic target is full Level 1 on every server and Level 2 on exposed or critical ones.
Checklist: the 20 CIS controls that really matter
The list below does not replace the official benchmark for your distribution, but it gathers the controls that, in practice, shrink the attack surface the most:
| # | Control | Why it matters |
|---|---|---|
| 1 | /tmp on a separate partition mounted nodev,nosuid,noexec | Blocks execution from the payloads' favourite directory |
| 2 | Unused filesystems disabled (e.g. cramfs, udf) | Less kernel code exposed |
| 3 | Unused services stopped and removed | Every open port is a door |
| 4 | Legacy clients removed: telnet, rsh, talk | Cleartext protocols with no justification today |
| 5 | Automatic security updates | Most exploits target vulnerabilities that are already fixed |
| 6 | SSH: PermitRootLogin no | The attacker must guess the user name too |
| 7 | SSH: key authentication, PasswordAuthentication no | Eliminates password brute force |
| 8 | Firewall with default-deny policy | Only what is explicitly allowed reaches services |
| 9 | auditd running, with rules for identity, sudo and kernel modules | Traceability for investigations |
| 10 | Time synchronisation (chrony or systemd-timesyncd) | Without correct time, logs cannot be correlated |
| 11 | Logs forwarded to a central server | An attacker with root deletes local logs |
| 12 | Strict permissions on /etc/passwd, /etc/shadow, /etc/group | Protects password hashes |
| 13 | Logging of sudo commands | You know who did what with privileges |
| 14 | AppArmor or SELinux in enforcing mode | Limits what a compromised process can do |
| 15 | net.ipv4.conf.all.rp_filter = 1 | Drops packets with spoofed sources |
| 16 | ICMP redirects disabled (accept_redirects = 0) | Stops an on-network attacker from rerouting traffic |
| 17 | net.ipv4.tcp_syncookies = 1 | Resilience against SYN floods |
| 18 | Password and lockout policy via PAM | Limits guessing of local passwords |
| 19 | cron and at restricted to authorised users | Persistence via cron is a classic technique |
| 20 | Unowned files and SUID/SGID binaries inventoried | Privilege escalation often starts here |
SSH, firewall and network: where most servers are lost
If you only have time for one thing today, start with remote access. A minimally hardened sshd_config contains PermitRootLogin no, PasswordAuthentication no, a low MaxAuthTries and, where possible, AllowGroups limited to an admin group. Validate the configuration with sshd -t before restarting and keep a session open while you test — a misconfigured SSH can lock you out.
The firewall should start from default deny inbound and explicitly allow only the ports you need, ideally with SSH reachable only from the management network. The sysctl parameters in the checklist (rp_filter, ICMP redirects, syncookies) belong in a file under /etc/sysctl.d/ so they survive a reboot.
Logging, auditd and time synchronisation
Hardening is not only prevention. When something gets through, the question becomes “what happened and when”, and the answer depends on three controls that look boring: auditd with rules for identity changes, sudo usage and kernel module loading; time synchronisation, without which you cannot correlate logs across servers; and log forwarding to a central system, where an attacker with root on one server can no longer delete them.
For organisations in NIS2 scope these logs are not optional: without them you cannot reconstruct an incident for the final report to the authority. See also the step-by-step DNSC notification.
How to verify automatically: CIS-CAT, OpenSCAP and Lynis
Applied by hand, a benchmark of several hundred recommendations degrades within months: a new package, a hurried admin, an old image. That is why verification has to be automated and scheduled. Three tools are widely used:
- CIS-CAT — the CIS tool that assesses directly against the benchmark; there is a free Lite edition and a Pro edition for CIS SecureSuite members.
- OpenSCAP with the SCAP Security Guide content — open source, with CIS-aligned profiles for several distributions. List the available profiles with
oscap infoon the content file and run the assessment withoscap xccdf eval, which produces an HTML report and XML results. - Lynis — a general security audit (
lynis audit system), useful for a first picture and for suggestions, but not a formal CIS assessment.
Whatever the tool, run scans on a schedule (for example weekly and after every major change), keep the results and watch the trend: a control that flips from “pass” to “fail” is an event to investigate.
What evidence to keep for NIS2 and ISO 27001 audits
An auditor does not want to see a server, they want to see a process. Secure configuration maps onto NIS2 Art. 21(2) point (e) — security in the acquisition, development and maintenance of systems — and point (i) — access control and asset management — as well as ISO 27001:2022 control A.8.9 (configuration management). The minimum file:
- The declared standard: which benchmark, which version and which profile you apply, to which server categories.
- Dated scan reports for every server, kept for the period set in your retention policy.
- The exception register: every control not applied, with justification, residual risk, who approved it and when it is reviewed.
- Change records linking remediations to tickets or commits.
- The asset inventory, so you can show that scanning covers every server, not just the ones you remember.
For the full picture of the technical controls the directive requires, see NIS2 Art. 21: the technical controls.
Common mistakes when applying the benchmark
- Applying Level 2 straight to production without testing. Controls such as
noexecon certain partitions can break legitimate installers or applications. - Automatic remediation without review. Remediation scripts are useful, but they must run on a test environment first, for every server image.
- Undocumented exceptions. A control disabled “temporarily” two years ago, with no justification, is an audit finding.
- Hardening only at install time. Without periodic scanning, configuration drift is guaranteed.
Frequently asked questions
+What is the difference between CIS Level 1 and Level 2?
Level 1 contains baseline controls with low impact on functionality, suitable for almost any server. Level 2 adds stricter defence-in-depth measures that may affect some applications and is usually applied to critical or exposed systems.
+Is a CIS Benchmark mandatory for NIS2?
NIS2 does not mandate a specific configuration standard; it requires appropriate risk-management measures. CIS Benchmarks are a recognised, easy-to-demonstrate reference, which is why they are often chosen as the internal standard.
+Which free tool can I use for verification?
OpenSCAP with the SCAP Security Guide provides CIS-aligned profiles for several distributions, and CIS-CAT Lite is the free edition of the CIS tool. Lynis is useful for a general audit but is not a formal CIS assessment.
+How often should servers be scanned?
There is no mandated frequency. In practice, a scheduled weekly scan plus one after every major change catches configuration drift quickly enough and produces continuous audit evidence.
+Can I reach 100% CIS compliance?
It rarely makes sense. Some controls conflict with your applications. What matters is that every deviation is a documented, approved exception that is reviewed periodically.
Official sources
Want to see how this looks in the platform?
Defneo collects NIS2 and AI Act evidence from the systems already running. Start with the free Community Edition or ask for a demo.
This article is for information only and is not legal advice.
Related articles
- NIS2NIS2 Art. 21: the 10 measures, translated into technical controlsWhat “risk management”, “supply chain security” or “cyber hygiene” concretely mean on a real server — measure by measure, with the evidence you should keep.
- Best practicesCrowdSec + Traefik: IDS/IPS for web apps, no applianceFull configuration, detection scenarios, community blocklists and how to avoid false positives.
- ThreatsAnatomy of a ransomware attack in Romania: from VPN to ransomA stage-by-stage reconstruction of a typical attack, built from public patterns, and the 4 controls that would have stopped it.