Security automation with rkhunter
Command Line – rkhunter

© Lead Image © Kamirika, photocase.com
The Rootkit Hunter script efficiently checks for malware, with the potential to detect over 240 rootkits.
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.
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.
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
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.
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.

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.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.
News
-
The GNU Project Celebrates Its 40th Birthday
September 27 marks the 40th anniversary of the GNU Project, and it was celebrated with a hacker meeting in Biel/Bienne, Switzerland.
-
Linux Kernel Reducing Long-Term Support
LTS support for the Linux kernel is about to undergo some serious changes that will have a considerable impact on the future.
-
Fedora 39 Beta Now Available for Testing
For fans and users of Fedora Linux, the first beta of release 39 is now available, which is a minor upgrade but does include GNOME 45.
-
Fedora Linux 40 to Drop X11 for KDE Plasma
When Fedora 40 arrives in 2024, there will be a few big changes coming, especially for the KDE Plasma option.
-
Real-Time Ubuntu Available in AWS Marketplace
Anyone looking for a Linux distribution for real-time processing could do a whole lot worse than Real-Time Ubuntu.
-
KSMBD Finally Reaches a Stable State
For those who've been looking forward to the first release of KSMBD, after two years it's no longer considered experimental.
-
Nitrux 3.0.0 Has Been Released
The latest version of Nitrux brings plenty of innovation and fresh apps to the table.
-
Linux From Scratch 12.0 Now Available
If you're looking to roll your own Linux distribution, the latest version of Linux From Scratch is now available with plenty of updates.
-
Linux Kernel 6.5 Has Been Released
The newest Linux kernel, version 6.5, now includes initial support for two very exciting features.
-
UbuntuDDE 23.04 Now Available
A new version of the UbuntuDDE remix has finally arrived with all the updates from the Deepin desktop and everything that comes with the Ubuntu 23.04 base.