Alan,<br><br>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?<br><br>The following inline comments are based on that assumption. Please correct me if I'm wrong.<br>
<br><div class="gmail_quote">On Wed, May 27, 2009 at 10:45 PM, Alan M. Carroll <span dir="ltr"><<a href="mailto:amc@...3043...">amc@...3045....</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.</blockquote>
<div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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.</blockquote>
<div><br>That's definitely redundant. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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.</blockquote>
<div><br>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".<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>
I am left with three questions:<br>
<br>
1) Is this a reasonable approach?</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
2) Would anyone else be interested in it, i.e. should I plan on making it robust enough for others to use? </blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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?</blockquote><div><br>There's an enumerated type in plugin_enum.h.  Add your index in there, before PLUGIN_MAX.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Thanks!</blockquote><div><br>No problem! I'm really happy to get email from people that have obviously done their homework.<br><br>-Ryan<br> </div></div><br>