--- On Sun, 10/3/10, John P. Rouillard <rou...@cs.umb.edu> wrote:

> From: John P. Rouillard <rou...@cs.umb.edu>
> Subject: Re: [Simple-evcorr-users] new pattern type for SEC
> To: "Risto Vaarandi" <rvaara...@yahoo.com>
> Cc: simple-evcorr-users@lists.sourceforge.net
> Date: Sunday, October 3, 2010, 10:25 PM
> 
> In message <341229.52733...@web33008.mail.mud.yahoo.com>,
> Risto Vaarandi writes:
> 
> >I've also been thinking about introducing optional
> named fields for custom
> >patterns. For example, if in the first rule one writes
> >
> >  action=createpattern SYSLOG
> HOST,PROGRAM,,MESSAGE
> >
> >then the HOST, PROGRAM and MESSAGE fields will be set
> to $1, $2 and $4,
> >respectively. If in the second rule one writes
> >
> >pattern=SYSLOG MESSAGE,HOST
> >
> >the MESSAGE field will set $1 and the HOST field $2.
> This would allow for
> >rearranging the variables if needed, and making them
> more readable.
> >
> >Note that once a new line is read from an input file
> and stored into input
> >buffer, the SYSLOG pattern would cease to exist, and
> pattern=SYSLOG would
> >evaluate false (until SYSLOG will be recreated with
> 'createpattern' action).
> 
> I like it. The named fields will make things much more
> readable, and
> while flexibly setting $1, $2 ... is nice it would be even
> nicer to be
> able to use the named fields directly. With:
> 
>   type=Single
>   ptype=RegExp
>   pattern=([\w\-.]+) ([\w\-.]+)\[(\d+)\]: (.*)
>   desc=parse a syslog message
>   action=createpattern SYSLOG HOST,PROGRAM,,MESSAGE
> 
> You could specify:
> 
>   type=Single
>   ptype=custom
>   pattern=SYSLOG
>   desc=Received syslog message %(MESSAGE) from host
> %(HOST)
>   action=logonly
> 
> rather than:
> 
>   type=Single
>   ptype=custom
>   pattern=SYSLOG MESSAGE, HOST
>   desc=Received syslog message $1 from host $2
>   action=logonly
> 
> Also ideally I would like any pattern to be able to be
> assigned to
> names and used immediately. Maybe something like:
> 
>   type=Single
>   ptype=RegExp
>   pattern=([\w\-.]+) ([\w\-.]+)\[(\d+)\]: (.*)
>   rem = rather than an action, this takes place as
> soon as the pattern matches
>   assignment = SYSLOG HOST,PROGRAM,,MESSAGE
>   desc=parse a syslog message
>   action = write - parsed syslog message: %(HOST),
> %(PROGRAM), %(MESSAGE)
>  
> which allows the name assignment to be done in the command
> and used
> for substitution in the same (or subsequent) command.

It is a somewhat tricky issue. Initially I was thinking about harnessing 
%<alnum> variables for holding match variables (currently their scope is 
limited to action lists). However, this data can exist only for the current 
state of input buffer, and must be destroyed immediately after the input buffer 
gets modified. This requires extra bookkeeping. Another issues are accidental 
reuse of the same variable by different custom patterns, and accidental resets 
of %<alnum> variables through 'assign', 'eval' or similar actions. 
For this reason I was thinking about a simple naming scheme for passing match 
data directly to match variables... Another opportunity would be to allow 
$<string> match variables (I think the latest Perl regular expression engine 
supports them). However, this raises the question how to use them from the 
second half of Pair* rules where %<number> syntax is also allowed (extending 
<number> to <string> clashes with user defined %<alnum> variables).
So implementing the new functionality is not entirely straightforward...
kind regards,
risto

> 
> --
>            
>     -- rouilj
> John Rouillard
> ===========================================================================
> My employers don't acknowledge my existence much less my
> opinions.
> 


      

------------------------------------------------------------------------------
Virtualization is moving to the mainstream and overtaking non-virtualized
environment for deploying applications. Does it make network security 
easier or more difficult to achieve? Read this whitepaper to separate the 
two and get a better understanding.
http://p.sf.net/sfu/hp-phase2-d2d
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users

Reply via email to