[Snort-devel] more fun questions

Todd Lewis tlewis at ...120...
Thu Dec 21 17:55:46 EST 2000


On Thu, 21 Dec 2000, Martin Roesch wrote:

> So are you recommending bypassing the packet filtering/firewall interface in
> the kernel?

Not necessarily.  Even for the conventional case, using a shared buffer
could save at least one copy.

> I agree doing direct DMA xfers to userland would be faster (which
> is how most NIC drivers *should* be sending data to the kernel bufs anyway). 
> Does it make more sense if we're concerned about that level of performance to
> maybe think about moving Snort into the kernel (which could break its
> cross-platform ability severely).  

Which is exactly why moving snort into the kernel is a bad thing.  I think
that the netfilter approach is perfect; the kernel does the kernel thing
and snort does the user space thing.  I think that even for people not
interested in user-space firewalls, the netfilter paengine for snort
will be popular, since you can craft your firewall rules only to divert
traffic of interest to snort, rather than sending everything ala a blind
pcap interface.

> Memory management is going to be a serious issue if we want to be able to
> shuffle packets around at will (such as into/out of the "packet switchyard"
> that we've mentioned a few times).  

That's an awesome concept.  I think that snort has a real short at becoming
the user-space packet manipulation engine of choice, and I think that we
understand how to do it.

> Well, you'd activate a specific output plugin to put Snort in "gateway mode"
> that would automatically assume that the proper paengine was being used. 
> There's no law that says you can't pair plugin elements together.

No, there's not.  This approach could work, and maybe even could be
coded in a clean way.  (It strikes me as much more of an event-style
programming method rather than a linear programming method; very much
"chop it all into pieces do the piece that needs doing now and trust
that it all works out in the end" as opposed to "layer it properly and
have your flow be perfect".  I try to shoot for the latter, but we can
give the former a shot if you really prefer and see if it can be made
to work cleanly.

> > This general thinking was exactly why I had previously asked to extend
> > the Packet structure to include the disposition flag, so that info could
> > be passed back up to the paengine, rather than being smuggled back in,
> > like it was in my USF prototype.
> 
> Adding a flag to the Packet struct is certainly doable, I've got no objection
> to doing it.

My point was that that makes sense only, I think, in the context of
layering the processing the way that I suggested.

> I agree, although I have a very limited supply of 4-way Xeon boxen to do dev
> work on around here. :)

I priced them out the other day, and they were less expensive than I
thought.  It looks like I might be able to put one together for around
$4000.  If I do build one, and it looks as if I will, I publish how I
built it and how much it costs, and anyone who has work that would be
interesting on that machine but can't afford one can approach me about
using ours remotely.

> > The work that we
> > are doing today to cleave these pieces off into clean interfaces will make
> > this process much easier, and indeed the threading of the code base can
> > serve as an additional catalyst for cleaning up the internal interfaces.
> 
> Yep, this needs to happen and it is one of the reasons we're thinking about
> going from 1.7->2.0.

Cool.

> Cool, I think we can work all of this stuff out, it's just a matter of making
> sure we're all on the same page with the base goals of Snort development. 
> Sounds like we are (or pretty close anyway).

Excellent.  I can't wait for 2.0 to get going; we've got lots of good
work to do.

--
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 mailing list