[Snort-devel] New Stream reassembly code committed
tlewis at ...255...
Tue May 8 18:56:41 EDT 2001
I have been thinking about this sort of application to make sure that it fits
well into the protocol engine framework. I have two thoughts:
1) Rather than a fixed set of sessions, I was thinking about allocating
them dynamically and then having a memory-pressure mechanism that can
press on this as well as other potential big memory hogs at the same
time. To do session tracking right, you'll need potentially to do it at
different points in the stack, so you need a generic way to tackle the
problem, and defining your limits at compile-time is cumbersome and less
efficient than it could be. Of course, being clever here requires much
more work, and so a fixed set of sessions is almost certainly the right
way to go at this point, as we are getting our feet wet with this stuff.
2) When you do hit your limit and have to start culling sessions,
I suggest shooting down existing sessions randomly rather than FIFO.
That way, hackers who know the defaults can't time their attacks to sneak
them in, but rather stand a chance of getting caught no matter how many
sessions they push through. Sure, if they crank up the number of
sessions then the odds go down, but with random shootdown, the odds never
go to 0.
tlewis at ...255...
On Tue, 8 May 2001, Martin Roesch wrote:
> Ok, I think we have a solution for the memory leaks in the stream
> reassembler. I just committed "stream3" to CVS, have a look at it and
> try it out. The new stream reassembler can handle a user-defined number
> of streams (default 8192) simultaneously and should be able to do so
> with more efficiency than the old one. The new stream reassembler uses
> a self-balancing AVL tree to store the stream nodes so it should be able
> to handle a huge number of simultaneous sessions (on the order of
> 16-32,000). Have a look at it and let me know how it works for you,
> it's had some moderate testing here and appears to be working
More information about the Snort-devel