Use CIS Benchmarks to audit and apply hardening safely, starting with disabling SSH root login on a Linux VM.
Why it matters
Fresh installs are built to be easy to use, not to be safe. Default settings often leave unneeded services running, allow weak authentication and keep logging minimal. Hardening is the work of reducing that attack surface with a repeatable, documented configuration. It prevents a huge share of real attacks, and it makes the vulnerability scans from the previous lesson much quieter.
Benchmarks: someone has already written the checklist
You do not have to invent a hardening standard. The Center for Internet Security (CIS) publishes free CIS Benchmarks: consensus configuration guides for operating systems (Ubuntu, Red Hat, Windows, macOS), cloud platforms, databases, browsers and network devices. Download them (free registration) from cisecurity.org/cis-benchmarks. Checked on 2026-10-23.
Other sources: the US DoD STIGs (Security Technical Implementation Guides), and vendor guides such as Microsoft's security baselines.
Each benchmark item (a "recommendation") has the same structure:
- Title, for example "Ensure SSH root login is disabled".
- Profile: Level 1 items are practical and low-impact for most systems; Level 2 items add defence in depth for high-security environments and may break some functionality.
- Rationale: why it matters.
- Audit: the exact command to check the current state.
- Remediation: how to fix it.
- Default value and references.
Worked example: disabling SSH root login
Rationale. If root can log in over SSH, attackers only need to guess one password for an account they know exists, and logs show "root" instead of the real person. Admins should log in as themselves and use sudo.
Audit. Ask the SSH server for its effective configuration (this includes settings from included files):
sudo sshd -T | grep -i permitrootlogin
# permitrootlogin without-password <- default on many distributions: keys allowed, passwords not
# permitrootlogin no <- what the benchmark wants
Remediation. On recent Ubuntu, add a drop-in file rather than editing the main file:
echo "PermitRootLogin no" | sudo tee /etc/ssh/sshd_config.d/60-hardening.conf
sudo sshd -t # test the configuration; no output means OK
sudo systemctl reload ssh # the service is "sshd" on Red Hat-style systems
sudo sshd -T | grep -i permitrootlogin
Two safety habits matter here. First, test with sshd -t before reloading, because a broken configuration can lock you out. Second, keep your current session open and test a new login in another terminal before you disconnect. In a lab VM, take a snapshot first.
Note that OpenSSH uses the first value it reads for most settings, so the drop-in's file name matters: files in sshd_config.d are read in name order, and if another file sets the same option earlier, that one wins. That is exactly why you audit with sshd -T instead of trusting what you typed.
Other common Level 1 items on Linux
| Area | Example recommendation | Quick audit |
|---|---|---|
| Updates | Ensure updates and security patches are installed | apt list --upgradable |
| Services | Ensure unneeded services are not running | systemctl list-units --type=service --state=running |
| Network | Ensure a host firewall is active with default deny inbound | sudo ufw status verbose |
| SSH | Ensure SSH MaxAuthTries is 4 or less | the maxauthtries line of sudo sshd -T |
| Accounts | Ensure no accounts have empty passwords | sudo awk -F: '($2 == "") {print $1}' /etc/shadow |
| Logging | Ensure auditd is installed and enabled | systemctl is-enabled auditd |
| Files | Ensure permissions on /etc/shadow are restrictive | stat -c '%a %U %G' /etc/shadow |
Exact wording and numbering change between benchmark versions, so always work from the version that matches your OS release.
Tooling: measure, then enforce
- Lynis is a free, open-source auditing tool for Linux and macOS.
sudo lynis audit systemprints warnings, suggestions and a hardening index. - CIS-CAT Lite (free) scores a system against selected CIS Benchmarks.
- OpenSCAP can scan and remediate against published profiles on many distributions.
- At scale, teams enforce settings with configuration management (Ansible, Puppet, Group Policy, Intune) or build hardened golden images, so every new server starts compliant. Manual changes on one server drift; code does not.
Exceptions are normal
Some benchmark items will conflict with what a system must do. A file server may need a service a benchmark says to disable. That is fine if it is documented: the item, the reason, the compensating control and an owner who reviews it. Applying every Level 2 item blindly to production is a common way to cause outages.
Common mistakes
- Hardening on production first. Test in a lab or staging system and roll out gradually.
- Locking yourself out. Keep a session open, test new logins, and know how to reach the console.
- One-off manual changes. Put settings in configuration management so they survive rebuilds.
- Treating a score as the goal. A higher Lynis index is nice; closing the paths attackers actually use is the point.
Quick recap
- Hardening reduces the attack surface with a documented, repeatable configuration.
- CIS Benchmarks give per-platform recommendations with rationale, audit and remediation; Level 1 is the practical baseline.
- Audit, change, test and verify: for SSH,
sshd -T, a drop-in file,sshd -t, reload, and a fresh login test. - Measure with Lynis or CIS-CAT Lite, enforce with configuration management, and document exceptions.
Try it
Open the Do tab to audit your lab VM and apply one benchmark item.