Lynis Hardening Checklist: What to Fix First on a Linux Home Server

Running Lynis on a Linux home server is easy. Knowing what to fix first is the useful part.

Last updated: May 27, 2026

You run one command, wait a little, and suddenly your server has a hardening score, warnings, suggestions, and a long list of things you probably ignored for too long.

That is exactly why Lynis is useful.

It is also why you should not treat the report like a checklist that must be fixed blindly in one evening.

This post is a practical Lynis hardening checklist for Linux home servers. It is written for small homelabs, old desktops, mini PCs, laptops used as servers, cheap VPS boxes and Docker hosts running useful services at home.

The goal is not to get a perfect Lynis score. The goal is to understand what matters, fix the high-value issues first, and avoid breaking a working server in the name of “security”.

Lynis is an open-source security auditing and hardening tool for Linux, Unix and macOS systems. It scans the machine and gives suggestions to improve security.

A good Linux home server is not one with a perfect score. It is one where you understand what is running, what is exposed, what is backed up, and what changed since last month.

Quick Lynis hardening checklist

If you only want the short version, this is the order I would follow after running a Lynis audit on a Linux home server:

Install all security updates.
Reboot if required.
Check open ports with ss -tulpn.
Remove unused services.
Harden SSH.
Disable direct root SSH login.
Use SSH keys where possible.
Enable UFW with LAN-only SSH access.
Review sudo users.
Remove or lock old accounts.
Check cron jobs and systemd timers.
Fix obvious bad permissions.
Review logs for repeated errors.
Install Fail2ban if SSH is exposed or noisy.
Confirm backups before making deeper changes.
Re-run Lynis and compare the results.

That list gives you practical improvement without turning a home server into a bank.

1. Install Lynis

On Ubuntu, Debian, Linux Mint and similar systems:

sudo apt update
sudo apt install lynis

Check the installed version:

lynis show version

Run a basic system audit:

sudo lynis audit system

After the scan, Lynis will print warnings, suggestions and a hardening index. The hardening index is useful, but do not obsess over it.

Useful report files:

sudo less /var/log/lynis.log
sudo less /var/log/lynis-report.dat

The log is easier to read as a human. The report file is more structured and useful if you want to compare scans later.

Here's and example of Ubuntu Server 26.04 default install:

2. Do not fix everything at once

This is the most important rule.

Lynis may suggest many changes. Some are easy wins. Some are more advanced. Some may not apply to your specific server. Some may break your setup if you paste commands without understanding them.

My preferred method:

Run Lynis.
Save or read the report.
Fix only a few obvious issues.
Reboot if needed.
Test your services.
Run Lynis again.
Repeat later.

A home server is not a compliance lab. If the machine runs Docker, file sharing, media services, backups, monitoring or a reverse proxy, test carefully after each group of changes.

Security hardening is good. Random breakage is not.

3. Update the system first

Before touching exotic hardening settings, update the server.

sudo apt update
sudo apt upgrade
sudo apt autoremove

Check if a reboot is required:

[ -f /var/run/reboot-required ] && cat /var/run/reboot-required

Reboot if needed:

sudo reboot

After the reboot, run Lynis again:

sudo lynis audit system

There is no point tuning small security settings while the server is missing basic package updates.

Patch first. Harden second.

4. Check what is listening on the server

Lynis may warn about services, open ports or unnecessary software. Before changing firewall rules, check what the server is actually exposing.

sudo ss -tulpn

Also check enabled services:

systemctl list-unit-files --type=service --state=enabled

And currently running services:

systemctl --type=service --state=running

Now ask:

Do I still need this service?
Is it listening on the network?
Should it be LAN-only?
Is it old test software?
Is it installed because of a tutorial I forgot?

If a service is not needed, remove it instead of just hiding it behind a firewall.

sudo apt purge package-name
sudo apt autoremove

Less software means fewer updates, fewer exposed ports and fewer surprises.

5. Harden SSH before worrying about fancy settings

SSH is usually the front door of a Linux home server.

Check your active SSH configuration:

sudo sshd -T | less

Useful SSH hardening settings include:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
X11Forwarding no

Do not paste those directly into the main config without testing. Create a separate config file:

sudo nano /etc/ssh/sshd_config.d/99-homelab-hardening.conf

Add:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
X11Forwarding no
AllowUsers youruser

