Run a Trustworthy rkhunter Check and Handle Warnings Safely

rkhunter's warnings are not a verdict; they are a to-do list you still have to investigate. You will refresh Rootkit Hunter's data, run a host check as root, validate its configuration and investigate warnings without immediately overwriting the evidence. The installed package here is Debian's rkhunter 1.4.6-12, running program version 1.4.6. Allow 15 to 30 minutes for a first run, depending on the host and the amount of logging.

This is a diagnostic tool, not proof that a machine is clean. A warning means that rkhunter found something it wants you to review. It does not identify the cause, and a clean result does not rule out a compromise. You need a working root shell, network access for the update step, and a recent backup or other trusted record of the host if you are investigating an incident.

1. Check the installed command

Start without changing the host. The command and package versions are useful context when you compare a result with another machine or report a problem.

$ command -v rkhunter
/usr/bin/rkhunter
$ rkhunter --version
Rootkit Hunter 1.4.6

The program normally requires root. On this installation, an unprivileged --config-check is rejected, so use sudo for the operational commands below. If your account cannot use sudo, obtain an approved root shell rather than weakening permissions on the configuration or database.

2. Review the configuration before scanning

The default configuration is /etc/rkhunter.conf. It can be supplemented by /etc/rkhunter.conf.local and by .conf files in /etc/rkhunter.d, when those files exist. Command-line options override equivalent configuration values.

Read the effective files and look for local exceptions, mail settings and unusual paths:

$ sudo sed -n '1,220p' /etc/rkhunter.conf
$ sudo find /etc/rkhunter.d -maxdepth 1 -type f -name '*.conf' -print 2>/dev/null

Do not copy a whitelist or path from an untrusted host. A local exception can hide a real change. In the configuration syntax, pathname options are generally one pathname per line and should not be quoted. Keep a record of any deliberate exception and why it is safe.

Checkpoint: validate the files before the scan.

$ sudo rkhunter --config-check
Checking configuration file(s)...
Configuration file(s) checked

The exact wording varies with the language file and package. A zero exit status means the configuration check found no problem. A non-zero status means that you must read and correct the reported configuration issue; it is not a scan result. To check every configured option, the manual documents --enable all --disable none with --config-check, although the normal check only validates options for tests it will run.

3. Refresh the detection data

Run this step when you have decided that the configured mirrors and the network path are trustworthy:

$ sudo rkhunter --update

--update checks for newer text data files and may install them, so it changes rkhunter's database area. It requires a command-line web browser such as wget or lynx. The installed program reports status 0 when no update is available, 1 for a download error, and 2 when updates were installed. Status 2 is a successful update, not a failure.

Keep this separate from a response to a suspected compromise. Updating from a machine that may be controlled by an attacker can complicate evidence handling. Preserve the existing log and record the update result before starting an investigation.

4. Run the host check

Run the full check with colours disabled and keypress prompts skipped. This is an elevated, read-mostly operation, but it writes the normal log and temporary files:

$ sudo rkhunter --check --skip-keypress --nocolors

By default the log is /var/log/rkhunter.log. A new run moves the previous log aside with an .old suffix unless --appendlog is used. The check can examine changed commands, startup files, network interfaces, listening applications and known rootkit or malware indicators. Missing optional commands can cause individual tests to be skipped.

Do not treat a non-zero status as proof of malware. rkhunter returns non-zero when any warning or error occurs. Capture the status immediately if a script needs it:

$ sudo rkhunter --check --skip-keypress --nocolors
$ status=$?
$ printf 'rkhunter exit status: %s\n' "$status"
rkhunter exit status: 0

The displayed status above is an example of a clean command completion, not a promised result for your host. A warning, a missing prerequisite or a configuration error requires review.

5. Preserve and inspect the result

Before rerunning anything that might rotate the log, copy the result to an access-controlled investigation directory. Choose a destination appropriate to your incident process:

$ sudo install -d -m 0700 /root/rkhunter-review
$ sudo cp --preserve=all /var/log/rkhunter.log /root/rkhunter-review/rkhunter.log
$ sudo less /root/rkhunter-review/rkhunter.log

Search for warnings without editing the log:

$ sudo grep -nE 'Warning|Found|Not found|Skipped' /root/rkhunter-review/rkhunter.log

Read the surrounding test output as well as the matching line. A changed file may be an expected package upgrade; a listening port may belong to an approved service; a hidden file may be a normal application artefact. Verify those explanations independently with your package manager, service inventory and trusted system records.

If you need a compact unattended report, use the documented cron mode:

$ sudo rkhunter --cronjob --report-warnings-only --logfile /var/log/rkhunter.log

--cronjob implies --check, --skip-keypress and --nocolors. It sends no normal output to standard output by default, while --report-warnings-only makes warnings visible. Do not use --nolog while you still need an audit trail.

6. Update the properties baseline only after verification

A property warning means that a recorded file property differs from the current file. It does not say whether the current file or the stored value is genuine. The command below changes the properties database and is therefore a security-sensitive action:

$ sudo rkhunter --propupd /path/to/verified-file

Use --propupd only after you have verified the file through a trusted package signature, a known-good deployment or an approved change record. The manpage explicitly warns that rkhunter cannot tell what caused a change. Updating the baseline first would discard a useful comparison and can make a compromised file look normal.

You can update a filename, directory, package name or the whole database. The package form uses the base package name without a version, and package metadata is used only when a package manager is configured. Do not run an unrestricted --propupd as a reflex. If the update was wrong, restore the properties database from your backup or reinstall rkhunter's database through your normal recovery process; there is no general undo option in the command.

Common traps

• Wrong status interpretation: status 2 from --update means updates were installed, while any warning from --check makes its status non-zero.
• Lost evidence: a normal run rotates the log. Copy the log before rerunning a check, or use a separate approved logfile for a follow-up.
• False certainty: skipped tests and expected administrator changes still need an explanation. A clean summary is not a forensic conclusion.
• Blind whitelisting: configuration exceptions and --propupd change what future checks can report. Verify first and document the reason.
• Interactive automation: use --skip-keypress or --cronjob for unattended runs. Do not feed arbitrary input into a security check just to make it continue.