How To Use RKHunter to Guard Against Rootkits on an Ubuntu VPS

Because the Ubuntu repositories have an outdated version of rkhunter which contains an unpatched bug, we will be installing from source so that our program will behave properly.

Change to your home directory and download the files. As of this writing, 1.4.0 is the latest version, but you can go to the project’s home page to see if a newer version is available:

cd
wget http://downloads.sourceforge.net/project/rkhunter/rkhunter/1.4.0/rkhunter-1.4.0.tar.gz

Once it has finished downloaded, extract the files and enter the resulting directory:

tar xzvf rkhunter*
cd rkhunter*

Inside, we should see a “files” directory, and an installer script. We will use this to install our program. Specify the layout to install it in the /usr directory so that it will be in our default path:

sudo ./installer.sh --layout /usr --install

This will install the software and the configuration files.

Now, we have rkhunter installed, but we still need some utilities to use all of its functionality. We can get these from the Ubuntu repositories:

sudo apt-get update
sudo apt-get install binutils libreadline5 libruby1.8 ruby ruby1.8 ssl-cert unhide.rb mailutils

You will be asked some questions about the mail server setup. You can configure this if you’d like, but for the sake of brevity, we will not be configuring a web-facing mail server. Select “Local only” to follow our example.

If you are installing locally, you can name the system mail anything. Otherwise, make sure to use a fully qualified domain name.

Now, our software is installed and ready for testing and configuration.

Before we begin configuration, we will do a few test runs with the default settings to get an idea of how the software operates and set a baseline against which to guide our modifications.

The first thing we should do is ensure that our rkhunter version is up-to-date. If you did get the latest tarball from the site, it shouldn’t need to do anything, but it’s best to check anyways:

sudo rkhunter --versioncheck

[ Rootkit Hunter version 1.4.0 ]

Checking rkhunter version...
  This version  : 1.4.0
  Latest version: 1.4.0

Next, we need to perform a similar option to update our data files. These files contain information that rkhunter checks against to determine if a file or behavior is suspicious or not. Keeping these files current is essential for accurately assessing your system:

sudo rkhunter --update

With our database files refreshed, we can set our baseline file properties so that rkhunter can alert us if any of the essential configuration files it tracks are altered. We need to tell rkhunter to check the current values and store them as known-good values:

sudo rkhunter --propupd

File created: searched for 167 files, found 136

Finally, we are ready to perform our initial run. This will produce some warnings. This is expected behavior, because rkhunter is configured to be generic and Ubuntu diverges from the expected defaults in some places. We will tell rkhunter about these afterwards:

sudo rkhunter -c --enable all --disable none

It will run one section of tests and then ask you to press enter to continue. You can review the warnings that were produced as you go, but there will be more detailed information in the log afterwards. Press enter until all of the tests are run.

Now, we should go through the logs and check out all of the warnings that were produced:

sudo nano /var/log/rkhunter.log

Search the file for the word “Warning”. You will see a number of different warnings that are caused by different aspects of our filesystem. We will configure rkhunter to ignore the ones we know are harmless in the next section.

Some of the changes, like changes to the passwd file, are only showing up because they have been changed by the helper utilities we downloaded with apt. The timestamps on these files are more recent than the rkhunter database files. They will disappear on the next run.

Another alternative to checking the log is to have rkhunter print out only warnings to the screen, instead of all checks:

sudo rkhunter -c --enable all --disable none --rwo

You can then copy and paste this information somewhere so we can implement the changes in our configuration file.

Now that we have some info on how rkhunter is viewing our system, we can tell it which files and applications to ignore or handle differently in order to avoid false-positives.

Begin by opening the rkhunter configuration file with root privileges:

sudo nano /etc/rkhunter.conf

Set Up Mail Notifications

The first thing you can do is set up email notifications if you want to receive those when rkhunter hits a warning. You can do this here:

<pre> MAIL-ON-WARNING=“<span class=“highlight”>your_user@domain.com</span>” </pre>

If you set up local mail, you can put this to receive mail when you log in as root:

MAIL-ON-WARNING="root@localhost"

Note, that the mail programs were configured when you installed them, so whether this functions correctly depends on what your choices were.

A related configuration option specifies the program and options for sending the mail:

MAIL_CMD=mail -s "[rkhunter] Warnings found for ${HOST_NAME}"

Whitelist Known Script Files

Next, we will fix the warnings that told us that some of the binary packages on the system have been replaced by scripts. Some distributions (Ubuntu included) use scripted versions of files instead of their binary counterparts.

The four warnings I received were all examples of this. We can set a SCRIPTWHITELIST parameter to tell rkhunter that these are expected to be script files:

SCRIPTWHITELIST="/usr/sbin/adduser"
SCRIPTWHITELIST="/usr/bin/ldd"
SCRIPTWHITELIST="/usr/bin/unhide.rb"
SCRIPTWHITELIST="/bin/which"

This will prevent these files from triggering false positives on all subsequent checks. Note that these whitelists are specific for certain tests, so we are only flagging that we know these files are not supposed to be binary. Other changes can still trigger warnings, which is what we want.

Whitelist Files in the /dev Directory

Certain files in the /dev directory trigger a warning for rkhunter. These are all implementation details that do not actually point to anything wrong. They are supposed to be there and are supported by the distribution.

