Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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?

share|improve this question

3 Answers 3

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.

share|improve this answer
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
@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 8:09
See this thread for how to get a checksum that won't jump around: linuxquestions.org/questions/linux-security-4/…. 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 1 '14 at 11:28

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.

share|improve this answer

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?

share|improve this answer
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 7:30

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.