SUMMARY: Tripwire False Reports

I set up Tripwire on a test server to try it out before moving it on to
the reset of our servers.  After installation we had no false reports
until we installed our backup software.  Every night I was getting a
report saying all files that Tripwire was monitoring had been modified. 
Updating the database would give clean results for an immediate run but as
soon as a backup took place all files were reported as modified.

Tripwire can be set to ignore the ctime attribute which appears to be what
the backup software (Tivoli Storage Manager) was changing.  Tripwire still
monitors the inode number, CRC checksum and MD5 fingerprint of all files
so changes are still detected in a far more difficult method to fake.

The -c flag tells Tripwire to ignore the ctime of files and just perform
the rest of its checks.  I just added this flag to each section of the
twpol.txt file and reloaded the policy.

SEC_CRIT      = $(IgnoreNone)-SHa ;  # Critical files that cannot change
to
SEC_CRIT      = $(IgnoreNone)-SHac;  # Critical files that cannot change

...and so on for the rest of the security classes.  Tripwire now comes
back clean each night and only reports expected changes.  Perfect!

By far the most helpful thing I got was the twprint command.  I was
previously unfamiliar with this command.  It will print a report from
Tripwire log files so you can see exactly what triggered the errors.  In
my case I used it like this:

twprint -m r -t 4 -r /var/lib/tripwire/<reportname>

The -m option sets the mode (-m r = report), -t sets report level (level 4
in this case) and -r to specify the report file itself.

Thanks to Tom Yates who had the winning solution.  I also received advice
from Boris Jordanov and Phil Schultz suggesting that I check the atime
settings for Tripwire.  Turned out not to be the problem in my case but I
can easily see someone setting up Tripwire a little to restrictively and
getting lots of errors from that.

Bryn

Original question below:

> I'm running Tripwire 2.3.1 on a Red Hat 7.3 server.  I get reported
> violations for ALL files on the server every night.  It appears our
> backup software must be making some subtle modification to the files
> which is enough for Tripwire to pick up.  Basically every time I
> re-initialize the database the reports are clean until a backup runs at
> which point I get a report saying everything has been modified.  This is
> my test server for Tripwire so I need to know if this can be resolved or
> if I should just scrap TW.
>
> Anyone had similar problems to this?  Know anything that can be done?
> I'm using the default Red Hat 7.3 Tripwire configuration with just the
> binaries we don't have commented out in the policy file.
_______________________________________________
LinuxManagers mailing list - http://www.linuxmanagers.org
submissions: LinuxManagers-35TzE1X9F6582KRnZfj+bdi2O/[email protected]
subscribe/unsubscribe: http://www.linuxmanagers.org/mailman/listinfo/linuxmanagers