Re: Intrusion Detection Evaluation Datasets

["Jim Sansing (Ritasa LLC)" <jjsansing () verizon net>]

Damiano Bolzoni wrote:

> On 19/03/2009 1.49, Martin Roesch wrote:
> > You guys do know that anything you can't do in the Snort rules
> > language natively can be done using .so rules, right?  Write your
> > rules in C, store data statefully within Snort, manipulate things like
> > flowbits that other rules can reference, pretty much anything you care
> > to do in C.  The only thing you can't do with it is generate
> > pseudopackets for other subsystems to analyze.
>
> Marty,
> .so rules offer indeed a high degree of personalization. However, you
> need to know what you're doing...it's C code, and we all know what that
> means. I would like to see a "neater" way to do that, with something
> more similar to "normal" Snort rules. I know there is a price to pay for
> this: I won't be able to push the analysis so in depth as with a .so
> rule. But I believe a user would prefer the rule to the C code...perhaps
> I'm wrong :)


This seems to be as good a place as any to step in.

One of the goals of the Realeyes IDS project
(http://realeyes.sourceforge.net) is to detect behavior.  It attempts to
achieve this by using a multi-level rule definition format.

The lowest level, Triggers, are combined into Actions, which are in turn
combined into Events.  This means that you can monitor for SQL injection
attempts by defining several columns of the target table.  Those values
can be detected in any order and the Action will still fire.  There are
parms for setting min/max distance between the Triggers and EOL strings
such as '</script>' can be used to define groupings.

The next level allows Actions to be found in opposite halves of a TCP
session to cause Events to fire.  This means that an Action detecting an
FTP login request can be matched with multiple FTP server rejections to
detect brute force login attacks.  I've actually got this defined in the
pilot project I'm running for the project.

Triggers and Actions may be defined with the NOT flag, which allows
conditions to be set for discarding detected Events, and helps reduce
false positives.  Also, there are specialty rules, such as time
monitoring, which allows a specific server to be monitored between
midnight and 5:00 am for example.

The definitions are read by the sensors from XML files which are defined
by using the application GUI.  The most recent updates (to be released
in the next download package) handle fairly thorough context checking.

Later . . .   Jim
Lead developer of the Realeyes IDS