galacticroot
join:2004-05-17 clubs:
4 edits | Odd things reported by tripwire...OK. I've narrowed down the issue substantially and this information is misleading, so I'm starting a new thread about the real issue. I'll leave this here just for reference to the original symptom.
See: [FreeBSD] Disk read corruption issues on server.
Original post: This is on a FreeBSD server which was set up at a datacenter a few days ago. Tripwire was installed, but not properly configured prior to putting the server online. I did what amounts to an almost complete reconfiguration of tripwire after the server was online. Today, I finished setting up tripwire and noticed some odd entries in the reports. A variety of files were reported modified, which I hadn't touched since putting the server online. At first, I thought that this was due to the old database and system upgrades. However, once I got E-Mail reporting set up, I noticed files being changed, at least according to tripwire, which shouldn't be changed.
Some of the files were sensitive system files, but some were totally random, like documentation, etc... It looked like stuff from an upgrade, but I hadn't touched those files for days. Incidentally, the file modification and changed dates were both from weeks ago. These modifications are slowly appearing in reports over hours.
Now, this system is firewalled and only the SSH and HTTP power are open. There was an SSH password cracking attack on it shortly after it was set up, but password based logins were disabled. Basically, I can't see how it could have been cracked.
Nevertheless, some of the modifications are are worrying me, like the kernel image, but others just don't make sense, like random gif images in the documentation directories. The other random files make it seem even less likely that this is due to anything malicious.
I confirmed that an update is not running in the background, although it seems like that is what is happening. Of course, the modifications and change dates listed by tripwire are in the past anyway.
The fact that these changes are occurring slowly over hours makes it even stranger.
Some of the files reported modified have been: /usr/local/lib/perl5/5.8.8/mach/auto/Encode/CN/CN.so /usr/local/share/vim/vim70/doc/pi_netrw.txt /usr/bin/ex /usr/bin/nex /usr/bin/nvi /usr/bin/nview /usr/bin/vi /usr/bin/view /usr/share/doc/es_ES.ISO8859-1/books/handbook/install/fdisk-drive2.png /usr/share/info/gdb.info.gz /usr/libexec/cc1plus /usr/share/doc/ru_RU.KOI8-R/books/handbook/pgpkeys-developers.html /usr/local/lib/perl5/5.8.8/perl/man/man3/Math::BigInt::Calc.3.gz /usr/bin/objcopy /usr/share/doc/zh_CN.GB2312/books/handbook/book.html /usr/share/doc/zh_CN.GB2312/books/handbook/book.txt /usr/share/doc/zh_CN.GB2312/books/handbook/eresources.html /sbin/devd /boot/GENERIC/kernel /boot/kernel/msdosfs.ko /usr/local/sbin/tw_cli /usr/local/share/doc/gettext/javadoc1/images/interface-index.gif /boot/GENERIC/if_cp.ko
Basically, the kind of stuff modified when upgrading. I have probably modified all of these files in the past after tripwire was initially installed. I know I recompiled the kernel for SMP support on this machine, although that was before the listed modification date.
No, there is nobody else working on the server during this.
My best guess is that changes from the past are being reported again for some reason. It is possible I screwed up something with the tripwire database while setting it up again.
Any ideas as to what is happening?
EDIT: Okay, I have confirmed that the problem is NOT due with tripwire. I found that these files are actually changing. To make things even more bizarre, they appear to be randomly shifting back to their original versions. I see no processes running which could account for this.
EDIT2: Here are a couple changes which have appeared in source files: In stc.c:
< ffelex_token_where_column (ffesta_tokens[0])); --- > ffelex_token_here_column (ffesta_tokens[0])); The change appeared and then reverted to the original a while ago.
In midway.c:
1950c1950 < tmp = m_getm(m, totlen, M_DONTWAIT, MT_DATA); --- > tmp = m_getm(m, totlen, M_DONT_AIT, MT_DATA); That change occurred recently.
In binary files: /usr/bin/as:
13217c13217 < 0033a00 8955 57e5 5356 8b51 0845 108b 458b 8b0c --- > 0033a00 8955 5fe5 5356 8b51 0845 108b 458b 8b0c /usr/sbin/dnssec-signzone:
8480c8480 < 0021200 fee5 c7ff 2404 0060 0001 05e8 02f1 8b00 --- > 0021200 fee5 cfff 2404 0060 0001 05e8 02f1 8b00 And in window:
2945c2945 < 000b800 5653 d7ff c483 8510 78c0 5021 5756 73ff --- > 000b800 5653 dfff c483 8510 78c0 5021 5756 73ff then back to the original:
2945c2945 < 000b800 5653 dfff c483 8510 78c0 5021 5756 73ff --- > 000b800 5653 d7ff c483 8510 78c0 5021 5756 73ff The common thing is that just one byte was changed in these cases. |