SSH into your VPS host:
sudo apt-getco updatesudo apt-get install binutils libreadline5 libruby1.8 ruby ruby1.8 ssl-cert unhide.rb mailutils
Once it has finished downloaded, extract the files and enter the resulting directory:
tar xzvf rkhunter*cd rkhunter*
Install RKHunter:
sudo ./installer.sh
Table of Contents
Initial Test Runs
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
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
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
Configure RKHunter Based on Known-Good Values
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:
MAIL-ON-WARNING="[email protected]"
If you set up local mail, you can put this to receive mail when you log in as root:
MAIL-ON-WARNING="[email protected]"
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.
Check the Configuration
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.
Set Up a Cron Job to Automate Checks
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.
Conclusion
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.