Lynis · hardening index

Raising your Lynis hardening index: what actually moves the score

2026-07-19 · HardStacked · 7 min read

You spent the afternoon hardening a server. New sysctl keys, auditd, a legal banner, AIDE. You run lynis audit system again and the index moved by two points. Nothing about that number is obvious: some heavy work earns nothing, and one apt habit quietly costs more than most fixes earn.

In July 2026 we measured a full climb, fix by fix, on throwaway VMs and a cloud VPS, then read the Lynis source to understand the surprises. Here is what actually moves the score, and what does not.

1. The biggest lever is a penalty you avoid, not a point you earn

The largest single hit in the whole test suite is PKGS-7392: pending security updates. In the source it is AddHP 0 25, twenty-five points added to the denominator in one line. You cannot earn anything here. A patched system skips the test entirely; an unpatched one takes the full hit.

The cruel part is that apt can tell you the system is up to date while the penalty still applies. Updates that need to add or remove a package are « kept back » by apt upgrade. Measured on our box, July 19, 2026:

$ /usr/lib/update-notifier/apt-check --human-readable 13 packages can be updated. 11 of these updates are security updates. ← Lynis sees these $ sudo apt-get upgrade --dry-run | grep -c '^Inst' 0 ← "nothing to do", says apt upgrade. The 11 are kept back.

On that machine, being fully patched was worth four index points on its own, more than any single package we installed.

The habit

sudo apt full-upgrade instead of upgrade, and read the plan it proposes before saying yes (it may add or remove packages, that is the point). Then reboot if /var/run/reboot-required exists: a kernel updated on disk but not loaded is another penalty (KRNL-5830). Patch, reboot, then scan.

2. Installing a security tool earns you (almost) nothing

On a fresh Debian 13 VM we stacked 18 common hardening fixes one at a time and measured after each. Ten of the eighteen moved the score by exactly zero. The pattern behind most of them: Lynis does not credit the presence of a tool, it checks whether the tool is actually doing its job.

auditd installed, enabled, running: zero. And an empty ruleset is penalized on top (auditctl -l returning nothing is what the test greps for).
AIDE installed without initializing its database made the report worse: Lynis raised a new warning about the missing database. We added a security tool and degraded the audit.
The legal banner is graded by keyword count. Lynis greps /etc/issue against a fixed word list and wants five or more hits. Our first banner had four. Zero credit, one word short.

The habit

Re-scan after every change and read the delta. applied is not credited:

$ sudo lynis audit system --quick >/dev/null $ grep '^hardening_index' /var/log/lynis-report.dat hardening_index=79 ← the only number that counts, before and after each fix

3. The scoring is binary where you expect proportional

We compared against a reference system running AppArmor with 26 profiles in enforce mode. Its MAC score is identical to one single loaded profile: the test only checks that aa-status exits cleanly. All the profile work counts for nothing extra.

It cuts the other way too. Separate partitions for /home, /tmp and /var look like ten points each in the source. Read the failure branch: a non-partitioned system already gets nine of the ten. The real delta is one point per mount, for a change you cannot undo on a VPS.

The habit

Before copying config from a high-scoring system, read what the test actually checks (include/tests_* in the Lynis source), both branches. The condition is often far weaker than what the reference system exhibits, and occasionally the expensive change you are considering is worth almost nothing.

4. SSH is the heaviest test, and it is all or nothing

SSH-7408 judges around nineteen sshd_config directives (X11Forwarding, MaxAuthTries, ClientAliveInterval, AllowTcpForwarding, LoginGraceTime…), each worth points. It weighs more than any other single area. But harden two or three options and you get zero: we measured both halves of a partial SSH hardening at +0. The block scores as a block.

The habit

Push the complete SSH block as one reviewed change, then sshd -t, then test from a second terminal with your current session still open. Editing that many directives at once is exactly how people lock themselves out; we wrote about the five classic SSH lock-outs and the habits that make them survivable.

5. Fixing suggestions does not move the index

Many Lynis tests emit a suggestion with no points attached. We resolved seven findings in one pass: index unchanged. Another pass, two more suggestions gone: unchanged again. The suggestion list and the score are two different instruments.

Points do not add up either. Our fixes measured in isolation summed to +14; stacked on the same system they gained +11. Several fixes compete for the same point, so a « module by module » estimate always overpromises.

The habit

Treat the index as a regression detector, not a to-do list. The suggestion list tells you what to look at; only a measured before/after tells you what a change was worth.

The four rules of an honest climb

Pin your Lynis version. We measured the same unchanged system at 21 points apart between Lynis 3.1.4 and 3.1.7. A score without its auditor's version is meaningless.
Measure the delta after every change. grep '^hardening_index' /var/log/lynis-report.dat. A fix that reports success may credit nothing.
full-upgrade, reboot, then scan. Otherwise the two biggest penalties in the suite sit on top of everything your config work earns.
The score is a thermometer, not the treatment. Our most security-relevant changes (key-only SSH auth, password quality rules) measured +0. Chase posture; use the number to catch regressions.

What a real climb looks like

Measured July 18–19, 2026, on an Ubuntu 24.04 x86 cloud VPS with Lynis 3.1.7 pinned: baseline 57, then 79 after 32 reviewed fixes, then back to exactly 57 after reverting every one of them. The day before, a fresh Debian 13 VM went 64 to 75 with a smaller set. Different distro, different baseline, same lessons: the points live in a few heavy tests, the state of your packages, and completed blocks, not in the number of tools installed.

The deeper lesson

Climbing by hand means days of scan, change, re-scan, and a growing pile of edits you would have to undo by memory. The two habits that matter, measuring every delta and preparing the way back before each change, are exactly the ones manual work skips at 2 a.m.

That loop is what HardVps automates: the 57 → 79 path above is its measured demo, every fix is applied with the original captured first, every restored file is verified byte-exact by SHA-256, and the risky fixes are opt-in behind an explicit warning.

See what HardVps does →

On a Raspberry Pi? Start free with audit-pi, our open-source security audit.