[prelude-devel] New rules for su root attempts

[G Ramon Gomez]

I suggested an alternative in the email I just sent out, but I don't
think the approach you suggest here will work because it relies on
someone to upkeep a substitution table (which is not entertaining work
by a long shot).  In the case of something like Snort, which has the
frequently-used Bleeding Threats rules available, whoever was
maintaining this table would be constantly chasing their own tail.

- Ramon 

-----Original Message-----
From: prelude-devel-bounces at prelude-ids.org
[mailto:prelude-devel-bounces at prelude-ids.org] On Behalf Of Steve Grubb
Sent: Thursday, July 24, 2008 11:34 AM
To: prelude-devel at prelude-ids.org
Subject: Re: [prelude-devel] New rules for su root attempts

Hi,

I blew this. :)  Corrected below

On Thursday 24 July 2008 12:32:39 Steve Grubb wrote:
> Authentication, authorization, session open failures all have 
> different meaning. Failure in Authentication could be brute forcing, 
> Failure in Authorization could be someone that stole the password and 
> are now trying to get in from a remote location. Failure in Session 
> open is usually a resource problem not of the user's making.

> I'd like to describe both broadly and specifically what an event  
> means so that it can be used in more ways.

What I mean by the above is somethings like "general.fine" as the event
category. Where general can be big broad categories that abstract the
event's specific's away, while fine could give very specific meaning. So
you could have some thing like:  authentication.login or
authentication.credentials where both describe that authentication was
done, but in one case it was a login, the other is su.

I think the only way to enforce consistency is by API where you use a
define that looks up the exact text and substitutes it.

-Steve


_______________________________________________
Prelude-devel site list
Prelude-devel at prelude-ids.org
http://lists.prelude-ids.org/mailman/listinfo/prelude-devel