Hi again, I have the next problem and I do not know how this could happen: I'm running tripwire to check my system each night, now I have a file which appears in my tripwire result as changed: /usr/lib/libc_nonshared.a But I didn't changed it! And in the tripwire-result I can only see the md5 and snefru sig's and NO st_mtime and NO st_ctime is displayed! The next night I run the tripwire-system again and now the result is OK without creating a new database!? Some days later another file was changed as the result of the tripwire told me: /usr/bin/expiry The same as described before but I see this changed file in each result until it occured the first time. Some days later these files show the same behaviour: /usr/share/terminfo/h/hp2645a /opt/kde2/bin/meinproc /usr/lib/locale/ar_EG/LC_COLLATE /usr/lib/perl5/5.6.0/unicode/Names.txt I'm running: - Tripwire version 1.2 (patchlevel 2) - SuSE7.2 This have I done before: I have secure copies of all my tripwire databases and I diff my secured against the one from the system -- it is OK, they do not differ! I took a look in all log's, bash_history and I checked the logins with last -- nothing! I am running iptables on this machine and only port 53 is open for IN and OUT. What happens on this machine? I don't think that somebody hack my system; perhaps somebody has similar problems and could help me. Many thanks and regards Ruediger InterConcept GmbH Drosselweg 27 D-61462 Koenigstein http://www.i-concept.de
ic_admin wrote:
/usr/share/terminfo/h/hp2645a /opt/kde2/bin/meinproc /usr/lib/locale/ar_EG/LC_COLLATE /usr/lib/perl5/5.6.0/unicode/Names.txt
the files belong to rpms, so you can verify with rpm if the files are really changed, if yes, check the files against the originals with diff. That makes it more possible to determine whats changed. maybe, just a fscked harddisk ...
I am running iptables on this machine and only port 53 is open for IN and OUT.
what version of bind are your running there? Are you sure that all other ports are closed? (ssh?) HTH Sven
Hi Sven,
the files belong to rpms, so you can verify with rpm if the files are really changed, if yes, check the files against the originals with diff. That makes it more possible to determine whats changed.
Sorry, I forgot to send this info: I'd run diff against the original: They don't differ!
maybe, just a fscked harddisk ...
What does this mean?
I am running iptables on this machine and only port 53 is open for IN and OUT.
what version of bind are your running there? Are you sure that all other ports are closed? (ssh?)
That's a little misunderstanding: I'm not running bind on this machine; the ports >1023 are open for dns-lookups to one special IP - this machine do not listen on port 53 but the iptables-script allows connections to my nameserver and back.
HTH Sven
Hi,
Sorry, I forgot to send this info: I'd run diff against the original: They don't differ!
the files tripwire marked as changed or the tripwire database?
maybe, just a fscked harddisk ...
What does this mean?
that your hardisk is maybe broken/damaged. Check logs for entrys like ext2 warnings or kernel hdd failures.
That's a little misunderstanding: I'm not running bind on this machine; the ports >1023 are open for dns-lookups to one special IP - this machine do not listen on port 53 but the iptables-script allows connections to my nameserver and back.
why not using connection tracking? Sven
this may be unrelated, but is this a new box? if not, did it have some kind of strange problems before? motivation for these questions: I once suspected a rooted box, since md5 sums of some system binaries changed. It was not rooted, it had a VIA (FIXME-don't remember the number) southbridge. and under heavy io it had single bitflips. yes. sometimes only on read, and then each read gave different results, sometimes on write too, so it really corupted data. workaround: switch off DMA access. (no fun on production machines) solution: change chipset. there may be similar hardware problems causing the effects you see. I don't say VIA boards are bad hardware. they are not. I just report what I experienced. /Lars On Tue, Jul 09, 2002 at 07:03:00PM +0200, ic_admin wrote:
I'm running tripwire to check my system each night, now I have a file which appears in my tripwire result as changed: /usr/lib/libc_nonshared.a But I didn't changed it! And in the tripwire-result I can only see the md5 and snefru sig's and NO st_mtime and NO st_ctime is displayed!
The next night I run the tripwire-system again and now the result is OK without creating a new database!? [ ... more the like ... ]
Hi Lars, l.g.e@web.de wrote:
this may be unrelated, but is this a new box? if not, did it have some kind of strange problems before?
It is a celeron 433MHz on VIA board! The installed OS is new and I had never problems with this machine before.
motivation for these questions: I once suspected a rooted box, since md5 sums of some system binaries changed. It was not rooted, it had a VIA (FIXME-don't remember the number) southbridge. and under heavy io it had single bitflips.
yes. sometimes only on read, and then each read gave different results, sometimes on write too, so it really corupted data.
workaround: switch off DMA access. (no fun on production machines)
I will switch off DMA and wait what happens.
solution: change chipset.
No chance ..
there may be similar hardware problems causing the effects you see.
I don't say VIA boards are bad hardware. they are not. I just report what I experienced.
/Lars
Thanks , if I now more about this problem I will post it. Regards Ruediger
participants (3)
-
ic_admin -
l.g.e＠web.de -
Sven 'Darkman' Michels