[Snort-devel] Looking at rule metadata from an output plugin

Ryan Jordan ryan.jordan at ...402...
Thu May 28 12:02:12 EDT 2009


Alan,

First off, let me make sure I'm correctly understanding your goal. Are you
trying to set an option while defining a rule, which will then get passed to
your output plugin when that rule alerts?

The following inline comments are based on that assumption. Please correct
me if I'm wrong.

On Wed, May 27, 2009 at 10:45 PM, Alan M. Carroll <
amc at ...3043...> wrote:

> I am working on an output plugin for Snort 2.8.4 and it would be handy to
> have access to metadata. However, looking at the code it appears that rule
> metadata that is not used by Snort is discarded and not available.


The "metadata" keyword is good for setting options in an OptTreeNode. The
metadata string gets discarded at this point because it has already been
parsed, and the values in otn->sigInfo have been filled out.

>
> One approach would be to use some other parser logic to read the rule file,
> extract the metadata, and then use signature identifiers to match up but
> that seems a bit redundant, especially for something that is compiled in to
> Snort, whose parser already fully parses the metadata.


That's definitely redundant.

>
> My current plan is to augment ParseMetadata to have a list of name/function
> pairs. After checking the known metadata keys, if unmatched it would
> traverse the list comparing the key to the strings. Upon a match, the
> corresponding function would be called and passed the OptTreeNode, the key,
> and the value (all of which are in local variables by this point). Then I
> would add a "RegisterMetadataHandler" function to allow plugins to populate
> the list.


If you want to add more metadata key/value types, take a look at the
#defines in the top of parser.c. You'll see a bunch named
"METADATA_KEY__FOO" or "METADATA_VALUE__FOO". Then, in the function
ParseOtnMetadata, add more cases to the if/else block and call whatever
function you want. I don't think it's necessary to keep a separate list of
key/value pairs, nor is it necessary to provide a "RegisterMetadataHandler".

>
> I am left with three questions:
>
> 1) Is this a reasonable approach?


That's hard for me to determine without knowing what your ultimate goal is
here. I would venture that whatever you're trying to do, there's probably a
cleaner way than repurposing the pre-existing "metadata" field. If you're
going to modify Snort, you might as well go whole hog and add your own
option type.

>
> 2) Would anyone else be interested in it, i.e. should I plan on making it
> robust enough for others to use?


> 3) How should my plugin interact safely with the ds_list member of
> OptTreeNode? Presumably it needs to get a globally unique index, but how is
> that done?


There's an enumerated type in plugin_enum.h.  Add your index in there,
before PLUGIN_MAX.

>
>
> Thanks!


No problem! I'm really happy to get email from people that have obviously
done their homework.

-Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20090528/625cb4e0/attachment.html>


More information about the Snort-devel mailing list