2

rkhunter reported a single file change on a virtual server (netstat binary). It didn't report any other warning. The change was not the result of a package upgrade (I reinstalled it and the checksum is back as it was before).

I'm wondering whether this is a file corruption or an intrusion. I guess an intrusion would have changed many other files watched by rkhunter (or none if the intruder had access to rkhunter's database).

I disassembled both binaries with objdump -d and stored the diff here: https://gist.github.com/3972886

The full dump diff generated with objdump -s is here : https://gist.github.com/3972937

I guess a file corruption would have changed either large blocks or single bits, not small blocks like this.

Do these changes look suspicious? How could I investigate more?

The system is running Debian Squeeze.

RichVel
  • 3,524
  • 1
  • 17
  • 23
Michaël Witrant
  • 338
  • 3
  • 5

2 Answers2

4

I spot checked a few of those, and they all appear to be single-bit errors. At this point I'd consider replacing the hard drive, using RAID/ZFS, etc.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
3

I agree this isn't an intrusion, but a hardware error of some sort.

I would also consider whether you have a failing RAM stick, and run a memtest86 on the host server - single-bit errors could also be non-ECC RAM errors. If you have ECC RAM, you can rule this out (every server should use ECC RAM of course, and preferably ZFS to detect RAM and disk corruption).

It could also be a disk controller error.

Generally it's worth checking your logs for controller and disk errors, and try to isolate the cause of the bit-flipping - is it only on one disk, does it still happen if you swap RAM sticks, etc.

If you have a backup tool that does checksumming of data blocks or files, that would act a bit like ZFS to detect wider corruption across more than this single file.

If this is an important server, just replacing the RAM and disk would be a quick option, letting you test them in a non-critical system offline.

Some background from a CERN study: http://storagemojo.com/2007/09/19/cerns-data-corruption-research/

RichVel
  • 3,524
  • 1
  • 17
  • 23