rkhunter warns of inode change but no file modification date changes

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.

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.