[Snort-devel] RE: A Proposal for Reengineering Snort's Packet Matching System - Comments

Todd Lewis tlewis at ...255...
Fri Apr 6 13:30:02 EDT 2001

On Fri, 6 Apr 2001 agetchel at ...358... wrote:

> 	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?
> Marty? =)

You would have to make sure that your protocol mapping was solid, but
taking an HTTP attack and masquerading it as a DNS query to the extent
that snort can be fooled would almost certainly fool the victim OS as
well, rendering the attack harmless.  Yes, you need to make sure that
your protocol mappings are good, but (tcp,80) is (tcp,80) and (udp,53)
is (udp,53), and that's a pretty solid thing to rely on.

> 	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?

The problem to which I alluded is not any sort of lack of standardization.
Rather, the issue is how you deploy your threads.  Do you generate
one thread per packet?  Do you have a threadpool to which packets
are dispatched on receipt?  Do you have a matching thread and a
post-processing thread, or one threadpool for each purpose?  This was
the decision on which I agreed with you but disclaimed any real expertise.

Todd Lewis
tlewis at ...255...

More information about the Snort-devel mailing list