I am using tripwire to detect intrusions, but the nightly yum updates make tripwire report a lot of changes. These changes are uninteresting and I'd really rather not have to check them.

Wouldn't it be smarter if tripwire had an option to query rpm to check if the change wasn't an authentic package update?

Then it need only report
(changed files) minus (files affected by yum)

Does anyone know if this already possible?

No it ain't possible at the moment AFAIK and it ain't gonna work anyway: no integrity checker knows the difference between a benign or a malicious "update". Changes should be noticed, the cause known and be verified.

OK. So let's be honest about it then: intrusion detection with nightly updates are totally impractical. Only those aspiring to really tight systems need bother and then they need plenty time on their hands to check every change. Most users do not have an hour a day to do this!

So let's be honest about it then: intrusion detection with nightly updates are totally impractical.
Here being "honest" really seems a misinterpretation for wanting convenience without the "hassle", wanting the sweet but not the sour. There are ways to make things easier, but to keep systems in check the chores still have to be done. And wetware (still) is the only one to do that "better". Compare it to using a (N)IDS: you expect it to alert on whatever rules are configured to trip an alert, but ultimately the interpretation and classification of the reports and data as being a slow sweep or multiple isolated "incidents" is a human one. No machine can or should make that decision (marketoid drones will say otherwise, of course).

So let's focus on making things easier. If you have a distribution sporting a somewhat evolved package management system it would be rather trivial to script a report to help facilitate easier checking of changes. Also, at least with the integrity checker I use, it's kinda easy to use separate profiles for different parts of the filesystems. The first thing though is to configure to only include what you need to monitor and to adjust to alert to what's necessary. Reasoning the other way around, choosing a stabilised distribution over a bleeding edge one will cause much less stress with respect to tracking changes.


Only those aspiring to really tight systems need bother
It always is a trade-off between systems usability and security. Any seasoned admin will agree that (in production systems anyway) change is bad with respect to stability. Less change means easier systems management.
If your systems are that volatile they keep changing every day, and you maintain you need to keep that distribution release and you maintain you can not adjust your checker, and you maintain you can not use anything in the above to make systems management easier then yes, you have a point. Luckily security is not based on the use of one application nor is defense based on one layer.

But please do not pass off your conclusion of your situation as speaking for "most people". You are *not* most people.

I only check my logs (including rootkit reports and tripwire reports) daily - I don't do updates daily.

If you schedule and batch your non-critical updates you can do the updates and keep tripwire happy:
- Download updates as they become available but don't install immediately;
- Schedule one day per month (or week if you have the time) for installing updates;
- Take the box off the network;
- Change to single user mode;
- Install your software updates;
- Update your tripwire database. You can accept all the changes because they're all due to your update process;
- Test that everything is OK;
- Put the box back online.

Doing it this way can also reduce the occurence of having to install multiple patches for the one fix when patches get re-issued. You also get a chance to read changelogs - there's a risk with auto-installing changes as soon as they are available...

Well, I thought computers were supposed to make our life easier and not keep as chained to the screen checking logs.

The thing is, package management systems (like rpm) do a good job of monitoring system files, where they come from, when they were last supposed to have changed, etc. This information can easily reveal tampering.

The problem is that the package management system can be tampered with, so that we can't trust it to provide the true results. But if we can protect the packagement management system then it seems logical that we can detect tampering of the system files.

The problem of detecting unauthorised changes to system to files can then be broken down into two steps:

1) Check the package management system hasn't been tampered with (use IDS like tripwire with offsite database)

If ok, then proceed to

2) package management system checks files and reveals those that shouldn't have changed.

And preferably packages updates come from a trusted source and must be signed.

Absolutely. But if the tools to monitor those changes automatically are already in place, then perhaps we should use them.

My point is: using tripwire to monitor all system files is laborious when there are frequent updates. But tripwire and rpm could be used in conjunction with each other to detect intrusion more cleverly.

Hope that makes sense...

This would be good if the updates could be automagically split into critical and non-critical. I'd still like patches to ssl, apache, made asap.