[Snort-users] Dynamic Rules in CVS, reruns at 11

Dragos Ruiu dr at ...333...
Thu Aug 24 21:27:47 EDT 2000


> dr's comments and answer's inset.
> here is a re-run from an old message from Marty
> announcing dynamic rules in the CVS tree a while
> back but it's been mostly overlooked.
>
> at the end of this You'll find the original e-mail that
>  spawned this question and my answers inset

--kyx--


From: Martin Roesch <roesch at ...2...> on 04/24/2000 02:38 AM
> To:   Snort <snort at ...9...>
> Subject:  [snort] CVS updates (dynamic rules!)
>
> There have been several updates to the version of Snort currently
> available in the CVS repository.  The biggest new thing in tonight's
> update is *dynamic rules*!
>
> That's right.  The dynamic rules functionality is still kind of limited,
> but I think this is along the lines of what people have been asking
> for.  It works like this:
>
> There are two new rule types, activate and dynamic.  Activate rules act
> just like alert rules, except they have a *required* option field:
> "activates".  Dynamic rules act just like log rules, but they have a
> different option field: "activated_by".  Dynamic rules have a second
> required field as well, "count".  Put 'em together and they look like
> this:
>
> activate tcp !$HOME_NET any -> $HOME_NET 143 (flags: PA; content:
> "|E8C0FFFFFF|\bin|; activates: 1; msg: "IMAP buffer overflow!";)
>
> dynamic tcp !$HOME_NET any -> $HOME_NET 143 (activated_by: 1; count:
> 50;)
>
> When the "activate" rule goes off, it turns on the dynamic rule it is
> linked to (indicated by the activates/activated_by option numbers) for
> "count" number of packets (50 in this case).
>
> Ok, this functionality is kind of neat, but the initial implementation
> is pretty limited.  At this time, there's a 1 to 1 correlation between
> activators and activatees.  You can't specify lists of rules to turn on
> (yet) from a single activate rule.  Additionally, the granularity of the
> dynamic rules is pretty coarse.  For example, if that buffer overflow
> did come in and activate the dynamic rule, all IMAP traffic from
> !$HOME_NET to $HOME_NET would be recorded.  I'm not quite sure how to
> implement something that would be more precise at this point, but I'll
> think about it for a bit. (suggestions welcome!)
>
> This code hasn't been tested extensively, so please keep that in mind if
> you're going to download it.  That said, I'd appreciate feedback from
> anyone who decides to try it!
>
>      -Marty
>
> --
> Martin Roesch                      <roesch at ...2...>
> Director of Forensic Systems     http://www.hiverworld.com
> Hiverworld, Inc.       Continuous Adaptive Risk Management    


FWD from Marty: Robert E. Leever wites....

Hi Marty,

Don't know if you've seen my wish list for snort or not,
but ... I want to be able to write a rule that once triggered
by -a- packet will *activate* a 2nd rule.  The 2nd rule would
be in a *suspended* state until then, -- ie part of the rule chain,
but never *applied* to any packets, just skipped over.

The second rule would also be able to have variables in it 
that could/would be setup by the first/triggering rule.
ie the source address of the triggering packet would be a good example.  

> see my proposal on variables on this list

I could then write a general rule that once triggered would
activate a 2nd rule that would then log ALL packets from the
specific triggering source address.  

For more or less obvious reasons the /first/ rule would have
to *suspend* itself until the 2nd rule *decides* to re-activate
the first, and then suspend itself.  [timeout, counter, ?]

I've sorta kinda decided that if I want the functionality
of being able to have a packet trigger a new rule, then
I'll have to write it myself.

I've found ParseRuleOptions in the code, and think that I
can modify it with a "NEWRULE:" option.  

Since you state that the rule parser itself is recursive,
at that point I should be able to just extract the new-rule
from between the quotes [or whatever] and call the rule parser
again.  that will put the new rule into the linked list.

I will also need to modify the rule structure and add a few 
items.  first, I will need a pointer to the new-rule in the
triggering rule. Which means that the rule parser has to be able
to return the link-list-pointer -- tis a void right now.  

I will also need to put in an active/suspended boolean.  
If a rule is suspended then when applying the rule to
the packet the first thing you'd look at would be that switch,
going on to the next rule in the chain if *this* rule is suspended.

Question, where are the rules applied to each packet? 
I hope it's not in a dozen differnt places.  -- altho, that is
what I suspect from my cursory examination of the code.

> in the main pcap loop in the Process routines.

> No, there is one main loop with several rule chains
> followed on a per packet basis.

I also want to add a packet count to the rules structure[s]
so that I will be able to tell how many packets have triggered
this particular rule.  Reason?  so that I can suspend the 2nd
rule after so many packets have triggered it, and re-activate
the original triggering rule.  which means that I will also have
to keep the original count - so.. a counter and the count has to
be added to the rules structure[s].  And I have to be able to
tell which of the rules is the primary/triggering rule and which
is the triggered rule.  either a bit in the pointer  or another
boolean in the structure [which imho is cleaner].  

So... having explained all this and taken up your time, 
can you point me at any documentation on the rules structure[s]?

> rules.c is a good starting point.


and could you give me a hint about where the rules are applied
to the packets?  

> see above

thanks

b;) Leever               [b;) eversince Microsoft copyrighted Bob]
Senior System Admin
Objective Systems Integrators, Inc

ps.  yup... add me to the growing number of snort enthusiasts.
pps.  The counter idea has also been put into the wish list already.
so we can have "Last message repeated NNNN times".


-- 
dursec.com ltd. / kyx.net - we're from the future
pgp fingerprint: 18C7 E37C 2F94 E251 F18E  B7DC 2B71 A73E D2E8 A56D 
pgp key: http://www.dursec.com/drkey.asc



More information about the Snort-users mailing list