Linux System Hardening & CIS Benchmarks
Apply CIS Benchmark thinking to a Linux server: SSH hardening, sysctl network hardening, auditd, least-privilege sudoers, and file integrity monitoring.
Learning Objectives
- → Explain what a CIS Benchmark is and how Level 1 vs Level 2 hardening differs
- → Apply core SSH hardening settings (disable root login, key-only auth, restricted access)
- → Reduce attack surface with restrictive sysctl network parameters and fewer running services
- → Configure auditd to monitor security-relevant events
- → Apply least privilege to users, groups, and sudoers configuration
What Is a CIS Benchmark?
The Center for Internet Security (CIS) publishes consensus-driven, vendor-agnostic hardening guides for operating systems, cloud platforms, and applications. Two levels are typically defined:
- Level 1 — practical, minimal usability impact; the safe default baseline for most servers
- Level 2 — defense-in-depth, may reduce compatibility or convenience; used for high-security environments
Tools like CIS-CAT or OpenSCAP audit a running system against a benchmark profile and produce a compliance score — the technical implementation of the audit evidence concept from the GRC lesson.
Reducing Attack Surface
Every unnecessary listening service is more code that needs patching and more surface to monitor. This connects directly to the ss -tulpn skill from the networking lesson: audit what's actually listening, then disable or remove anything unjustified (telnet, rsh, tftp, and unused desktop services like avahi or cups on a headless server are classic examples).
SSH Hardening
Key settings in /etc/ssh/sshd_config:
| Setting | Hardened value | Why |
|---|---|---|
| PermitRootLogin | no | Forces privilege escalation through a named, audited account |
| PasswordAuthentication | no | Key-only auth resists brute force and credential stuffing |
| Protocol | 2 | SSHv1 is cryptographically broken |
| MaxAuthTries | 3–4 | Limits brute-force attempts per connection |
| AllowUsers / AllowGroups | explicit list | Least privilege on who may even attempt to connect |
Always confirm an alternate access path (console, out-of-band management) exists before hardening SSH on a remote-only server — and validate the new config in a second session before closing the first, to avoid locking yourself out.
Kernel Network Hardening with sysctl
| sysctl key | Hardened value | Effect |
|---|---|---|
| net.ipv4.ip_forward | 0 (unless it's a router) | Prevents the box from silently forwarding traffic |
| net.ipv4.conf.all.accept_redirects | 0 | Blocks ICMP redirect attacks |
| net.ipv4.tcp_syncookies | 1 | Mitigates SYN flood denial-of-service |
| net.ipv4.conf.all.rp_filter | 1 | Reverse-path filtering blocks spoofed source IPs |
auditd: Watching What Matters
auditd logs security-relevant syscalls — file access, privilege escalation, configuration changes — independent of application logs. Example rule:
-w /etc/passwd -p wa -k identity
This watches for writes/attribute-changes to /etc/passwd, tagged with the key identity so matches are easy to find later with ausearch -k identity.
Least Privilege: Users, Groups, sudoers
Avoid shared root logins — named accounts plus sudo preserve accountability. sudoers entries should use a Cmnd_Alias to grant exactly the commands needed, not ALL=(ALL) ALL:
Cmnd_Alias APPRESTART = /usr/bin/systemctl restart myapp
dave ALL=(ALL) APPRESTART
This lets dave restart exactly one service, with full sudo logging, and nothing else.
File Integrity Monitoring
Tools like AIDE or Tripwire baseline the cryptographic hashes of critical files and alert when something changes unexpectedly — a detective control, the technical partner to the preventive controls above.
Common Pitfalls
- Hardening SSH before confirming an alternate/out-of-band access path exists — a classic self-lockout
- Blindly running a CIS remediation script without reading it first — some settings break legitimate services
- Treating hardening as a one-time project instead of a recurring benchmark scan against configuration drift
Each sshd_config directive controls one specific aspect of how SSH authenticates and authorizes connections.
Which sshd_config setting, when set to 'no', prevents direct SSH login as the root account?
Each sysctl network parameter defends against a specific class of attack.
Which sysctl value mitigates SYN flood denial-of-service attacks?
CIS Benchmarks define two levels that trade off usability against security rigor.
Which CIS Benchmark level prioritizes minimal usability impact and is the safe default for most servers?
💪 Exercises & Challenges
Linux System Hardening & CIS Benchmarks MCQ
Test your understanding of Linux System Hardening & CIS Benchmarks.
Draft an SSH Hardening Checklist
Write the exact sshd_config key/value pairs you would set to harden a newly-provisioned server, and explain the security reason for each in one sentence. Cover at minimum: root login, password auth, m
Fix the Failed CIS Scan
A CIS Benchmark scan against a freshly-provisioned server flags these findings: 1. PermitRootLogin is set to 'yes' 2. net.ipv4.tcp_syncookies is set to 0 3. A sudoers entry reads `dave ALL=(ALL) ALL`