Does Lynis make any changes to my system?

No. Lynis is read-only. It inspects configuration files, running processes, and kernel parameters but never modifies anything. All remediation is manual and under your control.

Can I run Lynis against a remote server?

Lynis must run locally on the target system because it reads the live filesystem and running state directly. You can SSH into the remote host and run it there, or push it via Ansible and collect the report files centrally.

How do I suppress a finding I have intentionally accepted as a risk?

Copy the default profile to a custom profile, add a `skip-test=TEST-ID` line for each accepted finding, and pass `--profile /etc/lynis/custom.prf` when running the audit. Document the business reason alongside the skip entry.

Is the community edition of Lynis sufficient, or do I need the enterprise version?

The community edition covers hundreds of checks and is sufficient for most environments. The enterprise version (Lynis Enterprise / SIEM integration via CISOfy) adds centralised dashboards, policy enforcement, and compliance reporting across fleets of hosts.

How to Audit Linux Hardening with Lynis

Q: What is a good hardening index score?

There is no universal threshold, but a freshly provisioned server typically scores 50–65. A well-hardened production host should reach 80 or above. Track the trend over time rather than treating any single number as a pass/fail line.

Lynis is an open-source security auditing tool that scans a running Linux system, checks hundreds of controls across hardening categories, and produces a prioritised list of findings. It works agentlessly, reads the live system directly, and requires no database server or agent daemon. A single run gives you a hardening index score and concrete suggestions you can act on immediately.

Installing Lynis

Always prefer the upstream Lynis packages over distribution packages where possible — distro repos frequently lag several versions behind, and new checks matter for accurate results. The CISOfy repository is the recommended source.

Debian and Ubuntu

curl -fsSL https://packages.cisofy.com/keys/cisofy-software-public.key \
  | sudo gpg --dearmor -o /usr/share/keyrings/cisofy-software.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/cisofy-software.gpg] \
https://packages.cisofy.com/community/lynis/deb/ stable main" \
  | sudo tee /etc/apt/sources.list.d/cisofy-lynis.list
sudo apt update && sudo apt install lynis

Fedora, RHEL, Rocky, and AlmaLinux

sudo rpm --import https://packages.cisofy.com/keys/cisofy-software-public.key
sudo tee /etc/yum.repos.d/cisofy-lynis.repo <<'EOF'
[lynis]
name=CISOfy Lynis
baseurl=https://packages.cisofy.com/community/lynis/rpm/
enabled=1
gpgcheck=1
gpgkey=https://packages.cisofy.com/keys/cisofy-software-public.key
EOF
sudo dnf install lynis

Arch Linux

sudo pacman -S lynis

The Arch community package is reasonably current. Check the AUR for the very latest release if the community package lags.

Verify the installation

lynis show version

Output will be similar to 3.1.2. Versions below 3.0 are end-of-life; upgrade before proceeding.

Running a System Audit

Lynis must run as root to read privileged files and return accurate results. Running as a normal user is possible but produces incomplete output.

Full system audit

sudo lynis audit system

The scan takes one to five minutes depending on hardware and installed packages. Output scrolls in real time; the full report is saved to /var/log/lynis.log and a summary to /var/log/lynis-report.dat.

Useful flags

--quick — suppresses pause prompts; useful in automation.
--auditor "Your Name" — embeds an auditor name in the report for team use.
--no-colors — plain text output, easier to redirect to a file.
--tests-from-group malware,authentication — runs only specific test groups when you want targeted results.

sudo lynis audit system --quick --no-colors 2>&1 | tee ~/lynis-$(date +%F).txt

Capturing output like this lets you diff runs over time to confirm that remediations actually stuck.

Reading the Report

The terminal output is divided into colour-coded sections. Each finding carries one of three status markers:

[OK] — control passed, no action needed.
[WARNING] — active problem; fix this first.
[SUGGESTION] — improvement opportunity; lower urgency than warnings.

The hardening index

At the end of the run Lynis prints a summary block. The most important number is the Hardening index, expressed as a value from 0 to 100. A freshly provisioned server with no hardening typically scores in the 50–65 range. A well-hardened production host should reach 80 or above. The score alone is not a security guarantee — it measures coverage of the checks Lynis knows about, not every possible attack surface.

