Every Linux server you deploy ships with a default configuration designed for compatibility, not security. Root login over SSH, weak password policies, unnecessary services running, and missing audit logging are the norm out of the box — on Ubuntu, Debian, RHEL, and CentOS alike. Attackers know this, and automated scanners probe for exactly these gaps within minutes of a server going live. It’s a reminder that the server you don’t think about is often the first one attackers find.
The good news: you don’t need an expensive GRC platform or a paid vulnerability scanner to fix this. The Center for Internet Security (CIS) publishes free, vendor-neutral hardening benchmarks for every major Linux distribution, and Lynis — a free, open-source auditing tool — can scan your system against hundreds of security controls in under two minutes.
This guide walks you through installing Lynis, running your first Lynis audit, interpreting the results against CIS Benchmark controls, and fixing the ten findings that show up most often on unhardened servers. By the end, you’ll have a repeatable Linux server hardening checklist you can run on every server you manage — and a measurable hardening score to prove progress to management or auditors. If you’re still building core Linux fundamentals before tackling hardening, it’s worth taking the time to get better at Linux first.
What CIS Benchmarks Actually Are
CIS Benchmarks are consensus-based configuration guides, developed by a community of security practitioners and published by the Center for Internet Security. They exist for operating systems, cloud platforms, databases, and more — including dedicated benchmarks for Ubuntu, RHEL, CentOS, Debian, and Amazon Linux.
Each benchmark organizes controls into numbered sections (typically: Initial Setup, Services, Network Configuration, Logging and Auditing, Access/Authentication/Authorization, and System Maintenance), and defines two profile levels:
- Level 1 — baseline hardening with minimal impact on functionality. Safe for almost any server.
- Level 2 — defense-in-depth hardening intended for high-security environments. Can affect functionality or usability, so it requires testing before production rollout.
The PDFs are free to download after creating a free CIS WorkBench account at cisecurity.org. You don’t need a paid membership to read and apply them — the paid tier (CIS SecureSuite) adds automated scanning and compliance reporting (CIS-CAT Pro), which most SMBs don’t need to get started.
What Lynis Does
Lynis, maintained by CISOfy, is a free, open-source security auditing tool for Linux, macOS, and Unix systems. It runs as a shell script with no agent and no external dependencies, performs several hundred checks across categories like authentication, SSH configuration, firewall status, kernel hardening, logging, file permissions, and installed packages, and outputs a hardening index — a single score from 0–100 that gives you a baseline and a way to track improvement over time.
Lynis is not an official CIS-certified scanning tool, and it doesn’t map one-to-one with every CIS control. What it does well is surface the real-world misconfigurations that CIS Benchmarks also target, using plain-English warnings and suggestions instead of requiring you to manually read a 400-page PDF. Think of it as a fast first pass that tells you where to focus your CIS Benchmark work.
Step 1: Install Lynis on Linux
On Debian/Ubuntu, Lynis is available in the default repositories, though the packaged version may lag behind the latest release:
sudo apt update
sudo apt install lynisOn RHEL/CentOS/Rocky, install via EPEL:
sudo dnf install epel-release
sudo dnf install lynisFor the latest version on any distribution, clone directly from the official GitHub repository instead:
git clone https://github.com/CISOfy/lynis
cd lynisVerify the version after installation:
lynis show versionStep 2: Run Your First Lynis Audit
From inside the Lynis directory (or anywhere, if installed via package manager), run:
sudo lynis audit systemThis takes 60–120 seconds on most servers. Lynis will print results live to the terminal, organized by test category (AUTH, SSH, FIRE, KRNL, NETW, LOGG, PKGS, and more), and finish with:
- A hardening index (e.g., "Hardening index: 62 [###############–––––––––––]")
- A list of warnings (issues that need attention)
- A list of suggestions (lower-priority improvements)
Full details are written to /var/log/lynis.log, and a machine-readable report is saved to /var/log/lynis-report.dat — useful if you want to script trend tracking later.
A freshly installed, unhardened server typically scores somewhere in the 50–65 range. Treat this as your baseline, not a verdict.
Step 3: Map Findings to CIS Benchmark Sections
Open the Lynis output alongside the relevant CIS Benchmark PDF for your distribution (e.g., "CIS Ubuntu Linux 22.04 LTS Benchmark"). Most Lynis warnings correspond directly to a CIS section:
| Lynis Category | CIS Benchmark Section |
|—|—|
| AUTH / password policy | Section 5 — Access, Authentication, Authorization |
| SSH | Section 5.2 — SSH Server Configuration |
| FIRE (firewall) | Section 3 — Network Configuration |
| KRNL (kernel/sysctl) | Section 3 — Network Parameters (Host/Kernel) |
| LOGG (logging/auditd) | Section 4 — Logging and Auditing |
| PKGS (updates) | Section 1 — Initial Setup / System Maintenance |
This mapping lets you prioritize: fix what Lynis flags first, then use the CIS PDF to confirm you’ve covered the full control and haven’t missed related sub-items Lynis doesn’t check.
Step 4: Fix the Top 10 Linux Hardening Findings
These are the issues that appear on nearly every unhardened Linux server. Each includes the fix and which CIS section it supports.
1. SSH root login and weak settings (CIS 5.2)
Edit /etc/ssh/sshd_config:
PermitRootLogin no
PasswordAuthentication no
Protocol 2
MaxAuthTries 4Restart SSH: sudo systemctl restart sshd. Confirm you have key-based access working *before* disabling password auth, or you’ll lock yourself out. For a deeper, dedicated walkthrough of every CIS SSH control, see our guide to hardening SSH on Linux servers.
2. No active firewall (CIS Section 3)
Enable a default-deny firewall:
sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw enableOn RHEL-based systems, use firewalld with firewall-cmd instead. If you want to see exactly what an open port exposes to an attacker, our guide on port scanning explains what security teams discover before attackers do.
3. Auditd not installed/enabled (CIS Section 4)
sudo apt install auditd audispd-plugins
sudo systemctl enable --now auditdThis gives you tamper-evident logging of security-relevant events — a requirement in most compliance frameworks, not just CIS.
4. Weak file permissions on sensitive files (CIS Section 6)
Check and correct:
sudo chmod 644 /etc/passwd
sudo chmod 000 /etc/shadow
sudo chmod 644 /etc/groupLynis flags world-writable files and incorrect ownership separately — review each one; don’t blanket-apply permissions without checking what depends on them.
5. No password aging policy (CIS 5.4)
Edit /etc/login.defs:
PASS_MAX_DAYS 365
PASS_MIN_DAYS 1
PASS_WARN_AGE 7Apply to existing users with chage as needed.
6. Kernel/network parameters not hardened (CIS Section 3)
Add to /etc/sysctl.d/99-hardening.conf:
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
kernel.randomize_va_space = 2Apply with sudo sysctl --system.
7. AppArmor or SELinux not enforcing
Ubuntu: sudo aa-status should show profiles in enforce mode. RHEL: sestatus should show "Enforcing." If disabled, re-enabling after the fact requires relabeling the filesystem — plan a maintenance window.
8. Legacy/unused services still running (CIS Section 2)
Check for telnet, rsh, NIS, or FTP daemons:
sudo systemctl list-units --type=service --state=runningDisable and remove anything not explicitly required.
9. No automatic security updates (CIS Section 1)
Debian/Ubuntu: sudo apt install unattended-upgrades and enable it. RHEL: sudo dnf install dnf-automatic and enable the timer.
10. No centralized/forwarded logging (CIS Section 4)
Configure rsyslog or journald to forward logs to a central server or SIEM. A compromised server’s local logs can’t be trusted as evidence — off-box logging is non-negotiable for incident response.
Step 5: Re-Audit with Lynis and Track Your Hardening Index
After applying fixes, run Lynis again:
sudo lynis audit systemCompare the new hardening index to your baseline. A server that started at 58 commonly reaches 80–85 after addressing the ten items above. Save each report (lynis-report.dat) with a date stamp so you can show auditors or management a trend line, not just a snapshot.
For ongoing use, schedule Lynis as a weekly cron job:
0 3 * * 1 /usr/sbin/lynis audit system --cronjob > /var/log/lynis-cron.logReview the log weekly, and treat any drop in the hardening index as a signal that a recent change introduced a regression. Once hardening is in place, pair it with an internal vulnerability assessment to validate that the fixes hold up against real attack techniques.
Common Mistakes and Misconceptions
Treating the Lynis score as proof of CIS compliance. Lynis is not a CIS-certified scanner. A high hardening index means you’ve fixed what Lynis checks — it does not mean you’ve achieved full CIS Benchmark compliance. Use the PDF as the source of truth; use Lynis as the fast triage tool.
Applying Level 2 controls directly to production. Level 2 CIS controls can break applications (e.g., disabling USB storage, restrictive SSH ciphers that older clients can’t negotiate). Always test Level 2 changes in staging first.
Fixing warnings but ignoring suggestions. Suggestions are lower severity, but many map to real CIS controls auditors will check. Don’t dismiss them by default — triage them.
Running the audit once and never again. Hardening isn’t a one-time project. Every patch, new package, or config change can reintroduce a finding Lynis already cleared.
Disabling password auth before confirming key-based SSH access works. This is the single most common way admins lock themselves out of a remote server during hardening.
FAQ
Is Lynis the same thing as CIS-CAT?
No. CIS-CAT Pro is CIS’s own official scanning tool, tied to specific benchmark profiles, and requires a paid CIS SecureSuite membership for most use cases. Lynis is an independent, free, open-source tool that covers overlapping but not identical ground. Use Lynis for ongoing self-assessment; use the CIS Benchmark PDF directly if you need to prove formal compliance.
Will hardening break my applications?
Possibly, especially with Level 2 CIS controls. Always apply changes in a staging environment first, and re-test application functionality after each change before rolling out to production.
How often should I run a Lynis audit?
At minimum, monthly — and immediately after any major configuration change, OS upgrade, or before a compliance audit. Weekly via cron is a reasonable default for production servers.
Does Lynis fix issues automatically?
No. Lynis only detects and reports. Remediation is manual, though you can script fixes with configuration management tools like Ansible once you’ve validated them on one server.
Is this really free, or is there a catch?
The Lynis core tool and the CIS Benchmark PDFs are genuinely free. CISOfy sells Lynis Enterprise (centralized dashboards, compliance reporting) and CIS sells SecureSuite (CIS-CAT Pro, automated compliance mapping) for organizations that need automation at scale — but neither is required to harden a server using the steps above.
Free Resources
- CIS Benchmarks — Official, free-to-download hardening benchmarks for every major Linux distribution (requires a free CIS WorkBench account).
- Lynis on GitHub — Official source code, latest releases, and issue tracker for the Lynis auditing tool.
- Lynis Documentation (CISOfy) — Official product page with usage guides and plugin documentation.
- OpenSCAP — Free, open-source framework for automated compliance scanning against SCAP-based security policies, including CIS profiles.
- NIST National Checklist Program — U.S. government repository of free security configuration checklists, including CIS-aligned baselines.
Conclusion
Hardening a Linux server doesn’t require a budget — it requires a process. Install Lynis, run a baseline audit, map the warnings to the relevant CIS Benchmark section, fix the top ten findings covered here, and re-audit to confirm improvement. Schedule it weekly, and you’ve turned a one-time cleanup into a continuous control that strengthens your security posture with every run.
Next step: run sudo lynis audit system on one server today, record the hardening index, and fix the three highest-severity warnings before end of week. That’s a concrete, measurable result you can report — no budget approval needed.