Replace youruser with your actual username.

Test the SSH config:

sudo sshd -t

If there is no output, reload SSH:

sudo systemctl reload ssh

Important: keep one working SSH session open while testing from another terminal. Do not lock yourself out of your own server.

6. Enable UFW and restrict SSH to the LAN

A common Lynis suggestion is to configure a firewall.

For Ubuntu and Debian-style home servers, UFW is usually enough.

sudo apt install ufw

Basic safe setup:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp
sudo ufw enable
sudo ufw status verbose

Change 192.168.1.0/24 to your real LAN range.

This is better than simply allowing SSH from everywhere:

sudo ufw allow 22/tcp

If the server is only managed from home, SSH should usually be LAN-only or VPN-only.

After changing firewall rules, test from another machine:

nc -vz server-ip 22
nc -vz server-ip 8080

Or scan known ports:

nmap -p 22,80,443,3000,8080,8096 server-ip

Do not assume the firewall works. Test it.

7. Review users and sudo access

Lynis may complain about accounts, permissions or authentication settings.

List local users:

cut -d: -f1 /etc/passwd

Check sudo users:

getent group sudo

Check recent logins:

last -a | head -20

Remove users you no longer need:

sudo deluser olduser

Lock a user account without deleting it:

sudo usermod -L olduser

Good home server rules:

use one normal admin user;
disable direct SSH root login;
avoid shared admin accounts;
use strong unique passwords;
use SSH keys where possible;
keep sudo access limited.

Related: Strong Unique Passwords

8. Check password and authentication settings

Lynis may suggest stronger password hashing, password aging or account policy changes.

Useful files to review:

/etc/login.defs
/etc/pam.d/common-password
/etc/pam.d/common-auth

For a simple home server, do not overcomplicate password aging. Forcing password changes too often can lead to worse passwords. I prefer:

strong unique passwords;
a password manager;
SSH keys;
no reused credentials;
no default passwords on dashboards.

Check password aging for a user:

sudo chage -l youruser

Lock unused accounts instead of letting them sit around forever.

9. Fix file permissions carefully

Lynis may report world-writable files, strange permissions or insecure directories.

Find world-writable directories:

sudo find / -xdev -type d -perm -0002 -print 2>/dev/null

Find world-writable files:

sudo find / -xdev -type f -perm -0002 -print 2>/dev/null

Do not blindly chmod everything. Some directories are supposed to be writable, such as /tmp.

Check a suspicious file:

ls -lah /path/to/file
stat /path/to/file

For a home server, the biggest permission mistakes are usually in:

Docker bind mounts;
shared Samba folders;
backup directories;
web directories;
scripts copied from tutorials;
home directories with strange permissions.

Do not make everything 777 just because an application complained once.

chmod 777 is not troubleshooting. It is surrender.

10. Check cron jobs and systemd timers

Scheduled jobs are easy to forget.

List user cron jobs:

crontab -l

List root cron jobs:

sudo crontab -l

Check system cron directories:

ls -lah /etc/cron.d/
ls -lah /etc/cron.daily/
ls -lah /etc/cron.weekly/
ls -lah /etc/cron.monthly/

Check systemd timers:

systemctl list-timers --all

Ask:

Do I recognize these jobs?
Are they still needed?
Do scripts have safe permissions?
Do they write logs?
Do they run as root unnecessarily?

A forgotten root cron job running an old script is exactly the kind of thing a home server collects over time.

11. Review logs before adding more tools

Logs are not exciting until they save you.

Useful commands:

journalctl -p warning -b
journalctl -u ssh -b
journalctl --since "7 days ago" -p err
sudo dmesg -T | tail -50

Check authentication logs:

sudo journalctl -u ssh --since "7 days ago"

Depending on your distribution, you may also have:

/var/log/auth.log
/var/log/syslog
/var/log/kern.log

For a home server, I would check for:

failed SSH attempts;
services failing repeatedly;
disk errors;
permission denied loops;
weird cron output;
Docker containers restarting constantly.

Lynis can tell you where to improve logging, but you still need to actually read logs sometimes.

12. Install Fail2ban if SSH is exposed or noisy

If SSH is available beyond your own trusted LAN, Fail2ban can help reduce brute-force noise.

sudo apt install fail2ban

Create a local jail config:

sudo nano /etc/fail2ban/jail.local

