rkhunter Rootkit Detection: Setup, Scheduled Scans, and Warnings

This article is a localized edition of the Japanese original. Read the Japanese original

rkhunter (Rootkit Hunter) is a command that checks a Linux server for rootkits and backdoors. It mainly looks at the following:

• Whether system commands such as ls and ps have been modified since you took the baseline (hash, permissions, owner, and so on)
• Whether files or directories used by known rootkits exist
• Suspicious hidden files, and whether ports commonly used by backdoors are open
• Settings such as whether root is allowed to log in over SSH

This article walks through installing rkhunter, building the baseline data, running scans on a schedule, and checking the warnings. The content is current as of October 2026 and was tested on Ubuntu 24.04 and Rocky Linux 9.

What to know before you start

• As of October 2026, the latest release is 1.4.6 (published in 2018), and its rootkit definition data has barely been updated since. Rather than a tool for finding new malware, it is more realistic to use it as a tool that checks "whether system files have changed since the baseline was taken"
• The baseline data (file hashes and so on) must be created while the server is clean. If you build the baseline after an intrusion, the tampered state is recorded as "normal"
• If an attacker gains root, they can modify rkhunter itself and its log on that server. The absence of warnings is not proof that the server is safe

Step 1: Install rkhunter

Ubuntu and Debian

sudo apt update
sudo apt install rkhunter

Mail packages (such as bsd-mailx) are pulled in as recommended packages, so a mail server configuration screen may appear because of their dependencies. If you will not receive results by email, you can install it with sudo apt install --no-install-recommends rkhunter.

AlmaLinux and Rocky Linux (RHEL family)

rkhunter is not in the standard repositories; it is in EPEL.

sudo dnf install epel-release
sudo dnf install rkhunter

Step 2: Check the configuration (fixing the error on Ubuntu)

The configuration file is /etc/rkhunter.conf. First, run the configuration check.

sudo rkhunter -C

If it finishes without printing anything, the configuration is fine. With the Ubuntu 24.04 package, the following error appears right after installation.

Invalid WEB_CMD configuration option: Relative pathname: "/bin/false"

Scans (--check) still run, but the configuration check and the definition data update (--update) fail with this error. Change the WEB_CMD="/bin/false" line in /etc/rkhunter.conf as follows.

sudo sed -i 's|^WEB_CMD=.*|WEB_CMD=""|' /etc/rkhunter.conf
sudo rkhunter -C

About updating the definition data

The Debian and Ubuntu packages ship with updates of the definition data from the internet turned off through UPDATE_MIRRORS=0 and MIRRORS_MODE=1. As shipped, sudo rkhunter --update ends with "Update failed". If you want to use updates, change /etc/rkhunter.conf as follows and make sure wget or curl is installed.

UPDATE_MIRRORS=1
MIRRORS_MODE=0
WEB_CMD=""

As noted in the previous section, the definition data has not been updated for a long time, so leaving updates off does not affect using rkhunter to detect later file changes.

The exit codes of --update are 0 for "no updates", 1 for "error", and 2 for "something was updated". 2 is not an error.

Use package manager data (optional)

When you set PKGMGR, files that belong to packages are checked against the package manager's records (dpkg or rpm). The RHEL-family package already uses PKGMGR=RPM. To use it on Ubuntu or Debian, add the following to /etc/rkhunter.conf.

PKGMGR=DPKG

After changing this setting, run --propupd from the next step again.

Step 3: Build the baseline data

This records the hashes and other properties of system files. Run it right after installation, while you know the server is clean.

sudo rkhunter --propupd

When you update packages with apt or dnf, system command files change legitimately and the next scan reports warnings. After updating packages, confirm that you recognize the updates and then run --propupd again.

On Ubuntu and Debian, setting APT_AUTOGEN="true" in /etc/default/rkhunter rebuilds the baseline automatically after you install or update packages with apt. It saves effort, but be aware that any file already tampered with at that moment is also absorbed into the baseline.

Step 4: Run a manual scan

sudo rkhunter --check --sk

Option	Meaning
--check (-c)	Check the system
--sk (--skip-keypress)	Do not wait for the Enter key between test groups
--rwo (--report-warnings-only)	Show warnings only
--cronjob	For cron. Combines --check, --sk and no-color output

The scan takes a few minutes. If there is even one warning, the exit code is 1 and the following is shown at the end.

