[Snort-devel] RE: A Proposal for Reengineering Snort's Packet Matching System - Comments
agetchel at ...358...
agetchel at ...358...
Fri Apr 6 11:32:50 EDT 2001
> If I were in the business of writing optimizers, and with any luck
> so many other people will that I won't have to, then I would try to
> generalise this strategy by somehow associating protocol prerequisites
> to rules and then culling all rules whose protocol prereqs
> are not met.
So, basically, the logic would be built into Snort that would say
'this packet can't possibly be HTTP, since it doesn't contain this set of
attributes, so I'm not going to bother to check it against the HTTP rules'.
Is this correct? I like this idea, _a lot_, but whoever programs this code
has to do some serious testing to make sure it can't be easily fooled and an
attack silently slip through. This, as I see it, would be the biggest
danger in using an optimization such as this. If the only optimizations
that are built into Snort 2.0 is the method I mentioned in my previous
e-mail, as well as the one you mention here, then leaps and bounds would be
made in packet matching performance. Anybody else out there listening?
> If you can send it on the wire, then you should be able to
> write a snort
> rule to describe it. I did not mention one single network protocol in
> my proposal that I don't think one could write a protocol engine for.
> I don't think that it's so important that snort be threaded,
> as that it be _possible_ to thread snort. Just as we shouldn't make
> snort linux-specific, we shouldn't make snort SMP-hostile. Now, does
> this mean that us Linux folks have to do the OpenBSD port ourselves?
> No, just that we shouldn't step on the toes of the people doing the
> OpenBSD port. Similarly, while I don't think that the core
> snort project
> should necessarily spend a lot of effort on making snort
> I do think that we should pay a lot of attention to making our code
> reentrant and otherwise making sure that those who need snort to be
> threaded can make snort threaded.
Interesting. My knowledge of threading in C is somewhat limited, so
please excuse the basic questions. The only multithread programming I've
done has been in console Java using native threads. So to me, a thread is a
thread is a thread no matter what kind of OS you're running the app on. I
get the impression from your response that this is not so in C. =) Is there
a standard threading library for C which is supported under most every OS?
Would it be possible to write the packet matching engine code using this
standard library? If so, what about threading the packet matching engine
(the part of Snort which would most benefit from this), keeping the single
threaded code, and allow the user (by means of the snort.conf file) to
choose if he has an SMP system or not?
Abe L. Getchell - Security Engineer
Division of System Support Services
Kentucky Department of Education
E-mail agetchel at ...358...
More information about the Snort-devel