Run a Useful Lynis Security Audit Without Losing the Evidence

You will finish with a repeatable local Lynis audit, a saved report to inspect, and a clear distinction between findings, command failures and missing privileges. These examples use Lynis 3.1.7 from Debian package 3.1.7-100.

Allow 10 to 20 minutes for the first run and review. You need a shell and a machine you are authorised to inspect. Root access is optional, but the manual says it lets Lynis collect more detail. The audit reads configuration, package, boot and logging information, so treat its log and report as sensitive.

1. Check the installed command

Start with read-only checks. This does not require elevated privileges:

$ command -v lynis
/usr/sbin/lynis
$ lynis --version
3.1.7
$ dpkg-query -W -f='${Package} ${Version}\n' lynis
lynis 3.1.7-100

The package version and program version are separate pieces of evidence. Record both in an audit note. Do not assume that a result from another distribution or a newer upstream release has the same tests or defaults.

2. Choose the audit mode

The normal local scan is audit system. It examines the current host and stores details in a log and findings in a report. Run the command as your normal account first when you want a low-impact preview:

$ lynis audit system --no-colors --quick

--quick avoids waiting for input. It does not mean that the scan checks only a small subset of the system. Add sudo when you are authorised to collect the extra root-readable detail:

$ sudo lynis audit system --no-colors --quick

Do not use sudo merely to silence an unfamiliar warning. Compare the unprivileged and privileged reports, and keep the privilege boundary visible in your notes.

For a non-privileged penetration-testing view, the manual provides --pentest. It skips tests that need root, so it is not a replacement for a complete host audit.

3. Make the first run predictable

Colour is useful at a terminal but adds noise to captured output. Use --cronjob for an unattended run because the manual defines it as colour-free, non-interactive and free of pauses:

$ sudo lynis audit system --cronjob

This command can inspect sensitive data and write audit artefacts. Run it only on a host and at a time approved by its owner. Do not upload results as part of a first test. The --upload option is for sending data to a Lynis Enterprise server and is a separate disclosure decision.

If writing a log would be unsafe for a particular diagnostic run, --no-log redirects logging to /dev/null. That also removes useful evidence, and it does not turn the scan into a harmless operation. Prefer keeping the normal log under the host's existing access controls unless you have a specific reason not to.

$ status=$?
$ printf 'lynis exit status: %s\n' "$status"
lynis exit status: 0

Exit status 0 means the program exited normally. The manual also documents 1 for a fatal error, 64 for an unknown or incomplete parameter, 65 for incorrect data, 66 for an inaccessible file or directory, and 78 when warnings or configuration errors are found and error-on-warnings=yes is in effect. A non-zero status is a reason to investigate, not a score for the machine.

4. Inspect the result without changing the host

Keep the original report until you have copied out the findings you need. Do not edit it in place or delete it to make a later scan look cleaner. The manpage identifies /var/log/lynis.log as the default log location; report placement can be controlled explicitly with --report-file.

For a controlled, readable destination, choose a directory you own and pass a new report path:

$ mkdir -p "$HOME/lynis-reports"
$ lynis audit system --no-colors --quick --report-file "$HOME/lynis-reports/$(hostname)-lynis-report.dat"
$ ls -l "$HOME/lynis-reports"
total 4
-rw-r--r-- 1 user user ... host-lynis-report.dat

The file size, owner and exact timestamp will vary. If the scan needs root, create a root-owned destination deliberately and set its permissions before the run, rather than writing a privileged report into a shared directory. A missing or unwritable destination can produce exit status 66.

Use --warnings-only when a scheduled job must show warnings rather than the normal screen output. Use --verbose when troubleshooting missing components. These options change what you see, not the underlying security of the host.

5. Narrow a follow-up scan carefully

A full audit is the best baseline. For a repeatable investigation, --tests accepts specific test IDs, and --tests-from-category or --tests-from-group limits tests by a category or group. The valid category and group names are installation-specific enough that you should discover them on the same host before scripting them:

$ lynis show categories
$ lynis show groups

Use the exact names and quote a multi-value argument as directed by the manual. Do not guess a test ID from a warning title. A narrow scan is useful for confirmation, but it is not evidence that unrelated areas are healthy.

Profiles provide another boundary. Pass --profile /path/to/profile only after reviewing the file and recording the change. A profile can alter what Lynis tests, so compare like with like when tracking changes over time.

6. Diagnose failures before rerunning

If Lynis rejects an option, run its help and compare the spelling with the installed program:

$ lynis show options
--auditor
--cronjob (--cron)
--no-colors
--no-log
--profile
--report-file
--tests
--verbose
--version (-V)

The displayed list can contain more entries than this excerpt. In particular, do not confuse the manpage's --plugin-dir spelling with a locally displayed alias such as --plugindir; use the form accepted by the installed command and keep scripts consistent.

If a privileged scan reports a missing file, permission problem or inaccessible directory, investigate the path and mount state. Do not respond by recursively changing permissions. If a report was written with the wrong ownership, copy it to an approved protected location, then remove only that known file if policy requires it. That removal is irreversible, so preserve evidence first.