[Snort-devel] Outputting info about a rule that fires

Joe McAlerney joey at ...63...
Fri Feb 23 21:00:45 EST 2001

"Crist J. Clark" wrote:
> On Fri, Feb 23, 2001 at 03:54:07PM -0800, Joe McAlerney wrote:
> [snip]
> > Snort will have to be able to handle reference, priority, and other
> > information internally anyway.
> That depends on how you define "snort."

As the entire application itself.  Not just the core pattern matching
> > This is done in the form of plugins,
> Herein lies the problem. Is a plugin really "part of" Snort?

The whole Snort lightweight intrusion detection system?  I think so.

> Do we
> require that "snort" provide all of the facilities that an arbitrary
> plugin needs? Sounds like a recipe for rampant featurism, bloat, and

I'm not really sure what additional facilities need to be added.  I
probably wasn't clear, and I apologize if you already know this - I'm
just core dumping.  An input plugin hooks into Snort without needing to
change any additional Snort code (with the exception of #includes, and
function calls in plugbase.[c,h]).  That lets you register keywords for
Snort rules if you so desire.  For example, the sp_reference plugin
registers the rule keyword "reference", and stores reference information
in a location where memory has specifically been allocated for plugins. 
Again, no need to tweak existing code.  That information is available to
output plugins to use if they want, and to ignore if they so desire.

> how do you divine what features every possible plugin could want in
> the first place.

They are limited to what is available to them.  The IDMEF XML output
plugin needed reference information, and thus the reference plugin was
born.  Now that information can be used by any other output plugin.  Am
I missing your point?

> IMHO, "snort" should be the central engine that grabs packets,
> compares them against the rules, and if it matches a rule, the packet
> and the rule info is passed to the output routine.

I assume you are defining "snort" as the core snort pattern matching
engine, along with preprocessors and input plugins.

> Now, snort already has some simple output routines, but the real
> growth and what this thread is talking about is specialized output
> plugins. I would like to keep the plugins and the central snort engine
> at a distance.
> Ask yourself, what does the output plugin need to know about the rule?
> Well, you really cannot say since any possible plugin could want to
> know just about anything. Here is all I think the snort engine needs
> to do:
>   The snort engine needs to pass a unique identifier of the triggered
>   rule to the output plugin.
> The rest is up to the plugin.
> This makes snort more modular and more customizable. Let's just say
> every Snort rule may have a unique 8-byte value associated with it,
> say four ASCII chars followed by an int. This thing is called a "tag."
> This tag is made available to any output plugin. A plugin may have its
> own configuration mapping a Snort rule tag to whatever values the
> plugin associates to the rule.
> > ...and
> > for the reference information, has already been put to use with the
> > IDMEF xml plugin.  Not only do I want to be able to view my alerts based
> > on priority,
> The plugin can do it on the backend. Your plugin has its own mapping
> of Snort rules that it gets from a config file, a hardcoded table,
> from ESP, whatever,

So when rule sets get updated, every plugin has to update it's mapping
file?  And people using 5 output plugins have to download 5 different
mapping files?  ouch.

> In addition, something like a priority is a very subjective
> value. This could be a very site-specific file. The role of tagging a
> priority to a brand new rule distributed with Snort, ArachNIDS,
> etc. is not left to the individual writing capture rules (and since
> the person writing the rule is probably concerned about the sig, I
> would expect rules to skew to high priorities if left to the
> creator).

Here's how I envision it.  The rule writer can choose whether or not to
include priority information in the rule.  When you download the rules,
you can choose whether or not to include (or update according to your 
policy) priority information in the rule.  When the output plugin gets
the alert, it can choose whether or not it wants to use priority
information (assuming that the particular rule includes it).  It is a
working system.  Excerpt from spo_idmef.c (IDMEF XML output plugin):

  /* Extract reference information for Classification url's. ... */

  for(rd = (ReferenceData *)otn_tmp->ds_list[PLUGIN_REFERENCE_NUMBER];
      rd != NULL; rd = rd->next)
       ... /* do stuff with rd */


> > I want them to be able to be processed based on priority.
> > This is something that an output plugin can do, and would not be able to
> > do if all the work is done on the back end.
> Now, this is a hard problem. And what exactly do you mean by processing
> them based on priority?

Ok, a simple example.  I have some output plugin that stores alerts in a
file, and in addition, throws winpopup messages up on the screen of each
network admin when a priority 5 alert comes in.  They are free to set
priorities to their liking in the rules file.  Just the same as being
able to pass on rules that produce too many false positives.

> Again, to be as general as possible, rather
> than add a facility for processing according to a "priority" value,
> there should be a separate mechanism soley devoted to allowing the
> user to force the rules to be processed in an arbitrary order
> (assuming a match-then-out approach) of his chosing. Using "priority"
> is probably too limited as an approach.

I'm not talking about some mechanism where Snort's rules matching engine
matches packets based on priority levels.  Everything I'm referring to
is completely independent of Snort's current rules pattern matching
functionality.  That's a whole other story; albeit an interesting one.

> But that's just all IMHO.

Mine too. :-)

-Joe M.

+--                            --+
| Joe McAlerney, Silicon Defense |
| http://www.silicondefense.com/ |
+--                            --+

More information about the Snort-devel mailing list