On Nov 29, 2009, at 3:52 PM, David McGuffey davidmcguffey@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...