strange tripwire entries
 

I'm maintaining a Fedora Core 3 system that runs tripwire nightly. The tripwire entry from this morning showed that a number of system binaries had been modified:

I ran ls -l on some of them, and their modification dates are from months ago or last year. I also checked the RPMs that some of these binaries were originally from (rpm -qf and rpm -qi), and they were also installed months ago or last year. rpm -V doesn't give any results for the most part. This computer runs yum update nightly, but /var/log/yum.log doesn't show these binaries or their RPMs being updated. SSH logs haven't shown any funny logins. Only IP addresses belonging to the college where I work can log in via ssh, and ftp and telnet are not running. Any ideas on what could be causing tripwire to report changes in these binaries?

Thanks!
S. Chen

What part of the tripwire check is failing, MD5sum, timestamps? Do the modification times on those binaries appear to approximately correspond with any of the yum updates?

The tripwire check is failing on the MD5 sums. The observed MD 5 sum differs from the expected, and the observed number of blocks for these binaries is also less than expected. The expected and observed modification timestamps and file sizes match. Most of the timestamps are from 2004. The log for the recent yum updates doesn't show anything about the RPMs for the binaries in question. A few days ago a new kernel was installed, but tripwire only started showing these changes in last night/this morning's run.

I just looked through the logs and installed chkrootkit... haven't come up with anything. Netstat doesn't show anything suspicious, and nmap from another machine didn't come up with any unusual ports open.

Did /etc/prelink.cache change by chance too? It so, this is probably a bunch of new binaries that got prelinked.

Exactly what I was thinking...might also want to try to undo prelinking on a few of the binaries with "prelink -au" and see if they come back clean.

Yes, the tripwire reports were due to prelinking. prelink.cache was being updated. After I changed /etc/sysconfig/prelink to set PRELINKING=no, the reports came back clean.