[Snort-devel] spo_database & fragments

James Hoagland hoagland at ...60...
Sat Jan 20 15:06:12 EST 2001

Greetings Jed, Chris, and everyone,

>  > This resurfaces an issue we talked about almost a year ago.. In order
>>  to start logging messages from pre-processors in the database (and
>>  other output plugins), I believe the right solution is for the
>>  preprocessor to pass that info to the output plugins in a structured
>>  format such as some predefined struct -- rather than just a
>>  string.
>Yes, theres enough generation of strings that I doubt parsing strings
>is the business one would like to get into on the output.  A defined
>struct is the best way.

I agree.  For Spade, the only thing different from a normal alert is 
that it has an anomaly score added; there is still a normal packet 
associated with it.  Some preprocessors might have something quite 
different though.  So maybe the best solution is to allow the 
preprocessors to pass along "extra fields" or "alternate output 
information" at their discretion.  "Extra" here meaning something 
that is not in the packet struct (with well known semantics) or in 
the message string.

I see each case having a union of structs associated with it.  Which 
struct to use within the union would be determined by which 
preprocessor originated the output.

>  > I like the idea of a "catchall" table for unstructured data from
>>  plugins. Yet, before we can start using this we need to flag the data
>>  origin currently there is no way to know where data originates from
>>  (from the perspective of an output plugin). Any thoughts on the best
>>  way to accomplish this?
>About a week ago, there was a thread on this ( took me a while to
>find though ) where Joe McAlerney thought adding another argument to
>CallAlert/CallLog would be beneficial.

Indeed, Joe has made and tested the changes but not yet released it. 
He has added a 4th argument, a char * specifying the source.

Starting a couple of days ago, Joe and I are working on passing extra 
output specification information from Spade to the IDMEF output 
plugin (for our own nepharious purposes).  It is nice that this 
meshed with the desire to pass along field information.  With this, I 
now see what we want to do as passing messages with different 
purposes between the data originator and the output plugins.

Let me put this forth as a proposal for how to do this.  We make use 
of the void *arg argument.  (As I understand it there is a limited 
few places where this is used now, so until everything gets in the 
standard format, we can make it so that only data originators known 
to the using the standard format should be assumed to use that 
argument in this way.  The best way really is to all go to a standard 
format simultaneously though.  Or maybe we should just add a 5th 
argument so we don't have to worry about conflicts.)

This argument is interpreted as a pointer to the head of a linked 
list of messages to output plugins.  Each link is a void *array of 
varying length.  This array has the format:

index 0:  one of a list of enumerated types indicating the message 
format or contents, e.g.  EXTRA_FIELDS, ALTERNATE_FIELDS, 
index 1:  a pointer to the next link, or NULL.
indices 2 and on:  data specific to the message format that can only 
be interpreted in that context

New message types can be added fairly easily; a new enum constant 
needs to be added and the format of the message type would need to be 
described.  Preprocessors and output plugins can support a new type 
on their own time schedule.

Discussion on this?  Hopefully I have made what I mean clear.  I have 
a deadline, so I'm working on at least the message passing for SPADE 
-> IDMEF now.

>perhaps, instead of a string for each processor name, each
>preprocessor can recieve their own symbolic constant so that output
>plugins can do a switch easily without having to parse.

As I mentioned, the way it is currently written is that it is a char 
*.  I think that using a symbolic constant is somewhat better though. 
char * is not that bad though I think as you would just need string 

>The generic case could be handled by a pointer to whatever function
>would generate a line of text in the alert file end of the game.

If we change the alert format depending on the source, can we at 
least do so in a way that doesn't cause alert parsers such as 
SnortSnarf too many headaches?  Please.

Kind regards,

|*   Jim Hoagland, Associate Researcher, Silicon Defense    *|
|*               hoagland at ...60...                *|
|*              http://www.silicondefense.com/              *|
|*  Voice: (530) 756-7317              Fax: (707) 445-4222  *|

More information about the Snort-devel mailing list