One or more warnings have been found while checking the system.
Please check the log file (/var/log/rkhunter.log)

The details are recorded in the log. You can find the log location with grep ^LOGFILE /etc/rkhunter.conf (on Ubuntu it is /var/log/rkhunter.log).

sudo grep -i -A3 warning /var/log/rkhunter.log

Step 5: Scan on a schedule

Ubuntu and Debian

The package includes a daily cron job (/etc/cron.daily/rkhunter), but it does not run by default. Change /etc/default/rkhunter as follows to enable it.

CRON_DAILY_RUN="true"
REPORT_EMAIL="root"

Only when there are warnings, the results are emailed to the REPORT_EMAIL address. Sending mail requires that the server can send email (a mail server that provides the sendmail command). Even if the mail does not arrive, the results are appended to /var/log/rkhunter.log.

RHEL family

The EPEL package includes /etc/cron.daily/rkhunter, which updates the definition data and runs a scan every day. You can change where the results go with MAILTO in /etc/sysconfig/rkhunter.

Registering your own schedule

To run the scan during a low-load time of day, create a file in /etc/cron.d/ (and stop the package's daily cron job).

echo '30 3 * * * root /usr/bin/rkhunter --cronjob --report-warnings-only' | sudo tee /etc/cron.d/rkhunter-local

With --report-warnings-only, output is produced only when there are warnings, so cron result emails also arrive only when there are warnings.

Step 6: How to check warnings

Most warnings are false positives with a legitimate cause. However, excluding them without checking means you will miss real problems. Check them in the following order.

A system command’s hash changed

First, check whether the file matches the one from the official package.

# Ubuntu/Debian: find which package owns the file and verify it against the package records
dpkg -S /usr/bin/filename
sudo dpkg --verify package-name

# RHEL family
rpm -qf /usr/bin/filename
sudo rpm -Vf /usr/bin/filename

If verification prints nothing, the file matches the package records. If you had just updated packages, rebuild the baseline with sudo rkhunter --propupd. If it does not match, or the file does not belong to any package, suspect tampering.

Common warnings and how to handle them

Example warning	Common cause	How to handle it
File properties (hash and so on) changed	A package update	Verify with the check above, then run --propupd
A command has been replaced by a script	A command the distribution ships as a shell script	After confirming it is the package's file, add it to SCRIPTWHITELIST
Hidden directories or hidden files exist	Legitimate hidden files created by software	Identify them, then add them to ALLOWHIDDENDIR or ALLOWHIDDENFILE
Root login over SSH is allowed	PermitRootLogin in sshd_config	The basic fix is to disable root login. If you need it, set ALLOW_SSH_ROOT_USER to match the actual setting
No system logging daemon is running	Environments such as containers that collect logs another way	If that is by design, add the relevant test (system_configs_syslog in this case) to DISABLE_TESTS to skip it

Write exclusions in /etc/rkhunter.conf, for example:

SCRIPTWHITELIST=/usr/bin/filename
ALLOWHIDDENDIR=/etc/.java

You can list the test names with rkhunter --list tests. Add names to the existing DISABLE_TESTS line (Ubuntu already disables several tests). After changing the settings, check them with sudo rkhunter -C, then scan again and confirm the warnings are gone.

If you really suspect an intrusion

If you find system commands that do not match the package records, hidden files you cannot identify, or ports you do not recognize, do not trust the results of tools on that server; move on to initial response, such as disconnecting the server from the network. The procedure is described in initial response steps when a server has been hacked.

Summary

• Use rkhunter as a tool that checks whether system files have changed since the baseline. Build the baseline with --propupd while the server is clean
• On Ubuntu 24.04, leaving WEB_CMD="/bin/false" causes an error. Change it to WEB_CMD="" and confirm with rkhunter -C
• Scan with rkhunter --check --sk; on Ubuntu, enable scheduled runs with CRON_DAILY_RUN="true" in /etc/default/rkhunter
• After updating packages, review the changes and run --propupd again
• Verify warnings against the package records with dpkg --verify or rpm -Vf before deciding whether to exclude or investigate

Related articles:

• How to set up file tampering detection with Tripwire
• How to scan a server for malware with ClamAV
• How to detect unauthorized access to a server (log monitoring, tampering detection, WordPress integrity checks)
• How to detect and remove backdoors in WordPress

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)