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

Alan M. Carroll amc at ...3043...
Thu May 28 15:52:16 EDT 2009

At 11:02 AM 5/28/2009, Ryan Jordan wrote:
>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?

Yes.  The output plugin is part of another system which needs to take action when a rule triggers, but that action depends on the specific rule that triggered. Basically I want to attach a metadata key/value that specifies the action of the system. E.g., in the rule I would add "metadata:my_action 12" to perform action 12 when the rule triggers. The amount of action data is small (two u_int32_t values) and having it with the rule in the Snort configuration file rather than somewhere else makes maintenance so much easier.

>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.

Yes, but anything that doesn't have a field already defined in SigInfo is completely discarded as far as I can tell.

I realize that my approach is significantly more general than absolutely required. However, one of my project goals is to minimize the amount of code changes in Snort both at the start and during maintenance. As much as possible I want my code to be in my plugin. The primary advantage of the approach I have selected is that it is a rather small, one time change to the Snort code base. Future changes the format, content, and number of metadata key/values would require no further changes to Snort itself, only to the plugin. It would also mean that other plugins could use the same system without code changes to Snort, or their implementors having to understand Snort internal details quite so intimately. This also makes ongoing maintenance of the changes for future Snort releases is minimized because the changes are minimized. Further a general mechanism has some chance of adoption in to the Snort codebase, whereas code specific to my project does not.

For these reasons I strongly prefer a solution that provides a general hook in to metadata parsing, rather than direct changes to support my project.

>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. 

I don't this as repurposing. It seems natural to me that if rules have metadata, then it's the place to put rule specific data. In fact, when I first read the Snort manual and saw that, I assumed this machinery was already in place and the Snort specific keys just the equivalent of reserved words. I was surprised to find that non-recognized metadata was discarded and not at a minimum stored in key/value pairs in the rule node.

After all, if one wants rule specific data, then one must either put it in the Snort configuration file with the rule, or maintain a mapping based on signature identifiers between rules and rule related data. Clearly, the more complex the related data, the relatively less the overhead of maintaining the mapping. But in our case the amount of data is tiny and synchronization is a large overhead. I think this tweak will, in the long run, prove to be less of a maintenance headache. It is definitely a judgement call, but that's why I get the big bucks.

Thanks for the feedback. 

More information about the Snort-devel mailing list