[Lognorm] Libnormalize issue

[James Lay]

>
> The rule does not match, because "(Unhandled..." is not matching the
> sample.
> So it did not extract any fields at all.
>
> I'll elaborate a bit later why we need to have perfect matches. Think
> about
> false positives...
>
> rainer

Thanks for responding so quickly.  As I look at my test setup, I see that
you are spot on...if it doesn't match the WHOLE thing, nothing gets
parsed.  That leaves me with two options as it relates to the below
examples:

IN=ppp0 OUT= MAC= SRC=121.11.80.101 DST=my_ext_ip LEN=40 TOS=0x00
PREC=0x00 TTL=108 ID=256 PROTO=TCP SPT=6000 DPT=1433 WINDOW=16384 RES=0x00
SYN URGP=0

IN=ppp0 OUT= MAC= SRC=121.11.80.101 DST=my_ext_ip LEN=40 TOS=0x00
PREC=0x00 TTL=108 ID=256 DF PROTO=TCP SPT=6000 DPT=1433 WINDOW=16384
RES=0x00 SYN URGP=0

Easy to miss, but the DF there is where I have an issue...some have it,
and some don't.  Without a regex to ignore junk (LEN=.*DF), then what are
my options?  I can create 2 different rules, one to match the above with a
%DF:word%, and one without, but now I have two seperate entries for pretty
much the same info...not optimal.

I'm guessing that my questions and comments are from my ignorance of how
this all works.  From my dealings so far with Sagan, it looks like my rule
file should match first, then send to normlize yes?  I would think that
would reduce false positives since my rule has already done the job of
matching, and liblognorm's job is to parse out the specific info..yes? 
Again, maybe I'm TOTALLY missing something.

I'll continue to test this out...my goal is corelate snort entires with
firewall rules, but so far it's been an uphill battle.  Again, thanks for
any light you can shed, and for taking your time to make liblognorm.

James