On Nov 29, 2009, at 3: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. Seems to be that a yum plugin could be written that would accomplish this. Consider - it would only allow signed rpm updates, and ask for permission (or use a key) to update to LIDS database...