Home / ubuntu / Questions / 255950
Accepted
zuba
Asked: 2013-02-15 01:18:00 +0800 CST

rkhunter: right way to handle warnings further?

  • 772

I googled some and checked out two first links it found:

  1. http://www.skullbox.net/rkhunter.php
  2. http://www.techerator.com/2011/07/how-to-detect-rootkits-in-linux-with-rkhunter/

They don't mention what shall I do in case of such warnings:

Warning: The command '/bin/which' has been replaced by a script: /bin/which: POSIX shell script text executable
Warning: The command '/usr/sbin/adduser' has been replaced by a script: /usr/sbin/adduser: a /usr/bin/perl script text executable
Warning: The command '/usr/bin/ldd' has been replaced by a script: /usr/bin/ldd: Bourne-Again shell script text executable
Warning: The file properties have changed:
         File: /usr/bin/lynx
         Current hash: 95e81c36428c9d955e8915a7b551b1ffed2c3f28
         Stored hash : a46af7e4154a96d926a0f32790181eabf02c60a4

Q1: Is there more extended HowTos which explain how to deal with different kind warnings?

And the second question. Were my actions sufficient to resolve these warnings?

a) To find the package which contains the suspicious file, e.g. it is debianutils for the file /bin/which

~ > dpkg -S /bin/which
debianutils: /bin/which

b) To check the debianutils package checksums:

~ > debsums debianutils
/bin/run-parts                                                                OK
/bin/tempfile                                                                 OK
/bin/which                                                                    OK
/sbin/installkernel                                                           OK
/usr/bin/savelog                                                              OK
/usr/sbin/add-shell                                                           OK
/usr/sbin/remove-shell                                                        OK
/usr/share/man/man1/which.1.gz                                                OK
/usr/share/man/man1/tempfile.1.gz                                             OK
/usr/share/man/man8/savelog.8.gz                                              OK
/usr/share/man/man8/add-shell.8.gz                                            OK
/usr/share/man/man8/remove-shell.8.gz                                         OK
/usr/share/man/man8/run-parts.8.gz                                            OK
/usr/share/man/man8/installkernel.8.gz                                        OK
/usr/share/man/fr/man1/which.1.gz                                             OK
/usr/share/man/fr/man1/tempfile.1.gz                                          OK
/usr/share/man/fr/man8/remove-shell.8.gz                                      OK
/usr/share/man/fr/man8/run-parts.8.gz                                         OK
/usr/share/man/fr/man8/savelog.8.gz                                           OK
/usr/share/man/fr/man8/add-shell.8.gz                                         OK
/usr/share/man/fr/man8/installkernel.8.gz                                     OK
/usr/share/doc/debianutils/copyright                                          OK
/usr/share/doc/debianutils/changelog.gz                                       OK
/usr/share/doc/debianutils/README.shells.gz                                   OK
/usr/share/debianutils/shells                                                 OK

c) To relax about /bin/which as I see OK

/bin/which                                                                    OK

d) To put the file /bin/which to /etc/rkhunter.conf as SCRIPTWHITELIST="/bin/which"

e) For warnings as for the file /usr/bin/lynx I update checksum with rkhunter --propupd /usr/bin/lynx.cur

Q2: Do I resolve such warnings right way?

rkhunter

2 Answers

  1. Best Answer

    Using debsums is a very clever idea with one major flaw: If something were to overwrite a root-owned file such as /bin/which, it could also rewrite /var/lib/dpkg/info/*.md5sums with an updated checksum. There is no chain of custody back to a Debian/Ubuntu signature, as far as I can see. Which is a real shame because that would be a really simple, really quick way to verify the authenticity of a live file.

    Instead to truly verify a file, you need to download a fresh copy of that deb, extract the internal control.tar.gz and then look at its md5sums file to compare against a real md5sum /bin/which. It's a painful process.

    What has most likely happened here is that you've had some system updates (a distribution upgrade even) and you haven't asked rkhunter to update its profiles. rkhunter needs to know what files should be like so any system updates are going to upset it.

    Once you know something is safe, you can run sudo rkhunter --propupd /bin/which to update its reference of the file.

    This is one of the problems with rkhunter. It needs deep integration into the deb process so that when trusted, signed packages are installed, rkhunter updates its references to files.

    And no, I wouldn't whitelist things like this because this is exactly the sort of thing a rootkit would go after.

    • 5

  2. zuba, the whitelist idea is a bad one; it is unassigning a file to be checked which should be visible to you and your anti-malware, the idea is used though and viewing the message is harmless. Could we create a writethrough instead would be better. somewhere along the lines of \lines beginning with \ will be ignored; but that takes some coding experience and intimate knowledge of the workings of rkhunter.

    The bin/which will be rewritten when needed to accommodate programming changes; In general one file may be replaced or files may be temporarily created and change or disappear after a reboot, and that may trick the rkhunter software.

    There is a line where software/updates or antimalware resembles a rootkit, and I believe these are one of those.

    The method you employ is dangerous only if it changes a program or file that will (act to) somehow affect the computers operation. Sometimes we are worse that our machines in that respect. Proving this for your computer is really unfair to ask, as I could if it were mine. I would know, document the warnings and checksums and would note whenever there was a change.

    • 1