1. Running Your First Lynis Security Audit
Before you harden anything, you need to know what’s wrong. That’s what a lynis security audit does on first run. It scans your system configuration, checks for known vulnerabilities, reviews file permissions, and inspects running services. The command is simple:
sudo lynis audit systemRun it as root or with sudo. Lynis checks dozens of categories including kernel hardening, file systems, SSH configuration, and firewall rules. It takes about two minutes on a standard server. The output shows suggestions, warnings, and findings grouped by severity.
I run this on every new server I set up. It catches things I’d miss otherwise. Things like weak SSH cipher settings or exposed kernel parameters.
2. Customizing How the Lynis Security Audit Runs
The default scan works well, but you can tune it. Lynis reads a profile file at /etc/lynis/default.prf. Open that file and you’ll find settings for what to scan and how to report results.
You can set a custom admin email address so reports get sent somewhere useful:
[email protected]You can also define which directories to scan and which services to inspect. If your server runs custom applications in non-standard paths, add those paths to the profile. Lynis respects these customizations on every subsequent run.
Setting this up once saves you from passing the same flags every time. Just configure the profile, then run sudo lynis audit system again.
3. Skipping Tests During a Lynis Security Audit
Not every test applies to every system. If you run a Docker container, a test that checks for kernel boot parameters might not matter. Lynis lets you skip specific tests with the --skip-test flag:
sudo lynis audit system --skip-test KRNL-5788You can find test IDs in the report output next to each warning. Each one starts with a category code like KRNL (kernel), SSH- (SSH), or FILE- (file permissions). Accumulating a list of test IDs to skip is common after running a few audits. You know which tests produce noise on your system and which ones matter.
This keeps Lynis output clean and practical. No point reading about kernel hardening on a container that shares the host kernel.
4. Reading the Lynis Security Audit Report
After Lynis finishes, it saves a report file to /var/log/lynis-report.dat. This is a plain text file with structured data about everything it found. You also get a human-readable log at /var/log/lynis.log.
The report file is useful for automation. You can grep it for specific findings or feed it into your monitoring system. The log file is the one to read yourself. It shows each test and its result:
2026-07-16 12:00:01 Performing test KRNL-5788
2026-07-16 12:00:02 Result: hardening suggestion foundIt has a score at the end called the hardening index. It ranges from 0 to 100. A score above 70 is decent. Above 80 is solid. I aim for 85 on public-facing servers.
5. Running a Quick Lynis Security Audit
A full audit runs every test Lynis knows about. That takes time. When I’m iterating on config changes and want fast feedback, I use the quick mode:
sudo lynis audit system --quickQuick mode skips the more time-intensive tests like package database scans and deep file checks. It still covers the critical areas: kernel settings, SSH config, firewall status, and user accounts. The whole thing runs in about 20 seconds instead of two minutes.
Use quick mode during active hardening work. Run the full Lynis audit when you’re done and want the complete picture. This two-step cycle speeds up your workflow without losing thoroughness.
6. Automating the Lynis Security Audit
One-time scans are fine. Regular scans are better. I set up a cron job to run Lynis every night and log the results. Add this to your crontab:
0 2 * * * /usr/bin/lynis audit system --quiet --logfile /var/log/lynis-daily.logThe --quiet flag suppresses output. The --logfile flag writes results to a dedicated file so your daily log doesn’t mix with manual runs. In the morning, I check the hardening index trend. A sudden drop means something changed overnight.
Automating your Lynis scans turns it from a one-off check into continuous monitoring. You catch regressions the same day they happen.
7. Acting on Lynis Security Audit Warnings
Lynis produces three types of findings. Suggestions are recommended improvements. Warnings indicate potential security issues. Findings flag something it couldn’t check due to missing information.
Warnings are the ones to act on first. A typical warning might say your kernel parameters allow IP forwarding when they should not, or that file permissions on /etc/shadow are too open. Each warning comes with a reference URL that explains what to do.
When I run Lynis on a new system, I start by fixing all warnings. Then I move to suggestions. Many warnings resolve in under a minute. Disabling IP forwarding is a single sysctl command. Tightening file permissions is one chmod call.
8. Comparing Lynis Security Audit Results
Lynis reports include a hardening index and a score for each category. You can compare results from different dates to track your progress. The report file contains timestamps and scores for every run.
I keep a spreadsheet of hardening scores across my systems. After each weekly audit, I note the score and any new warnings. Over time, you see which configurations drift and which stay locked down. This is more honest than trusting your memory.
Lynis provides a standardized measurement. The same test runs in the same order every time. Your scores are comparable week to week as long as you use the same profile settings.
9. Combining Lynis Security Audit with Other Security Tools
Lynis is a system-level auditor. It checks your configuration and software setup. It doesn’t scan for vulnerabilities in running services or monitor network traffic. That’s fine. Pair it with tools that cover those gaps.
Fail2ban handles brute force protection on SSH and web services. Trivy scans your containers and filesystems for known CVEs. Lynis checks that both tools are installed and configured correctly during the audit. I use all three together on every server.
A regular Lynis audit plus scheduled Trivy scans plus fail2ban active monitoring covers configuration drift, software vulnerabilities, and attack prevention. No single tool does all of it. But the combination is solid.
10. Penetration Testing with Lynis Security Audit
Before a penetration test, run Lynis. Fix the warnings it finds. A pentester will discover the same issues, and you want to remove the easy wins first. Lynis checks for things like exposed kernel parameters, weak user passwords, and insecure SSH settings. These are the first things an attacker probes.
After the pentest, run Lynis again. Compare the hardening scores. Any new findings after the pentest might be issues the pentester introduced during their testing. It’s a good sanity check.
Using lynis security audit before and after pentesting gives you a baseline that’s hard to argue with. The numbers don’t lie. And when your manager asks what you did to improve security this quarter, showing a hardening index that went from 65 to 82 is a concrete answer.
Lynis is free, open source, and runs on any Linux distribution. Install it from your package manager or grab it from the Lynis GitHub repository. The official documentation covers every test and configuration option in detail. The CISOfy website has guides on hardening and compliance. For more server security guidance, check out our guide on setting up CrowdSec for additional protection.