On Nov 29, 2009, at 3:52 PM, David McGuffey
<davidmcguffey@xxxxxxxxxxx> 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...
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