The log and report files

/var/log/lynis.log contains verbose output including every test ID, command executed, and its result. /var/log/lynis-report.dat is a machine-parseable key=value file useful for scripting or feeding into a SIEM.

grep "^warning" /var/log/lynis-report.dat

This extracts every warning line cleanly for scripting or ticketing workflows.

Understanding test IDs

Every Lynis test has a unique ID such as AUTH-9328 or KRNL-6000. The prefix maps to a category: AUTH is authentication, KRNL is kernel, FIRE is firewalling, and so on. Use the ID to look up full remediation notes:

sudo lynis show details AUTH-9328

Prioritising Remediation

Do not try to fix every suggestion in one pass. A sustainable approach works through findings in order of impact.

Step 1 — clear all warnings first

Warnings represent active misconfigurations or missing controls that attackers can exploit today. Common examples include world-writable files, empty root passwords, SSH root login enabled, or no active firewall. Extract the warning list:

grep -E "^\s+- " /var/log/lynis.log | grep -i warning

Step 2 — group suggestions by category

Suggestions are numerous. Group them by test prefix to batch similar work:

grep "Suggestion:" /var/log/lynis.log | sed 's/.*\[/[/' | sort | uniq -c | sort -rn | head -20

If you see ten SSH suggestions, address all SSH hardening in one editor session rather than context-switching repeatedly.

High-value, low-effort wins

Several findings appear on almost every server and have straightforward fixes with meaningful security impact:

SSH hardening — disable root login, enforce key authentication, set MaxAuthTries 3, restrict AllowUsers.
Kernel parameters — enable kernel.dmesg_restrict, net.ipv4.conf.all.rp_filter, and related sysctl values via /etc/sysctl.d/.
Firewall — Lynis checks whether a firewall is active and configured. Enabling ufw, nftables, or firewalld satisfies this immediately.
Automatic updates — install and configure unattended-upgrades (Debian/Ubuntu) or dnf-automatic (Fedora/RHEL).
File integrity monitoring — Lynis strongly recommends a FIM tool such as AIDE or Tripwire; installing either eliminates several suggestions at once.

Automating Periodic Audits

Running Lynis weekly through a systemd timer produces a history you can compare. Create the service and timer unit files:

sudo tee /etc/systemd/system/lynis-audit.service <<'EOF'
[Unit]
Description=Lynis security audit

[Service]
Type=oneshot
ExecStart=/usr/bin/lynis audit system --quick --no-colors
StandardOutput=append:/var/log/lynis-weekly.log
StandardError=append:/var/log/lynis-weekly.log
EOF

sudo tee /etc/systemd/system/lynis-audit.timer <<'EOF'
[Unit]
Description=Run Lynis weekly

[Timer]
OnCalendar=Mon 03:00
Persistent=true

[Install]
WantedBy=timers.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now lynis-audit.timer
systemctl list-timers lynis-audit.timer

Verification

After applying remediations, run the audit again and compare the hardening index. Diff the two output files to confirm regressions have not crept in and that new warnings have not appeared from other system changes:

diff ~/lynis-2025-06-01.txt ~/lynis-2025-06-15.txt | grep -E "^[<>].*WARNING"

Troubleshooting

Lynis reports fewer tests than expected

Running without root skips tests that require reading /etc/shadow, kernel parameters, and process state. Always use sudo for a complete scan.

False positives on hardened systems

Some checks flag controls you have intentionally configured differently — for example, a custom PAM stack or a kernel compiled without a module Lynis expects. You can whitelist specific test IDs in a custom profile:

sudo cp /etc/lynis/default.prf /etc/lynis/custom.prf
# Add to custom.prf:
# skip-test=AUTH-9328
sudo lynis audit system --profile /etc/lynis/custom.prf

Permission denied on log files

If you redirect output to a user-owned file but the log directory is root-only, the write will fail silently. Either run the full command under sudo including the redirection, or write to a path your user owns as shown in the capture example above.