9

I have several systems running Centos 6 with rkhunter installed. I have a daily cron running rkhunter and reporting back via email.

I very often get reports like:

---------------------- Start Rootkit Hunter Scan ----------------------
Warning: The file properties have changed:
        File: /sbin/fsck
        Current inode: 6029384    Stored inode: 6029326
Warning: The file properties have changed:
        File: /sbin/ip
        Current inode: 6029506    Stored inode: 6029343
Warning: The file properties have changed:
        File: /sbin/nologin
        Current inode: 6029443    Stored inode: 6029531
Warning: The file properties have changed:
        File: /bin/dmesg
        Current inode: 13369362    Stored inode: 13369366

From what I understand, rkhunter will usually report a changed hash and/or modification date on the scanned files to, so this leads me to think that there is no real change.

My question: is there some other activity on the machine that could make the inode change (running ext4) or is this really yum making regular (~ once a week) changes to these files as part of normal security updates?

Andrew Schulman
  • 8,561
  • 21
  • 31
  • 47
Nic Cottrell
  • 1,282
  • 16
  • 31

4 Answers4

9

Updating files is often done by writing a new file in the same directory followed by renaming the file on top of the old file. This method is usually applied to everything installed through a package manager, but also to any update performed to executables and libraries even if updated for other reasons.

This way of updating files ensure that any process opening the file will get either the old or the new, and not see anything changing in the file, which they have opened. It does mean that each time it is updated, you will actually have a new file with the same name, hence the inode number has changed.

I guess this is the reason for those files having a new inode number.

A security update could be one reason. But there is another possibility, which I first observed on Fedora Core 1, and that could very well have made it into Centos at some point.

Executables and libraries are being prelinked such that they can start faster and use less memory. During this process the load address is randomized to make exploiting security vulnerabilities a little bit harder. A cron job would periodically repeat the process with new randomized addresses causing all the prelinked executables and libraries to get updated.

kasperd
  • 29,894
  • 16
  • 72
  • 122
  • 2
    Yep, prelinking seems the most likely explanation here. – Michael Hampton Jun 14 '14 at 19:07
  • Is there a good way to handle this though? If I just have a cron to run `rkhunter --propupd` then I could miss a hack and invalidate the whole point of rkhunter, right? – Nic Cottrell Jun 18 '14 at 17:19
  • 1
    @NicholasTolleyCottrell `rpm` handle it by first verifying the integrity of the `prelink` executable, then it calls the `prelink` executable with arguments to revert the prelinking with input from a prelinked executable and output to stdout. Then `rpm` can check the integrity of that output. No idea if that approach can be applied to `rkhunter`. – kasperd Jun 20 '14 at 08:09
  • 1
    See this thread for how to get a checksum that won't jump around: http://www.linuxquestions.org/questions/linux-security-4/question-about-different-checksum-of-binaries-827461/. I've moved away from rkhunter as a cron based tool. It has lots of useful checks, but inability to turn off checks that amount to false positives makes it nearly useless for getting your attention to where its needed, as I just get used to ignoring its emailed reports. I still find it occasionally useful as a manually run tool. – mc0e Jul 01 '14 at 11:28
2

The other option I found was to disable these properties tests completely. If you edit /etc/rkhunter.conf and look for the DISABLE_TESTS line and change it to:

DISABLE_TESTS="suspscan hidden_procs deleted_files packet_cap_apps apps properties"

The properties test is the one checking and returning false positives on the file hashes.

Nic Cottrell
  • 1,282
  • 16
  • 31
1

A changed inode number usually means the file has been replaced. It could as you say be due to an expected update. I'd verify the md5sums of those files match those of the distributed versions. If you have another comparable system around, it might be easiest to compare to that.

Take a look at the accepted answer at rkhunter reports change in file properties, but I don't see that they've been updated by yum for how to check which package those binaries are from.

It wouldn't be too surprising if those binaries were from a distribution which has been updated because of an issue with another binary which was changed, but the binaries you list were included in the new version of the package unchanged. Did your report also show some binary where the content was changed?

Community
  • 1
mc0e
  • 5,786
  • 17
  • 31
  • No, actually, it looks like I only have ever received that the file properties have changed - never that the contents have. – Nic Cottrell Jun 20 '14 at 07:30
-1

I cloned a drive to a larger drive and received the warnings of files with different inodes numbers. I removed rkhunter from the system and reinsalled and ran the scann again with no warnings concerning inodes numbers being changed

will smith
  • 1