There are three warning types that we need to deal with. The first one is was a warning that there was a “suspicious file” in the directory. We will specifically allow this file by placing this line in the configuration:

ALLOWDEVFILE="/dev/.udev/rules.d/root.rules"

The next warning we must deal with is that there is a hidden directory in /dev. This is also expected. It is the directory that contained the previous file:

ALLOWHIDDENDIR="/dev/.udev"

The last warning is for hidden files. These are basic configuration files that are kept in this directory so that the utilities can access them regardless of the partitioning scheme and mount status.

Add these lines to allow these files to exist:

ALLOWHIDDENFILE="/dev/.blkid.tab"
ALLOWHIDDENFILE="/dev/.blkid.tab.old"
ALLOWHIDDENFILE="/dev/.initramfs"

Allow Root SSH Login

The next step is simply an assertion check. When you run rkhunter, it checks a parameter in its configuration file and compares it to the value in the SSHD configuration file.

This option specifies whether the root user can log in using SSH. Many security practices recommend disabling root login. If you have disabled root login, you should leave this parameter as “no”.

If you need root login over SSH, you should change this parameter to “yes” so that rkhunter can check this and will mark this setting as valid:

ALLOW_SSH_ROOT_USER=yes

Save and close the file when you are finished.

Now that we have configured rkhunter, you need to validate the configuration and check to see that everything is now working as expected.

The first step in this is checking that the configuration file itself is valid. You can run a test on it to see if rkhunter will accept all of the values that you’ve assigned:

sudo rkhunter -C

If this gives you any output back, you need to revisit the configuration again to adjust your parameters.

After you’ve gotten the configuration file in good working order, you can run the test again to see if there are any warnings.

sudo rkhunter -c --enable all --disable none --rwo

This should produce one warning, because our rkhunter configuration itself has been modified:

Warning: The file properties have changed:
         File: /etc/rkhunter.conf
         Current hash: fa8ad80a18100e669be507e69d0cbb88348fc07d
         Stored hash : f9015108a2f6d8044126351cf16235c55993ff7a
         Current inode: 2098189    Stored inode: 2100424
         Current size: 37607    Stored size: 37359
         Current file modification time: 1388443781 (30-Dec-2013 17:49:41)
         Stored file modification time : 1388442019 (30-Dec-2013 17:20:19)

We should have updated the file properties again after modifying this file. Do that now by typing:

sudo rkhunter --propupd

After it is finished, you can run the check command again and see that no errors are produced.

Forgetting to update the file properties gives you an option to check the mail notifications if you configured that. Since we configured local mail, we can access the messages by checking the root mailbox:

sudo mail

You should see a message that you can access by the number in the second column.

You can exit the mail screen by typing:

quit

If you set up remote email, you can check that too. It may be in your spam folder, so look there if you have not received it in your regular inbox.

Now that you have configured rkhunter and verified that it is operating correctly, it is probably a good idea to automate the system. We can set up rkhunter to run checks every day so that we have up-to-date information about intrusions.

This is most useful if you can have it email your regular email address, so that you are more likely to check it. Change the MAIL-ON-WARNING parameter in the /etc/rkhunter.conf file to your regular email if you haven’t done so already.

We want to run rkhunter with root privileges, as we have been doing, so we should add it to the root user’s crontab. It is important to remember not to add it to the system crontab, because this could be replaced in an upgrade and wipe out your changes.

First, we can see if the root user already has a crontab by typing:

sudo crontab -l

If this returns a crontab, then it is best to back up the file in case we make a mistake. You can do that by typing:

sudo crontab -l > crontab.bak

Afterwards, we can edit the root user’s crontab by issuing this command:

sudo crontab -e

If this is the first time you are running this command, it will ask you to choose the editor you would like to use. A safe choice is nano, if you do not have a preference for any of the other editors.

Afterwards, you will be taken into your editor and your file will be pre-populated with some comments explaining how to write the crontab.

There are a lot of complex ways to write cron specifications that can run commands at many intervals. For our purposes, we are just going to have to decide what time each day to run the command. As with most services, running it at night is usually optimal:

The format we will use is minutes hours * * * command. The hours should be written in 24 hour format (for example, 15 for 3pm). The command we want to use is /usr/bin/rkhunter --cronjob --update --quiet.

So if we want to run this command at 4:15am, we can type at the bottom of the file:

15 04 * * * /usr/bin/rkhunter --cronjob --update --quiet

The --cronjob option tells rkhunter to not output in a colored format and to not require interactive key presses. The update option ensures that our definitions are up-to-date. The quiet option suppresses all output.

The cron utility will run this command at 4:15am, and if there is any output, the rkhunter command itself will email our user to alert them. If no problems were found, no email will be received.

Now that you have rkhunter installed, configured, and automated, it should do the work for you for the most part. Make sure that if you are relying on email alerts, that you check them regularly and respond to any warnings that are produced.

It is also helpful to remember that when you make software changes on your computer, rkhunter may report differences in its next run. It is recommended that after you make changes, at least run sudo rkhunter --propupd to update rkhunter to the new file properties.

Because this software references known-good values and system states that you have allowed, it is best to install and configure this directly after you have configured most of the software for your installation. Doing so before configuring your software will result in a lot of false positives, while waiting too long can result in intrusion and not knowing if you are whitelisting bad files.

<div class=“author”>By Justin Ellingwood</div>