Scanning for rootkits with rkhunter (DEPRECATED)

NOTE: This article has been updated. The new version can be reached via this link.

Continuing with the scanning for rootkits articles, we now concentrate on installing and configuring rkhunter.

Rkhunter works in the same manner as chkrootkit (see this article) but rkhunter also scans for other types of exploits.

Which one?

Neither rkhunter nor chkrootkit are necessarily better than the other and can easily be run at the same time, giving added defence measures and peace of mind.

As with chkrootkit, rkhunter is not an active defence method. It does not prevent exploits being placed on your Slice but it will inform you if there is a suspected exploit. Again, as with chkrootkit, if you have been exploited then the only real option is to reinstall with a fresh Slice.


Log into your VPS and move to your sources directory:

cd ~/sources

Once there, download the latest version of rkhunter from the SourceForge download area:


Version 1.2.9 is the latest stable version but do check with the rkhunter home page to see if a newer version is available (at the time of writing there is a 1.3.0 beta2 version available but my advice would be to wait until a stable release before upgrading).


Being good sysadmins we want to check the md5sum of the downloaded file before extracting it and installing it.

To find the md5 signature of the downloaded package:

md5sum rkhunter-1.2.9.tar.gz

Compare this with the signature available on the Debian package list - ensure you look at the original download and not the diff patch that Debian applies.


Once happy, extract the source code:

tar xvfz rkhunter-1.2.9.tar.gz

Then move into the newly created directory:

cd rkhunter-1.2.9/


To install the code, simply issue the following command:

sudo ./


At the end of the install a message tells me:

Installation ready.
See /usr/local/rkhunter/lib/rkhunter/docs for more information.
Run 'rkhunter' (/usr/local/bin/rkhunter)

Have a read of the main docs:

sudo nano /usr/local/rkhunter/lib/rkhunter/docs/README

I won't go through what it says but do take some time to have a look and see what configurations are available.


First thing is to update the signatures and files rkhunter uses to detect anomalies:

sudo /usr/local/bin/rkhunter --update

Do that at least once or until you get an output like this:

Running updater...

Mirrorfile /usr/local/rkhunter/lib/rkhunter/db/mirrors.dat rotated
Using mirror
[DB] Mirror file                      : Up to date
[DB] MD5 hashes system binaries       : Up to date
[DB] Operating System information     : Up to date
[DB] MD5 blacklisted tools/binaries   : Up to date
[DB] Known good program versions      : Up to date
[DB] Known bad program versions       : Up to date


Let's run it:

sudo /usr/local/bin/rkhunter -c

This runs rkhunter in an interactive mode. In other words, when it gets to the end of a particular scan, you need to press 'enter' to continue.

My scan results were as follows:

---------------------------- Scan results ----------------------------

MD5 scan
Scanned files: 0
Incorrect MD5 checksums: 0

File scan
Scanned files: 342
Possible infected files: 0

Application scan
Vulnerable applications: 0

Scanning took 79 seconds


Which is nice.

If you want to skip the interactive but add the -sk option at the end:

sudo /usr/local/bin/rkhunter -c -sk

To see other options available for use:

sudo /usr/local/bin/rkhunter


You may have configured your Slice in a way that triggers warnings from rkhunter.

Firstly, I would say listen to what it says and decide if you really need something that is a security risk and, secondly, if you do want the risk, there are ways of configuring rkhunter so it ignores certain things.


Here's an example. Let's say I ran rkhunter and got this message:

Checking for allowed root login... Watch out Root login possible. Possible risk!
    info: "PermitRootLogin yes" found in file /etc/ssh/sshd_config
    Hint: See logfile for more information about this issue

That's fairly straight forward: I left the "PermitRootLogin" set to "yes" in my sshd_config file.

Now we know that's a silly thing to do and it's a nice reminder to tighten up our SSH configuration.

But let's say we do want to enable root logins via SSH but don't want a warning every time we run rkhunter.

Enter /usr/local/etc/rkhunter.conf. Open it up:

sudo nano /usr/local/etc/rkhunter.conf

Scan down until you reach this line:


Uncomment the line and change the 0 to a 1


Now when we run rkhunter there are no highlighted warnings and this message:

Checking for allowed root login...  [ OK (Remote root login permitted by explicit option) ]

Now it's says root logins are OK, but specifies why it's OK: You explicitly allowed it.

However, please don't allow root logins. Thanks.


Lastly, we know that automation and email notification make an administrator's life a lot easier, so now we can add rkhunter to a cronjob.

