Securing a Linux server: Part 4 — Auditing and hardening with Lynis

A firewall, Fail2ban and CrowdSec respond to attacks that are already underway. An audit solves a different task: to find weak spots in the server configuration in advance — extra services, permissive SSH settings, incorrect file permissions, lack of updates — and close them before they are exploited. This work is called hardening, strengthening the system. The most common free tool for it is Lynis.

What is Lynis

Lynis is a security scanner for Linux, macOS and BSD from CISOfy. It is distributed under the GPLv3 license, current version — 3.1.7 (25.06.2026). Lynis does not need to be compiled: it is a set of shell scripts that run directly from the directory or are installed as a package.

Lynis does not change anything in the system. It checks kernel settings, bootloader, SSH, users and passwords, installed packages and their updates, file permissions, logging, firewall, network services — and produces a report with found issues and recommendations.

The commercial version, Lynis Enterprise, adds a web interface, reports across multiple servers, remediation plans and compliance checks for standards like PCI DSS and ISO 27001. The free version is enough for one or a few servers.

Installation and run

Lynis is available in the Debian and Ubuntu repositories, but the version there often lags. A fresh version can be installed from the CISOfy repository or simply downloaded from GitHub:

git clone https://github.com/CISOfy/lynis
cd lynis
sudo ./lynis audit system

Run it as root: without privileges Lynis will skip some checks and will warn about it. The audit takes a minute or two.

How to read the result

There are three main things in the output and the report.

Warnings — problems that actually require action. There are usually few of them.

Suggestions — places where the configuration can be improved. There are always noticeably more of these, and not all of them apply to your server.

Hardening index — the final security score. By itself it says little, but it is convenient for comparison: run an audit before and after changes and see how it changed.

Each finding has an identifier, for example SSH-7408. Details for it:

sudo lynis show details SSH-7408

The full audit log is written to /var/log/lynis.log and is overwritten on each run; the machine-readable report is in /var/log/lynis-report.dat.

What to fix first

There can be several dozen suggestions, and you don’t need to fix everything. A sensible order:

1. Warnings. Everything marked as a warning should be addressed immediately.
2. Updates. Packages with known vulnerabilities and lack of automatic security updates are the most common real cause of compromises.
3. SSH. Use key-only login, disable root password login, disable unused authentication methods.
4. Unnecessary services and ports. Stop and disable anything that listens on the network and is not needed. The firewall checks this as well.
5. Users and permissions. Accounts without passwords, excessive sudo privileges, files writable by everyone.
6. Logging. Logs must be written and retained long enough, otherwise after an incident there will be nothing to investigate.

Suggestions that are not applicable to the server (for example, a separate partition for /tmp on a small VPS) can be disabled in a custom profile custom.prf so they don’t obscure the important items.

Automation

A one-off audit is useful, but configurations drift over time: someone opens a port for debugging, installs a package, changes the SSH configuration. Therefore audits should be run regularly.

For scheduled runs Lynis has the --cronjob option: it disables colors and interactive prompts.

# /etc/cron.d/lynis — weekly audit on Mondays at 05:00
0 5 * * 1 root /usr/sbin/lynis audit system --cronjob > /var/log/lynis-weekly.log 2>&1

Then you can send the report by email or collect the hardening index in monitoring to see if it drops sharply.

It’s more convenient to apply fixes not manually on each server but via a configuration management system. For Ansible there is an open collection devsec.hardening from the DevSec project: it applies standard OS and SSH settings. After applying it Lynis shows what remains.

What Lynis is not

• It is not an antivirus or an intrusion detection system: it does not look for ongoing attacks or malicious code.
• It is not an application vulnerability scanner: it will not find bugs in your website’s code.
• A high hardening index does not mean the server is secure: it only shows how closely the configuration matches Lynis’s set of checks.

Common mistakes

• Running without root — some checks are skipped and the report looks better than reality.
• Trying to apply all suggestions blindly, including those that are not applicable — time is wasted and important things get lost.
• Auditing once after setup and never again.
• Applying recommendations without verification — for example, hardening SSH without testing login from a second session can result in losing access.
• The version from the distribution repository being a year or two behind the current one: it lacks the new checks.

Audit is the last layer in this cycle, and it’s better to start it from the basic steps in the checklist Checklist: Bought a VPS — What’s Next? and the article A new server isn’t a blank slate. It’s an unlocked door..