[Snort-devel] more fun questions
tlewis at ...120...
Thu Jan 18 18:21:54 EST 2001
On Thu, 18 Jan 2001, Martin Roesch wrote:
> The output plugin approach hews closer to what has been done in Snort
> before. It can also be treated as a preprocessor, but if we do that
> then we'll be trying to make decisions ahead of the detection engine.
> Maybe we should think about new action keywords, pass and drop and have
> the system specifically integrate netfilter functionality.
I would agree with the new "pass" and "drop" keywords, but I don't know
that I would call associate this functionality with netfilter. Viz.,
under FreeBSD, using divert sockets will be identical.
> Can you describe for me the way you envision the packet flow through
> Snort for this application?
Sure. In my mods to 1.6.3, which it looks like SecureWorks will try to
deploy in advance of snort 2.0, I have created a new function called
HandlePacket. This function holds the majority of what used to be in
ProcessPacket; its purpose is to print the packet info and/or log it if
required, and then to send it through the rules via Preprocess().
That having been done, ProcessPacket now looks like the following:
(*grinder)(&p, p.pkth, k->buf);
That's it. You get a packet, you grind it, you process it, and then
you dispose of it, all in a loop.
(As an aside, the reason the function pointlessly returns a (void *)NULL
is that it's a pthread_create-friendly function. As a proof of concept,
I've had this loop running in several threads under Linux simultaneously
with no problems. I plan to test this further on an MP machine and clock
the performance. In other words, this approach is threadable in a way
that the callback model is not, which I think is an important criterion.)
Does that answer your question?
Todd Lewis tlewis at ...120...
God grant me the courage not to give up what I think is right, even
though I think it is hopeless. - Admiral Chester W. Nimitz
More information about the Snort-devel