Re: Strange tripwire behaviour

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff Kinz wrote:

Scott is correct on both counts, prelink is the likely culprit, but
don't discard the idea of a very thorough intrusion effort.

If it was intrusion, and rootkit installed was that thorough to actually replace tripwire binary, than he probably wouldn't see the change in tripwire binary either.


Of course, being a bit paranoid never hurts.

BTW, a bit of topic. Tripwire as tool for detecting RAM problems. Some time ago, tripwire detected a change in single bit in one shell script. Upon examining the file, one " character (double quote, hex code 0x22) was changed to "2" character (hex code 0x32). But only when looking at the file through the file system. Partition was mirrored, and checking the files directly from each of submirrors (simply mounted each submirror in read-only mode) showed unchanged file. After running "memory intensive program" to clean the cache, voila, looking at the file at the file system showed original file. Apperently, machine had enough RAM to cache all files checked by tripwire and keep them in cache for weeks (never read them from disk, other when machine is booted). Because of the bad RAM chip (verified, running memtest86 on that memory module for couple of weeks showed errors occuring after long periods of time), one bit flipped. Had there not be tripwire, memory problem would be undetected (memory in question was not ECC).

So, giving extra $$$ for ECC memory and motherboards that support it isn't a bad idea after all... Not all memory problems will make your machine crash. You may be running bad memory module for months or years before realizing it.

I also have a similar story when tripwire detected problems with Linux RAID1. One night tripwire would report one file changed, the other night reported it unchaged. And it went on flipping for some time. What happened was that machine had crashed when that file was accessed, and mirrors went out of sync. Upon booting, (an early version of) MD driver hasn't detected the problem and considered submirrors to be in clean state (ooops). But tripwire did, since each night kernel randomly gave it a copy from either first or second submirror. Tripwire as tool for detecting kernel bugs ;-)

Thinking of it, I don't recall reporting the bug. Who knows, maybe it was never fixed 8-\

--
Aleksandar Milivojevic <amilivojevic@xxxxxx>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux