[Snort-devel] spo_database & fragments
roesch at ...48...
Sat Jan 27 01:41:10 EST 2001
Chris Green wrote:
> > >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.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
roesch at ...48...
More information about the Snort-devel