This is straight from the rkhunter website: You need to create a short shell script as follows:


( /usr/local/bin/rkhunter --versioncheck
/usr/local/bin/rkhunter --update
/usr/local/bin/rkhunter --cronjob --report-warnings-only
) | /usr/bin/mail -s "rkhunter output"

Save the file and call it something like 'rkhunterscript'. Make the file executable:

chmod 750 rkhunterscript

and place in your local bin folder or in a public bin folder. Now set a root cronjob as follows:

sudo crontab -e

My cronjob looks like this:

10 3 * * * /home/demo/bin/rkhunterscript -c --cronjob

This will run the script at 3.10am each day. Why 3.10am? Well, I have chkrootkit running at 3.00am, I'd like that to finish before starting this one.


Article Comments:

Lex commented Mon Sep 10 16:12:21 UTC 2007:

This might be a silly question, but what's to stop a rootkit from installing a trojaned version of rkhunter or chkrootkit that falsely tells you you're all clean? Doesn't this result in a false sense of security?

I realize that it's likely that at least some rootkits won't do this, but I thought it was worth mentioning. Is there a tool like rkhunter that works over SSH, so that it could be run from another server entirely to lower the chance of false negatives?

PickledOnion commented Mon Sep 10 16:20:25 UTC 2007:

Hi Lex,

It's not a silly question at all. I think to be able to do that it would also have to fool the update servers (notice the rkhunter cronjob checks the version and updates itself before running a check).

I suppose in theory it would be possible but I can't conceive of the level of integration with the install and updating that would be needed to pull off a trick like that.

It's also another reason to run both. I remember in my 'windows' days I used to run two virus checkers and one discovered an infection whilst the other didn't and vica-versa.

If anyone has any deep security knowledge and could answer this with some real examples I would be grateful.


randy commented Mon Sep 10 19:07:15 UTC 2007:

Can u provide a couple of examples as to how rootkits would get on your slice to begin with?

Just wondering if everything is "locked down" via SSH, firewall, etc, how does this stuff get in?


Lex Neva commented Mon Sep 10 19:31:30 UTC 2007:

Well, PickledOnion, let's just follow out the devil's advocacy to its logical conclusion. Why would a trojanned version of rkhunter even bother to query the update server? If a rootkit comes onto your system, all it needs to do is replace rkhunter with a binary that prints "Updating... successful, scanning for rootkits, none found", etc. So it's not necessary to compromise the actual update server if the fake rkhunter binary doesn't bother to query it. We could check to see if rkhunter actually queries the server through some kind of elaborate packet sniffing, but who's to say THAT program won't also become trojanned?

Using two scanners is, of course, advantageous because a rootkit might not compromise both, but it's definitely conceivable to do exactly that. If you're dealing with a dedicated, talented blackhat who's personally rooting your box, it's more likely that they'll be able to replace all of your tools like rkhunter, chkrootkit, tripwire, etc.

