[prev in list] [next in list] [prev in thread] [next in thread] 

List:       prelude-devel
Subject:    Re: [prelude-devel] Re: An IPv6 theory
From:       Yoann Vandoorselaere <yoann.v () prelude-ids ! com>
Date:       2005-06-09 8:35:18
Message-ID: 1118306119.9866.75.camel () titane ! prelude-ids ! org
[Download RAW message or body]

On Thu, 2005-06-09 at 09:52 +0200, Herve Debar wrote:
> Gene R Gomez wrote:
> >>LML ruleset are already not easy to maintain, and that would, IMHO,
> >>increase the maintainance pain. The solution I'm thinking about is
> >>rather to have the ability to inline function call from a rule:
> >>
> >>source(0).node.address(0).address=$3; \
> >>source(0).node.address(0).category=ip_to_category($3); \
> > 
> > 
> > This would work well to solve the problem at hand for me.
> 
> If you go that route, I think allowing the value tu be set by the return 
> value of a regular expression applied on a variable is more flexible 
> (see my former message and the possible definition of a perl-like =~ 
> operator -- however the syntax and semantics would need to be worked 
> out). 

The advantage of inlined function is that they are much more flexible in
what the "code" does. As an example, an inlined function could fill some
missing IDMEF field from the input it is given (address -> node name,
etc.). 

They could also be used to make some security check on hostname that we
read from logfile, etc. 

PCRE condition have their advantage too, being more flexible to the
signature writer, albeit people might start to have a real hard time
reading rulesets.

In the end, probably both could be implemented in LML, since they solve
differents problems.

> The issue you are pointing out here for addresses is applicable to 
> all fields.

Yes, at least to enumeration member defining the datatype contained by
another member.

-- 
Yoann Vandoorselaere | Responsable R&D / CTO | PreludeIDS Technologies
Tel: +33 (0)8 70 70 21 58                  Fax: +33(0)4 78 42 21 58
http://www.prelude-ids.com


[prev in list] [next in list] [prev in thread] [next in thread]