> --- 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 >
I think I've found a way to create named match variables which complies with Perl syntax, and does not create clashes with existing naming schemes. I'll only need to experiment with it a bit :) BR, 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 > > ------------------------------------------------------------------------------ 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
