[Snort-devel] Regarding Stream6 preprocessor

Russ rucombs at ...3461...
Fri May 5 08:45:58 EDT 2017



On 5/3/17 7:55 AM, Sherlock Holmes wrote:
> Hello Snort aficionados,
>
> I have a few questions on the Stream6 preprocessor. I'm a complete 
> newbie and i hope you'll pardon my ignorance. Also, this is my first 
> query to the open source community. I am not sure of the etiquette 
> followed. I'm all ears.
Cool - glad to help.
>
> I understand the intent of this input plugin. It is needed for TCP 
> reassembly, among other things.
>
> 1. Would it be possible to bypass this preprocessor altogether for TCP 
> traffic if it is absolutely certain that snort will always receive 
> in-order TCP segments with no overlap ( i won't get into how that is 
> possible now ) ?
No.  Stream is responsible for tracking and enforcing flow state and 
stream5_tcp is responsible for parsing out PDUs from the byte stream, 
among other things.
>
> 2. Here is the code flow:
>
> StreamProcess()
>     StreamProcessTcp()
>         ProcessTcp()
>             ProcessTcpData()
>                  ProcessTcpStream()
>                       StreamQueue()/NewQueue()
>                             AddStreamNode()  ---- Internally does a 
> calloc of 'StreamSegment'.
>         CheckFlushPolicyOnData() -----|
>         CheckFlushPolicyOnAck()----These two checks are for the PAF 
> and to do a 'flush'.
>
> If I were to skip CheckFlushPolicyOnAck(), would that effect in any 
> dire ramifications?
Yes, no post-ack reassembly would take place.  This means detection on 
PDUs generally won't work.
>
> 3. 'Packet' is snort's abstraction of a packet, like we have sk_buff 
> in Linux Kernel and mbuf in FreeBSD. So what is the intent of doing 
> another calloc of 'StreamSegment' for every packet, when we already 
> have the 'Packet' structure? This 'StreamSegment' is again merged into 
> 'Packet' when doing a flush.
Because stream holds on to the data until it has been acked, which may 
be welll after the kernel has disposed of it.  There is no coordination 
of buffer management between Snort and kernel.  Apart from lifetime, 
there are also space considerations, with the kernel being generally 
more limited.
>
>
> 4. Flushing happens in a do-while loop in  _flush_to_seq(). It is 
> specifically this code chunk within the do-while that sends the packet 
> further:
>
> _flush_to_seq() {
> .
> .
>             SnortEventqPush();
>             Preprocess(s5_pkt);
>             SnortEventqPop();
>
> .
> .
>
> }
> A call to Preprocess sends the packet to the next preprocessor. So, if 
> the flush were to happen after 5 'StreamSegment's were queued , does 
> it mean that the 'Packet' that gets forwarded ( for instance, 
> FlushStream() builds the packet from StreamSegments ) is a single one 
> in lieu of 5?
Generally yes, but fewer may have been acked (post-ack mode) and fewer 
may be required to complete a PDU.  "Protocol Aware Flushing" (PAF) is 
used to scan the in order sequence of bytes and determine where the PDU 
boundaries are and flush at those points.  This is done for HTTP etc.  
If not protocol aware, then the flush point depends on the amount of 
contiguous bytes ("footprint") and of course pre- or post-ack mode.
>
>
> Would highly appreciate any inputs. Thanks for your time.
>
> Much obliged,
> - S
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-devel
>
> Archive:
> http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel
>
> Please visit http://blog.snort.org for the latest news about Snort!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20170505/0aaf10d2/attachment.html>


More information about the Snort-devel mailing list