rkhunter & chkrootkit: wise crackers only
February 6th, 2008 edited by TinchoArticle submitted by Claudio Criscione. Guess what? We still need you to submit good articles about software you like!
Rkhunter and chkrootkit are tools to check for signs of a rootkit. They will inspect the system they’re running on and report anomalies either through the shell or via email.
Although an attacker able to install a rootkit is likely also able to easily escape or delete these tools, not every attacker is a skilful one. Not every script kiddie knows about these tools or the way to cover its tracks. Since every single error can make the difference, on either sides, an effortless passive protection can do no harm and adds one more (maybe thin) layer of security.
Both rkhunter and chkrootkit, indeed, can be deployed quickly and require little management effort.
Installation
Thanks to apt-get, aptitude and their super cow powers, we can just go for a
$ sudo aptitude install chkrootkit rkhunter
Or go root if you’re not a sudoer. Once installed, both packages will add a cron entry and automatically execute every day.
What they do
Both chkrootkit and rkhunter use a signature-rule/filter based system: they can detect the presence of known rootkits —via files or similar indicators— and flag anomalous conditions, like interfaces entering promiscuos mode or hidden files. In fact, not unlike anti-virus programs, rkhunter and chkrootkit indeed need periodical updates.
The signature based approach is a quite simple one, something like a big grep and strings combo: it is strongly suggested to have an alternate copy of some binary (egrep and strings, just to name a couple) so that —at the very least— the aggressor has to patch them too. Obviously, mounting the disk via another machine is far more reliable, even if it won’t allow you to find modified rootkits.
Both softwares provide MD5 signature verification on known binaries, with sort of a white list approach, thus trying to ensure that none of the most important binaries were tampered with. Among others, checks performed include searching for hidden directories and scanning for promiscuous interfaces and suspicious file permissions.
So, what are the differences?
Rkhunter pros
The autoupdate feature is a very nice feature to have. You just have to run rkhunter –update and the software will update the rootkit definitions. You can control the autoupdate behaviour via the /etc/default/rkhunter file, using the CRON_DB_UPDATE parameter, which is enabled by default. This will upgrade the system binaries MD5 database and the good/bad/black list of applications and program versions.
Other features of note include the ability to use WebJob to run rkhunter in a centralized manner, thus simplyfying administration, and the colorful interactive mode you can run with rkhunter -c.
Chkrootkit pros
Chkrootkit provides a differential mode where it reports only what changed between the latest scan and the previous one. While this is a very nice feature to limit the impact of false postives, one single missed mail can make the difference, so choosing whether it should be enabled or not is an important decision.
If the whole “grep and look for signatures” stuff is not enough for you, you can root chkrootkit in expert mode, with
# chkrootkit -x
This will give you a greatly improved control on what’s going on and more verbose output, but make sure to redirect the output somehow.
Chkrootkit has a nice modular design, with subcomponents taking care of differenct aspects, like lastlog and wtmp deletions. Last but not least, chkrootkit can run without installation and from a read only media.
The big decision
Maybe now you’re wondering “which one should I use?”. My answer is simply “both of them”. There is no reason not to do that, so go for it. Chkrootkit has been available since, at least, Sarge and Dapper. Rkhunter, being newer, has been available since Etch.
The chkrootkit package has been available .
The rkhunter package has been available .
February 6th, 2008 at 9:43 pm
You may also want to install “unhide” since rkhunter can make use of it.
It’s a small utility which attempts to detect hidden processes by looking at discrepancies between the lists returned by different system calls.
To enable it, just remove “hidden_procs” from the DISABLE_TESTS variable in /etc/rkhunter.conf
February 6th, 2008 at 11:36 pm
One thing to be wary of is the number of false-positives coming from chkrootkit. It seems to alert for just about every .* directory it can find on the system, including bits of JDK, volatile tmpfs, and is subject to race-conditions falsely complaining about “hidden” processes when all that’s happened is a few have died since it compared lists. Processes in detached screen sessions seem to show up based on their ttys not being found in utmp. It seems to think my init is `INFECTED’ which is complete hokum. All this because it’s a kludged-up load of shell-scripts relying on grep for ill-defined regexp-matches.
So. I’m with rkhunter - it’s far more intelligent in operation, doing things like checking for changes in passwd and root-equivalent users between runs, for example. I can and do run both on all dozen-or-more debian boxes, but I take rkhunter far more seriously and only look for *changes* in output from chkrootkit.
February 7th, 2008 at 2:36 am
Full ACK, Tim.
These false positives are a pain. I don’t know why it don’t provide an opportunity to disable the well known false positives.
Always the same alerts for the .* files and detecting my running pppd as a sniffer in the daily mails blunts me.
If there were a serious alert i wouldn’t even recognize it.
So I also run the two programms, but trust rkhunter more.
February 7th, 2008 at 10:38 am
… and if I (it) find(s) an infection… what should I do then?
I know… i smell like a newbie :-)
February 8th, 2008 at 7:34 am
Anyone know why rkhunter’s default install on etch says that it’s running on an unsupported OS, and what can be done about it?
February 8th, 2008 at 4:31 pm
paulgear you have to use this hashupd script from rkhunter
http://dfn.dl.sourceforge.net/sourceforge/rkhunter/hashupd.sh
February 15th, 2008 at 4:43 pm
Unfortunately hashupd.sh has a bug in its Debian section…
Make sure line 156 reads:
if [ -n "${version}" -a -n "${architecture}" ]; then
February 19th, 2008 at 10:08 am
As long as this
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403863
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406962
is not resolved by either side, I won’t install chrootkit anymore.
So I stick only with rkhunter on my servers.
February 20th, 2008 at 4:17 pm
Archebuse the most sensible answer is: make sure it’s a rootkit and not a false positive. In case it is, do an image of the disk, format the machine and start again with a clean system. There is no (easy and feasible) way to tell if your machine is clean once it has been rootkited.
Once you’re back up and running, check your applications and passwords: since you’ve been hacked, you have vulnerabilities in place, and if you don’t patch them up you’re bound to be hacked again soon.
February 29th, 2008 at 8:13 pm
@Claudio Criscione
Grazie per la risposta, anche se non lascia molta speranza… certo che ’sti rootkit sono una bella rogna.
Grazie ancora
Archebuse
April 19th, 2008 at 5:33 pm
If you think false positives are a pain, you may consider enable diff mode. You simply edit /etc/chkrootkit.conf, change
DIFF_MODE=”false”
to
DIFF_MODE=”true”
and it will only problems if they differ from yesterday’s report.
This is a bit unsafe, since a cracker can easily modify your yesterday’s report. But if a craker can modify your yesterday’s report, why doesn’t it modify your cron job or even chkrootkit itself? So I guess you don’t lose much security by enabling diff mode.
May 21st, 2008 at 1:55 am
I stopped using rootkit checkers a long time ago.
I have only one port open on my firewall - that’s for Bittorrent, which I only rarely run. I figured that anyone who can get root access to my system can also remove any rootkit checkers, or just turn them into mindless collections of “sleep” and “echo” statements in a shell script.
Also, I think rkhunter also pulls in “exim” as a dependency. There was a definite drop in speed when rkhunter was installed, which caused me to look at what dependencies were pulled in; and I discovered exim.
January 10th, 2009 at 1:30 pm
The second Debian bug entry above linked to a site with a patch. This was hardcoded to ignore .ramfs:
Line 705
files=`${find} ${DIR} \( -name “.[A-Za-z]*” -o -name “…*” -o -name “.. *” \) -and -not -wholename /lib/init/rw/.ramfs`
A more general solution was suggested by the first bug entry to ignore empty files. This could be done by changing the patch from using on the affected “find”:
-and -not -wholename /lib/init/rw/.ramfs
to:
-and -not -empty