Basic SSH jail:

[sshd]
enabled = true
port = ssh
filter = sshd
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

Restart and check:

sudo systemctl restart fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

Fail2ban is not a replacement for SSH keys, firewall rules or disabling root login. It is another layer.

Related: Fail2ban for Beginners

13. Be careful with kernel and sysctl suggestions

Lynis may suggest kernel hardening or sysctl tuning.

View current sysctl settings:

sudo sysctl -a | less

Custom settings usually go here:

/etc/sysctl.d/99-homelab-hardening.conf

Example settings often seen in hardening guides:

net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

Apply changes:

sudo sysctl --system

Be careful here. Network settings can affect routing, VPNs, containers and unusual homelab setups.

If you use Docker, WireGuard, VLANs, reverse proxies or routing between interfaces, test after changes.

14. Do not install every scanner just because Lynis suggests it

Lynis may mention malware scanning tools.

For a simple Linux home server, I do not automatically install every scanner. It depends on what the server does.

A scanner makes more sense if the server:

stores files from Windows machines;
accepts uploads;
runs a mail server;
shares files over Samba;
is exposed to untrusted users.

For a private Docker host or media server, basic hardening, updates, firewalling and backups may matter more.

Security tools should solve real problems, not just increase the number of daemons running.

15. Check backup status before hardening more

Before making many changes, make sure backups exist.

At minimum, back up:

/etc
/home
/srv
Docker compose files
application data
important scripts
SSH keys, if appropriate and stored safely

Simple rsync example:

sudo rsync -aAX --info=progress2 /etc/ /mnt/backup/etc/
sudo rsync -aAX --info=progress2 /home/ /mnt/backup/home/
sudo rsync -aAX --info=progress2 /srv/ /mnt/backup/srv/

Test restoring at least one file:

mkdir /tmp/restore-test
cp /mnt/backup/etc/hostname /tmp/restore-test/
cat /tmp/restore-test/hostname

A hardening mistake is annoying. A hardening mistake with no backup is a weekend project.

16. Re-run Lynis and compare the results

After fixing a few things, run Lynis again:

sudo lynis audit system

Save the output if you want to compare over time:

sudo cp /var/log/lynis.log /root/lynis-$(date +%F).log
sudo cp /var/log/lynis-report.dat /root/lynis-report-$(date +%F).dat

Now compare what changed.

Do not chase every point. Look for meaningful improvements:

fewer unnecessary services;
firewall enabled;
SSH hardened;
updates applied;
permissions cleaned up;
logs reviewed;
backups confirmed.

That is real progress.

17. Things I would not blindly fix

Not every Lynis suggestion should be applied immediately.

I would be careful with:

kernel and network sysctl changes on servers using Docker, VPNs or routing;
aggressive password aging policies;
removing packages without understanding dependencies;
locking down permissions for app folders without knowing how the app writes data;
disabling services just because they look unfamiliar;
changing PAM settings without testing login from another session.

Security hardening should be deliberate.

If you do not understand a suggestion, research it first or test it on a non-critical machine.

18. Monthly Lynis routine for a home server

For a home server, I like a simple monthly routine:

sudo apt update
sudo apt upgrade
sudo lynis audit system
sudo ufw status verbose
sudo ss -tulpn
df -h
journalctl -p warning --since "30 days ago"

Then ask:

Did new ports appear?
Did a service start failing?
Did disk usage grow too much?
Did Lynis report new warnings?
Did I add a Docker container and forget about it?
Did backups actually run?

This is not glamorous. That is why it works.

Final thoughts

Lynis is useful because it gives structure to Linux hardening.

But the report is not the boss of your server. You are.

Use Lynis to find weak points, then fix the things that matter first:

updates;
open ports;
SSH;
firewall rules;
unused services;
users and sudo access;
permissions;
logs;
backups.

A good Linux home server is not one with a perfect Lynis score.

It is one where you understand what is running, what is exposed, what is backed up, and what changed since last month.

That is the kind of boring security I like.

Written by MsR

MsR is a Linux homelab and cybersecurity enthusiast who documents practical experiments with home servers, Docker, firewalls, backups, Lynis, Fail2ban, honeypots and old hardware. The guides on IT Random Stuff are based on hands-on testing, real configurations and lessons learned from running Linux systems at home.

IT Random Stuff

Search This Blog