Re: A "Flowbits" issue

[Jason Brvenik <jasonb () sourcefire com>]

None that I'm aware but if you will send me your config and rule I'll
happily have a look.

tung tran wrote:
> Hi,
> I got a "Segmentation fault" with Snort 2.8.0.1 when I tried to
> declare a new alert type, configured the order and used it in a rule
> as you suggested. Is it a bug in Snort 2.8.0.1?
> Thanks,
> Tung.
>
> On Dec 2, 2007 7:02 PM, tung tran <tunghack () gmail com> wrote:
>   
> > Great explanation !!!
> > Thanks,
> > Tung.
> >
> >
> > On Dec 2, 2007 3:37 PM, Jason Brvenik <jasonb () sourcefire com> wrote:
> >     
> > > tung tran wrote:
> > >       
> > > > Hi,
> > > > My question is:should we use "flowbits" to check a packet against
> > > > multiple rules or we only use "flowbits" to check next coming packets?
> > > >         
> > > yes but...
> > >
> > > The behavior is not guaranteed and it's effectiveness is dependent on
> > > the order of the rules. You must have the flowbits:set before the isset.
> > >
> > > Given this constraint, there is generally no reason to do this because
> > > in order for them to match, the same packet must have both qualifying
> > > contents.
> > >
> > > Except...
> > >
> > > When there are multiple paths to a single end state for the final rule.
> > >
> > > EG:
> > >
> > > content:"bob"; flowbits:set,seen.suspect.user;
> > > content:"alice"; flowbits:set,seen.suspect.user;
> > > content:"jane"; flowbits:set,seen.suspect.user;
> > >
> > > flowbits:isset,seen.suspect.user;content:"ccdata";
> > >
> > > In this case we are looking for suspect users that are accessing credit
> > > card data. It will immediately flag the packet(s) provided that they are
> > > ordered correctly in the rules file.
> > >
> > > You could just as easily use a single PCRE to locate the users but there
> > > would be a different performance profile involved.
> > >
> > > If you want to ensure that the rules are always evaluated in the desired
> > > order you can define new rule types.
> > >
> > > ruletype alert2
> > > {
> > >  type alert
> > > }
> > >
> > > Then use rules as folows.
> > >
> > > alert tcp 192.168.0.1 any -> any any (msg:"Seen bob"; content:"bob";
> > > flowbits:set,seen.suspect.user; sid:1000000; rev:1;)
> > >
> > > alert tcp 192.168.0.1 any -> any any (msg:"Seen alice"; content:"alice";
> > > flowbits:set,seen.suspect.user; sid:1000001; rev:1;)
> > >
> > > alert tcp 192.168.0.1 any -> any any (msg:"Seen jane"; content:"jane";
> > > flowbits:set,seen.suspect.user; sid:1000002; rev:1;)
> > >
> > > alert2 192.168.0.1 any -> any any (msg:"suspect user access of ccdata";
> > > flowbits:isset,seen.suspect.user; content:"ccdata"; sid:1000003; rev:1;)
> > >
> > > and then set order using either -o
> > >
> > > or
> > >
> > > config order: pass drop alert alert2 log
> > >
> > > The cases where you might want to do something like this are extremely
> > > rare but I've seen them in the past.
> > >
> > >       
>
>   


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users