rkhunter (Rootkit Hunter)

Security 2026-08-28

rkhunter scans a system for known rootkits, backdoors, and local exploits. It checks system binaries against stored hashes, looks for suspicious file permissions, hidden files in sensitive directories, and known rootkit signatures. It is pre-installed on Shani OS as a direct dependency of the shani-core package (alongside lynis, apparmor, audit, and fwupd).

Unlike Lynis, Shani OS does not enable a scheduling timer for rkhunter — there's no rkhunter.timer unit enabled by shani-core's post-install hook. The scheduled-scan setup below (cron) is a genuine gap you need to fill yourself, not busywork duplicating something already running.

rkhunter does not change anything — it only scans and reports.

Important workflow: rkhunter must build a baseline of known-good file hashes before the system is potentially compromised — ideally immediately after installation, and again after every deployed OS version bump (sudo shani-deploy). Running it for the first time on an already-compromised system provides little value.

Initial Setup

# 1. Update the rootkit signature database
sudo rkhunter --update

# 2. Build a baseline of current system file hashes
#    Run this immediately after a clean install and after every system update
sudo rkhunter --propupd

Running a Scan

# Full system scan (interactive — press Enter to continue between sections)
sudo rkhunter --check

# Non-interactive scan (suitable for cron / scripting)
sudo rkhunter --check --skip-keypress

# Suppress OK messages — show only warnings
sudo rkhunter --check --skip-keypress --rwo

# Log output to a file
sudo rkhunter --check --skip-keypress --rwo 2>/dev/null | tee ~/rkhunter-$(date +%Y%m%d).txt

Understanding the Output

[ Rootkit Hunter version 1.4.6 ]

Checking system commands...
  Performing 'strings' command checks
    Checking 'strings' command                               [ OK ]

  Performing file properties checks
    Checking for prerequisites                               [ OK ]
    /usr/bin/awk                                             [ OK ]
    /usr/bin/basename                                        [ WARNING ]

[09:15:32] Warning: The file properties have changed:
[09:15:32]          File: /usr/bin/basename
[09:15:32]          Current inode: 123456   Stored inode: 123400

A WARNING for a file that changed after an OS deployment is expected — this is why you run --propupd after every deployed version bump. An unexpected warning (file changed with no deployment) warrants investigation.

After an OS Deployment

On Shanios there is no rolling package update path: the host binaries change wholesale each time you deploy a new OS version (sudo shani-deploy). Every deployed version bump replaces the entire root filesystem, so all stored hashes legitimately change at once — update the baseline immediately after each deployed OS version bump:

sudo shani-deploy
sudo rkhunter --propupd   # update baseline to reflect the newly deployed image

If you scan before running --propupd after a deployment, you will see a flood of hash-change warnings for every system binary — these are false positives.

Changes in the mutable layers do not trip host hash checks: Flatpak apps, Nix packages, and container contents live outside the read-only root and are not part of rkhunter's host-binary baseline, so adding or updating them never produces file-property warnings.

Scheduled Scans

sudo tee /etc/cron.weekly/rkhunter-scan << 'EOF'
#!/bin/sh
rkhunter --update --skip-keypress --quiet
rkhunter --check --skip-keypress --rwo \
  --logfile /var/log/rkhunter/scan-$(date +%Y%m%d).log 2>/dev/null
EOF
sudo chmod +x /etc/cron.weekly/rkhunter-scan
sudo mkdir -p /var/log/rkhunter

Configuration

/etc/rkhunter.conf controls which checks run and what is whitelisted:

# Email warnings to root (requires a working MTA — see Exim page)
MAIL-ON-WARNING=root

# Whitelist a known-safe script that rkhunter flags as suspicious
SCRIPTWHITELIST=/usr/bin/egrep
SCRIPTWHITELIST=/usr/bin/fgrep

# Whitelist a hidden directory that rkhunter warns about
ALLOWHIDDENDIR=/dev/.udev
ALLOWHIDDENDIR=/dev/.static

# Disable a specific test (use test name from the log)
DISABLE_TESTS=suspscan

After editing:

sudo rkhunter --config-check   # verify config syntax

Logs

# View the full log from the last scan
sudo cat /var/log/rkhunter.log

# See only warnings from the last scan
sudo grep -i "warning\|infected\|found" /var/log/rkhunter.log

Troubleshooting

Issue	Solution
Many `WARNING` after an OS deployment	Expected — run `sudo rkhunter --propupd` to update the baseline, then re-scan
`Unhappy about OS` / `Unknown OS` warning	Cosmetic on Arch-based systems; does not indicate a problem
False positive for a known-safe binary	Add it to `SCRIPTWHITELIST` in `/etc/rkhunter.conf`
`rkhunter --update` fails	Check network connectivity; the signature database is downloaded from the rkhunter project servers
Scan not finding anything suspicious	That's the expected result on a healthy system — the value of rkhunter is the delta between scans, not finding problems on every run