Among other measures, we have rkhunter going on a couple of servers.

rkhunter on both servers reported a "suspicious file". Specifically:

Warning: Suspicious file types found in /dev:
     /dev/shm/R1Soft-SHM-ZocPNFWuCcEl2rrN: data

This corresponds to a regular package update to R1Soft from just before this alert appeared. However, rpm -qf indicates that this file is not owned by any package.

I am reasonably satisfied that this is a false positive, given that the timing corresponds with a package update of a piece of mainstream software, and it did so identically on two unconnected servers. The bit of doubt I have is really that a few days have gone by, and I don't see anybody else reporting the same issue.

My main question is:
What sort of steps can we take to definitively verify that this is a false positive?

If we can do that, I would happily white-list it in rkhunter.


Why are you having rkhunter scan /dev?

If rkhunter works by calculating a hash on each file in a directory then comparing recent hash results against a database of original hashes, AND /dev is your device directory (so a non-normal filesystem), then /dev/shm is a shared memory device and not a static file.

Of course a hash on /dev/shm (shared memory) could be ever changing and producing alerts since it may not be static data. As what's stored in that shared memory device changes so will its calculated hash change.

Consider prohibiting rkhunter from scanning some of these non-normal filesystem directories in Linux (such as /dev) by adding /dev to the preclusion list.

This has very little to do with your yum update.

  • Thanks for moving the comment here. I do agree generally all of it, except that I'm not sure it has nothing to do with the update given the timing - months went by without an error like this, but right after the update, it began. However, the file itself is not connected to the update, so it is a side effect of functionality change. – SCruz Dec 27 '16 at 0:32
  • 1
    The update may have influenced what was in the /dev/shm (shared memory). The thing that caused the rkhunter alert was the change in what was in /dev/shm and the update only indirectly. – user34445 Dec 27 '16 at 0:33
  • As a followup, I have added (tentatively) the file to rkhunter's whitelist (incidently, the default configuration has a few other files in the /dev/shm directory whitelisted). I also scanned the file with ClamAV, and for what it is worth, it didn't find anything wrong with it. – SCruz Dec 27 '16 at 0:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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