[Snort-devel] spo_database & fragments

Martin Roesch roesch at ...48...
Sat Jan 27 01:41:10 EST 2001


Chris Green wrote:
> 

[snip]

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

Let's please enumerate this, I don't want to be doing strcmps in the
output stage if we don't have to.  Remeber, we try to parse/process as
much ahead of time as possible so that we keep the amount of work
required to do any operation as efficient as possible.  Let's
tokenize/enumerate the strings and look them up that way.

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

Let's be careful with that, the hackers would love to flood us out if
we're sloppy with our design here (c.f. the default packet logging
mechanism...  ;)

   -Marty

--
Martin Roesch
roesch at ...48...
http://www.snort.org




More information about the Snort-devel mailing list