Re: [Snort-inline-users] Stream4 and snort_inline anybody have any ideas?

[Stephan S. <ss...@as...>]

Hi Will,

great to hear that you are making progress on this issue.
Did you notice that Marty has rewritten the stream4 preprocessor, which AFAIK
has not made it into stable Snort releases? Maybe this will improve some things.
Here's the mail Marty sent to snort-devel 2 months ago:

> Hi everyone,
> 
> We checked some code into CVS a few days ago that make a couple pretty big changes as to how the stream reassembler works and I'm soliciting feedback as to how the changes work.  The biggest change is that I replaced the state machine in stream4 for TCP state tracking and changed the way that state transitions are handled.  Basically, the state machine has been reduced from ~650 lines of code down to about ~230 or so, I removed the different state trees that paid attention to state differently based on whether or not you were the client or server and I added a state queuing mechanism into the engine so that we can defer state transitions until we see the side being transitioned indicate that it has seen the transition itself.  Session teardown state transitions are modeled more correctly in the new code as well and it seems to work a lot more efficiently in general.
> 
> Another change that was made was to the unified output plugin (one that should be translated across all the logging plugins in the not too distant future I hope).  One of the big annoyances with the way we do stream reassembly is the "pseudo-packet" that we generate to analyze the reassembled stream segments.  A lot has been written on the pros and  cons of doing it this way, but one of the side effects of this method and the way that Snort's engine works is that if there was a detection event on a reassembled pseudo-packet, the pseudo-packet got logged.
> 
> I made a change to the way that the unified output module works so that it can get access to the packets that are queued (fully) in the stream4 StreamTrackers and log them instead of logging the pseudo packet.  The way it works is to generate the event on the first packet in the reassembled stream and log all subsequent packets in the stream as tagged packets referencing the original event.  The upside of this method is that it logs the actual packets instead of the pseudo-packet so you can look for signs of hand crafting and such, not to mention that you now have the set of unmodified packets for legal/whatever purposes you might need them for.
> 
> Anyway, this code is in CVS now and if people could give it a test and report if they see any weirdness, I'd appreciate it.  If  you want to keep tabs on the stream state transitions specifically I added in a new SNORT_DEBUG value (8388608) to track those independent of other debug statements in Snort.  The new stream logging stuff only works if you're using log_unified as an output type, but it should work with Barnyard (including the latest builds) just fine.
> 
>      -Marty

Regards,
Stephan

-- 
Stephan Scholz <ss...@as...> | Development
Astaro AG | www.astaro.com | Phone +49-721-490069-0 | Fax -55

Awards for ASL:
- Nätverk & Kommunikation Magazine, Sweden: "Five Stars" - October 2003
- Linux Enterprise Readers' Choice Award: Best Firewall - October 2003
- LinuxWorld Product Excellence Award: Best Security Solution - August 2003
- "Excellent" Infoworld Magazine - August 2003