On Sun, 2009-11-29 at 20:31 +0000, John Horne wrote: > On Sat, 2009-11-28 at 18:57 -0500, David McGuffey wrote: > > Starting with a fresh load and after I finish hardening the load > > following the Center for Internet Security (CIS) guidance, I'm wondering > > whether AIDE or OSSEC would be a better intrusion detection system. > > > > I installed AIDE and did a quick test of AIDE and after initializing the > > db and applying the recent cups update, I found that 1700+ files had > > changed. Those are a lot of changes to wade through to determine if > > they are legit or not. If that is all that AIDE can do, then it is not > > "manageable." > > > > Seems to me that any IDS must be tied to the yum update process so that > > one is not dealing with hundreds/thousands of changes that were brought > > in by a yum update that I choose to apply. > > > > Is OSSEC any less noisy? > > > More so as far as I can tell. > > Don't forget that prelinking will cause files to regularly change their > hash value whether they have been updated or not. Aide does have a patch > to cater for prelinking (as far as I know it is not in the current > release so you'll have to search their archives for it). OSSEC does not > know about prelinking, so will frequently report files having changed. > > Shameless plug: You could take a look at rootkit hunter > (http://sourceforge.net/projects/rkhunter/), its file properties testof > knows about prelinking and can use the local RPM database to verify > files, so an updated file won't be flagged as having changed unless > someone has deliberately changed it. > > Another alternative is Samhain. As far as I remember it can handle > prelinking, but will report updated files as having been changed. Thanks. I'm not looking for a "tech" solution so I can sit on my butt and let the tools do their magic. What bothered me was that I did the install, configured the load the way I wanted it, ran AIDE to init the db. A couple of days later, the CentOS list informed us that cups needed to be updated. I did the update and immediately ran AIDE to see what changed. That cups update changed nearly 1,700 files. That caused me to think...there should be a way to tie the IDS to the patching (that I deliberately authorized), so that the changes related to the patching are either ignored, or collected at the end of the report under the header something like: "The following changes appear to be tied to authorized patching activity...if you did not authorize these changes, then find out why they changed..." I still want to see the changes, but it would be nice to see the ones I authorized through the update service to be partitioned off from the ones that seem to have no reasonable explanation. DaveM