[Snort-devel] spo_database & fragments

Chris Green cmg at ...81...
Sun Jan 21 18:39:25 EST 2001


James Hoagland <hoagland at ...60...> writes:

> [ different output formats ]
> 
> 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.
>

Thats the best way I've seen.  A common info and an extra * to
their own struct for things that wish to handle it.

> [ catchall table and joe modding ]
> 
> 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, 
> IDMEF_OUTPUT_SPEC, etc
> 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.

This is very expandable message passing type ( sounds a lot like the
packets we're dealing with in the first place ).  I'm slightly
confused - is it an array of pointers or a linked list?   Is it a
linked list of array messages?

Seems like a null terminated variable length array could do the same
for us as a linked list so I'm confused which way you a proposing.  I
suppose it depends on what you wish to deal with.

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

Yes the strcompares wouldn't be bad but it seems like a lot of
repeated work in every output plugin and since this is something not
yet implemented in general release, constants might be the way to go.

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

I was thinking things shoudln't change at all with the way output
actually looks.

a portscan alert could have a pointer to the function that parses a
portscan alert to create a generic message for the output plugins that
are just recording things it can't handle anyway.  The output plugins
and preprocessors that handle their own logging would continue as is.

I was just thinking something like

ALERT_FTP_WOOWOO

alert.packet
alert.src
alert.dst (etc...)
alert.function where alert.fucntion returns a usable string for spo's
that don't grok ALERT_FTP_WOOWOO alerts.

In the default cause for output files, perhaps each alert type should
get it's own file if we don't know how to handle it to avoid log
processing confusion.
-- 
Chris Green <cmg at ...81...>
This is my signature. There are many like it but this one is mine.




More information about the Snort-devel mailing list