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

    -Marty

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




More information about the Snort-devel mailing list