[Snort-devel] spo_database & fragments
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
>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.
|* 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