[Snort-devel] more fun questions

Martin Roesch roesch at ...48...
Fri Jan 19 00:01:33 EST 2001

Todd Lewis wrote:
> 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.

Well, yeah, we should abstract the firewall interface so that it can
talk to any netfilter/divert mechanism in any OS that provides one.

> > 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:
> void *
> ProcessPacket(void *pa)
> {
>         pa_packet *k;
>         Packet p;
>         while(1){
>                 k=pa->get_packet();
>                 (*grinder)(&p, p.pkth, k->buf);
>                 HandlePacket(P);
>                 k->code=p.verdict;
>                 pa->dispose_packet(k);
>         }
>         return(NULL);
> }
> 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.)

Ok, looks pretty reasonable at this point.  I'll be interested to see
how the performance works out...


Martin Roesch
roesch at ...48...

More information about the Snort-devel mailing list