I guess my end point is that it's important to know that these tools CAN'T be infallible, and are only really trustable when they DO report a rootkit found on your system (assuming it's not a false positive!) Their reports that your system is all clear shouldn't be trusted completely.

Randy, years ago I was rooted on a system that had everything locked down, no unnecessary services, etc. The attacker got in via an unpatched vulnerability in the SSH daemon, because I was lax in applying security updates. It's also possible for your system to be compromised even if you do apply all of the security fixes that your distribution releases. This can happen if there's a vulnerability in one of your services that is not publically known yet, which is called a "Zero-day exploit".

PickledOnion commented Mon Sep 10 19:35:18 UTC 2007:

Hi Randy,

There are a few ways they can infect machines. The first and, as far as I am aware, most common method is by manual means such as downloading some source code from untrusted sources. Not being ultra careful at all times with everything you do. Allowing other users to have access to certain commands, directories.

I know it's a server but you'd be surprised the shortcuts people (sometimes) take to save themselves time or those tedious tasks we'd all rather not do.

Another way is not patching your system if an exploit is found in installed software. It doesn't take the bad guys long to scan thousands of machines looking for a particular exploit. Once found you are more likely to be the target of an effort to compromise your system.

Lex mentions that no system is completely secure and that is absolutely correct. However, unless we all switch off our servers the best we can do is keep on top of it with patches, updates and regular scanning.


Jlhenry commented Mon Sep 17 17:26:02 UTC 2007:

FYI, I had to uncomment the following in my /etc/rkhunter.conf under Debian Etch.


And personally, I do not like permitting remote root login so I left this:


And also, I've uncomment the line:

I used the default Debian Etch package. Installation:

#aptitude install rkhunter libmd5-perl

I run it in a cron this way: 26 * * * * /usr/bin/rkhunter --versioncheck --quiet 26 * * * * /usr/bin/rkhunter --update >/dev/null 26 * * * * /usr/bin/rkhunter -c --cronjob

Thanks for the help!!


Jlhenry commented Mon Sep 17 17:27:08 UTC 2007:

Sorry for the formation. I didn't know that "#" was for Bold.

PickledOnion commented Mon Sep 17 17:32:34 UTC 2007:

Hi Jlhenry,

I think I may have to change the Markdown option as it does interpret config files a little oddly!

Thanks for the info. I agree that root logins are a bad idea - you can leave it commented out (as you have) or have it set at 0.

Was there any particular reason you used aptitude and not installed via source?

Cheers, PickledOnion.

Jlhenry commented Mon Sep 17 17:56:26 UTC 2007:

Would love to be able to edit my comment... I made an other mistake.

As I do not want to receive alerts for every run, but do want only to receive information for Warning, I need to add the "--quiet" keyword.

Jlhenry commented Mon Sep 17 18:03:44 UTC 2007:

_ Was there any particular reason you used aptitude and not installed via source? _

Yes sure. I used aptitude (or apt-get) in order to be able to update easily my distro and programs. If there is a bug fix in rkhunter available in debian, I only have to do aptitude upgrade (or apt-get upgrade).

Using sources, It's harder to maintain updates. Imagine that you have installed plenty of programs. Using source, It would takes hours to upgrades all. But with aptitude, It takes few seconds.

Furthermore, I use apticron (debian package) in order to receive a mail when there is programs updates available.


James commented Sun Dec 02 23:00:05 UTC 2007:

krhunter 1.3.0 is out. The install command is now:

sudo ./ --layout default --install

Before running a scan, run:

sudo /usr/local/bin/rkhunter --propupd

  • Also, when you call "rkhunterscript -c --cronjob", I don't think the "-c --cronjob" options do anything....
  • You probably want to use the --nocolors option on all the calls in rkhunterscript, since things like "[1;33m" shouldn't be in the email.
  • Here's my rkhunterscript (remove the "--quiet" if you want to see everything): #!/bin/sh ( /usr/local/bin/rkhunter --versioncheck --nocolors --quiet /usr/local/bin/rkhunter --update --nocolors --quiet /usr/local/bin/rkhunter --propupd --nocolors --quiet /usr/local/bin/rkhunter --cronjob --report-warnings-only ) | /usr/bin/mail -es "rkhunter output" you@domain

James commented Sun Dec 02 23:01:34 UTC 2007:

Markdown has no respect for line breaks. Here's the same script with semicolons to break the commands up: #!/bin/sh ( /usr/local/bin/rkhunter --versioncheck --nocolors --quiet; /usr/local/bin/rkhunter --update --nocolors --quiet; /usr/local/bin/rkhunter --propupd --nocolors --quiet; /usr/local/bin/rkhunter --cronjob --report-warnings-only ) | /usr/bin/mail -es "rkhunter output" you@domain

Knack commented Mon Feb 11 14:50:38 UTC 2008:

@James, I think that the "rkhunter --propupd" command should not be part of the script. As stated in the rkhunter log file:

WARNING! It is the users responsibility to ensure that when the '--propupd' option is used, all the files on their system are known to be genuine, and installed from a reliable source.
The rkhunter '--check' option will compare the current file properties against previously stored values, and report if any values differ. However, rkhunter cannot determine what has caused the change, that is for the user to do.

If you run "rkhunter --propupd" each day just before doing the system checking, any property changed by an attacker will be stored in the database, and no difference will be found later during the check.

Instead of it, you should run manually the --propupd as you need it, after verifying that the system is not compromised. Or, at least, run the command after the check.

Kris Leech commented Tue Sep 23 14:29:38 UTC 2008:

Both hkhunter and chkrootkit can be installed using apt-get (on hardy).

Moped commented Thu Jul 09 12:39:59 UTC 2009:

rkhunter in the deb repos is currently 1.3 branch, so would be better to install from there than follow the exact wget here..

Moped commented Thu Jul 09 12:58:09 UTC 2009:

running rkhunter on lenny gave warnings with unhide, a little bit of googling later, and i find that running rkhunter --propupd updated the necessary rkhunter files to stop the warning message.

Want to comment?

(not made public)


(use plain text or Markdown syntax)