[Snort-devel] spo_database & fragments

Chris Green cmg at ...81...
Fri Jan 19 12:18:14 EST 2001


Jed Pickel <jed at ...7...> writes:

> On Thu, Jan 18, 2001 at 12:44:55PM -0600, Chris Green wrote:
> > suppose "UDP Scan" and src/dst ip, protocol, ports and scantype
> > SPADE would have it's own unique table format as well.
> > 
> > A catchall type table that is a cid / text field would atleast allow
> > centralized sql logging from new plugins.
> > 
> > To have a fancy table type for a plugin, there needs to be a mecahnism
> > to know what generated the alert so that the appropriate logic can be
> > followed.  
> 
> 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 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.

http://marc.theaimsgroup.com/?l=snort-devel&m=97933992219503&w=2

> 
> Also, I'd like to start working the the pre-processor authors to
> define appropriate database tables / data structs for output from
> their plugins so we can start passing around, analyzing, and archiving
> this data around more efficiently. Any thoughts from the pre-processor
> dudes?
> 
> * Jed

this is the where I'd like to head.  With the argument type passed to
the output, it wouldn't be hard to do a switch on the function type
with a void pointer to parse the right type of struct into the table.

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.

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.
-- 
Chris Green <cmg at ...81...>
Let not the sands of time get in your lunch.




More information about the Snort-devel mailing list