Home / server / Questions / 601154
Accepted
Nic Cottrell
Asked: 2014-06-03 01:13:00 +0800 CST

rkhunter warns of inode change but no file modification date changes

  • 772

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?

centos

4 Answers

  1. Best Answer

    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.

    • 9

  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.

    • 2

  3. 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?

    • 1

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

    • -1