Rootkit Hunter, or rkhunter, detects over 240 rootkits – pieces of malware designed to gain control of a system. However, while testing for rootkits may be rkhunter's main purpose, it is far from the only one. You can see the list of the names of the various tests run by the script by entering rkhunter --list (Figure 1) [1]. Mostly, the tests' names are self-explanatory. They include checks not only for rootkits, but also changed or deleted libraries and commands, hidden ports, loaded kernel modules, and several dozen other aspects of a system besides.

Figure 1: The --list option shows the tests that rkhunter runs.

Rkhunter is written for generic Unix systems with a Bourne-type shell, such as Bash or ksh. Since its tests depend on online databases, it also requires an Internet connection. It is available in major Linux distributions and can be run from the command line, or as a cron job. Note that some distributions, such as Debian and its derivatives, may not install some of the Perl packages needed for a few of the tests. You can see what functionality may be missing by running rkhunter --list (Figure 2) and will then have to figure out which packages support the missing functionality. These packages, of course, may have different names depending on your distribution.

Figure 2: Some Perl-based scripts may need to be installed separately.

Setup and Configuration

If you install rkhunter from outside your distro's standard repositories, you can make sure that you always have the latest version by running rkhunter --versioncheck to help ensure your system's security. With most commands, I would always recommend that you not run the repository version, but rkhunter is so slow to release that in many cases the latest version is contained in a distro's repository (see below). Currently, for example, even Debian, whose software versions often lag behind those of other distributions, has the latest rkhunter release in its official release.

No matter what your installation source, before running rkhunter for the first time, you need to run rkhunter --propupd to ensure that the command's databases are up to date (Figure 3). You should also run --propupd whenever the system is updated. Otherwise, the log will contain false positives that will only waste your time. You can automate the updating of the databases by adding:

APT_AUTOGEN="yes"

to

/etc/default/rkhunter

Figure 3: Use --propupd to keep rkhunter's databases current.

You may also want to configure /etc/rkhunter.conf for your system. The field MAIL-ON-WARNING ="EMAIL" can be modified to send a list of warnings to the address of your choice. You may also want to whitelist some common false positives by removing the # to uncomment these lines:

#ALLOWHIDDENDIR=/dev/.udev
#ALLOWHIDDENDIR=/dev/.static
#ALLOWHIDDENDIR=/dev/.initramfs

After the first time you run rkhunter, additional whitelists (Figure 4) can be defined by adding the field SCRIPTWHITELIST="FILE,FILE" so that false positives are not flagged when the command is run. After any changes to rkhunter.conf, in some distros you can run rkhunter -C to check for any errors.

Figure 4: Rkhunter flags known exceptions or whitelisted files that give false positives.

Running the Tests

If you install rkhunter from a distribution's repository, it can be run as soon as it is installed, although whitelisted files will be logged. If you install from an outside source, however, configure the command as described above. In either case, to run the command, enter rkhunter --check (-c) (Figure 5). Rkhunter will begin to run its tests, although at several stages it will pause until you press the Enter key. As it runs, it may flag warnings, ranging from whitelists (files that list acceptable files) to unusually large files. A running summary of results displays (Figure 6) as tests are done, although they may scroll too quickly to be easily read at some stages. Not to worry – you will want to study /var/log/rkhunter anyway (Figure 7). Some of the warnings may be false positives; for example, Firefox often has a larger than usual configuration file (Figure 8). Take your time with the logfile, and make a list of any problems that you need to research to learn how to address.

Figure 5: Rkhunter at the start of its run.

Figure 6: Rkhunter finishes with a summary of results.

Figure 7: After rkhunter runs, go to the log for details.

Figure 8: Some warnings are false positives; rkhunter can be configured to ignore such warnings after its first run.

This basic sequence can be modified with options, some of which have a long and a short form, and some which have only a long form. To start with, you can use --disable or --enable to select the tests to run in comma-separated lists (use the --list option to see which tests are available). Since the next step after running rkhunter is to examine the log, you can also use --display-logfile to show the log immediately after the completion of the command. Similarly, --skip-keypress (-sk) omits the pauses in the running of the command where you need to press the Enter key to continue. In addition, you can also suppress default features with commands like --nocolors and --nolog or set the directories to use with options like configfile FILE or tmpdir FILE.

Running as a Cron Job

Rkhunter can be automated even more by setting it to run as a cron job. The cron job is best run with MAIL-ON-WARNING set in /etc/rkhunter.conf. Since rkhunter must be run as root, use the root account's crontab. Before beginning, use crontab -l to see if root already has a crontab, and, if so, back it up before beginning.

To add rkhunter to the crontab, enter crontab -e while logged in as root, and, if this is your first time editing it, choose a text editor to use. There are many ways to enter times and dates with crontab, but the easiest is to enter the minutes and hours using a 24 hour clock, followed by the command. For example, if you want to run rkhunter at 3am, when you are not using your computer, the cron job entry would look like this:

The three asterisks indicate unused fields. The --cronjob option runs rkhunter without colors and without pausing, while the --update option updates the databases and --quiet runs the command without output. MAIL-ON-WARNING sets email notifications, and you can check the log later.