🛡️ Auditing Linux Server Hardening with Lynis

Most servers I’m handed have never been audited. They were provisioned, they worked, and nobody looked at them again. So before I change anything, I run Lynis — a single open-source script that walks the whole box and reports, in a couple of minutes, exactly where it’s soft: weak SSH config, missing kernel hardening, world-readable secrets, no audit framework, unowned files, the lot. It’s the fastest way I know to turn “this server is probably fine” into a concrete, prioritized to-do list.

The trap is treating the hardening index it spits out as a score to maximize. It isn’t a leaderboard. It’s a starting point for judgment.

What Lynis is and how to run it

Lynis is a host-based security auditing tool — a shell script with no agent and no dependencies to speak of. It runs locally with root, inspects config files, running services, file permissions, and kernel settings, then emits findings as warnings (act on these) and suggestions (consider these), plus a numeric hardening index.

Install and run:

# Debian/Ubuntu
sudo apt install lynis
# RHEL/Fedora
sudo dnf install lynis
# Or run the latest straight from the repo
git clone https://github.com/CISOfy/lynis && cd lynis

sudo lynis audit system

It scrolls through dozens of categories — bootloader, kernel, users, SSH, firewall, logging, file integrity — color-coding each check. Let it finish and read the summary at the bottom.

Reading the output like an adult

Two files hold the real value after a run:

# Human-readable, every check and its result
sudo less /var/log/lynis.log
# Machine-readable, just the actionable items
sudo grep -E 'warning|suggestion' /var/log/lynis-report.dat

Each finding has an ID like SSH-7408 or KRNL-5820. You can ask Lynis to explain any of them:

lynis show details SSH-7408

The hardening index (say, 64) is a relative measure — useful for tracking whether you’re improving over time, useless as an absolute target. A locked-down internet-facing host and a trusted internal build box have legitimately different right answers. Don’t chase 100. Chase “every warning is either fixed or consciously accepted with a reason written down.”

The findings that actually matter

After hundreds of runs, these are the categories I jump to first:

• SSH (SSH-*) — root login still enabled, password auth on, weak ciphers, no MaxAuthTries. Almost always the highest-leverage fixes on an exposed box.
• Kernel hardening (KRNL-*) — missing sysctl settings like kernel.randomize_va_space, unrestricted dmesg, core dumps enabled. Cheap to fix via /etc/sysctl.d/.
• Authentication (AUTH-*) — no password aging, weak PAM config, accounts with empty passwords, UID 0 accounts other than root.
• Logging & auditing (LOGG-*, ACCT-*) — no auditd, no log forwarding, process accounting off. You can’t investigate what you didn’t record.
• File permissions (FILE-*) — world-writable files, files with no owner, weak permissions on /etc/shadow and friends.

Work warnings before suggestions, and within warnings work the internet-exposed surface (SSH, firewall) before the internal stuff.

Turn findings into fixes

A finding is only useful if it becomes a change. For example, Lynis flags SSH-7408 for hardening options — translate that into actual sshd config:

# /etc/ssh/sshd_config.d/hardening.conf
PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3
X11Forwarding no

And kernel suggestions into a sysctl drop-in:

# /etc/sysctl.d/99-hardening.conf
kernel.randomize_va_space = 2
kernel.dmesg_restrict = 1
net.ipv4.conf.all.rp_filter = 1

Apply, then re-run Lynis and confirm the finding cleared. The audit-fix-reaudit loop is the whole point; a single scan is just a snapshot.

Where AI accelerates the loop

Lynis is excellent at finding problems and deliberately light on fixing them — it tells you “consider hardening SSH” but won’t write your config. That gap is exactly where I use a model. My workflow:

1. Run Lynis, pull the warnings and suggestions from lynis-report.dat.
2. Paste a finding ID and its description and ask for the concrete config change plus an explanation of the tradeoff — because some hardening breaks legitimate workflows and I need to know which.
3. Read the proposed change, apply it deliberately, re-run Lynis to confirm.

The “explain the tradeoff” part is critical. Disabling password auth is great until it locks out the one process that relied on it. A model is good at flagging those consequences before you hit them — but you make the call. Keep a set of Linux hardening prompts for translating findings into reviewed changes.

Automate the scan, not the fixes

Run Lynis on a schedule so drift gets caught, but keep remediation human-reviewed:

# Weekly cron, quiet, report only
0 6 * * 1 /usr/sbin/lynis audit system --cronjob > /var/log/lynis-cron.log 2>&1

Track the hardening index over weeks — a dropping number means someone loosened something, which is a signal worth investigating even if no single finding looks scary.

The honest summary

Lynis is the cheapest security win available on Linux: two minutes gives you a prioritized list of real weaknesses. The discipline is to treat it as a checklist to work through, not a score to game — fix the warnings, consciously accept what you won’t fix, and re-run to confirm. Pair it with a model to turn each finding into a reviewed config change, and you’ll harden a server properly in an afternoon instead of putting it off forever. More security and ops guides live in the AI for Linux Admins series.

Hardening changes can break legitimate functionality. Review each Lynis-driven change for its tradeoffs and test on a non-production host before rolling out broadly.