Scanning for rootkits with rkhunter

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?

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?

Thanks!

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".

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

ALLOWHIDDENDIR=/etc/.java ALLOWHIDDENDIR=/dev/.udev ALLOWHIDDENDIR=/dev/.static ALLOWHIDDENDIR=/dev/.initramfs

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

#ALLOWSSHROOT_USER=0

And also, I've uncomment the line: MAIL-ON-WARNING=myemailaddress@domain.com

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!!

Jluc

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

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.

_ 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.

Jluc

krhunter 1.3.0 is out. The install command is now:

sudo ./installer.sh --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

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

@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.