On Sun, Nov 29, 2009 at 6:52 PM, David McGuffey <davidmcguffey at verizon.net> wrote: > 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 Are you running AIDE on a scheduled basis? It should probably be running from cron at least once a day, which will give you the partitioning you are looking for based on time. You'll know when the changes happen within a 24 hour period, which should help you track down what caused them. If it's something like prelink, then you can decide what to do about it. We did the install on our servers, and then had to spend some time tuning to make sure it was only getting the things we need. We now run AIDE every day, and the reports are usually only about a few files, if any.