[Snort-devel] more fun questions
roesch at ...48...
Thu Jan 18 17:33:29 EST 2001
Todd Lewis wrote:
> 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.
We looked at doing a shared buffer when I was at Hiverworld for their
IDS, it essentially requires you to write your own memory management
subsystem if you want to have any kind of level of performance. OTOH,
with all the packet manipulation that we're getting into, it might not
be a bad idea to do just that.
> > 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.
Sounds reasonable to me. :)
> > 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.
We're already pretty close to being that, some more interfaces for
manipulation and better packet handling and we'll be there.
> > 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.
I'm open to whatever architecture is going to work "best" for a given
situation, I think we should be flexible in as many ways as possible and
let people extend the functionality in ways that we don't contemplate
when we write it. If a layered approach is rational and will work best
for what we want to do then by all means lets do it. Since we're in the
design phase right now, I'm open to all suggestions.
> > > 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.
Consider yourself approached. :)
> Excellent. I can't wait for 2.0 to get going; we've got lots of good
> work to do.
Soon, very soon...
roesch at ...48...
More information about the Snort-devel