<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Let me know if I understand this correctly.<br><br>Say I have a large HTML file that gets passed from the application layer to the TCP layer. TCP will look at this stream of data and divide it into segments, and append a TCP header to each segment. Each TCP segment will then be passed to the IP layer. If the TCP segment is larger than the MTU, then IP will further break up the TCP segments into fragments that are each smaller than the MTU. Each of these fragments will then have an IP header appended to it. This also means that some of these IP fragments will not have a TCP header. These IP fragments are then passed to the network layer.<br><br>Now, when these IP fragments are passed through the preprocessors, they first go through Frag3. The IP fragments are reassembled and form the TCP segments from before. At this stage, the original HTML file is still in
 chunks and not whole yet. These TCP segments then pass through the Stream5 preprocessor, where they are reassembled, and we are able to obtain the original HTML data.<br><br>If the TCP segments were smaller than the MTU size, then there would be no IP fragmentation, and these TCP segments would then pass through Frag3 unchanged.<br><br>If I have a string "ABCDEF" that I want to match, but the string spans across 2 fragments, i.e. "ABC" on one and "DEF" on the other, am I right to say the reassembled pseudo-packet by Frag3 and Stream5 will trigger the alert? What about UDP fragments?<br><br>Off-topic: How do I reply such that my posting appears within/under the previous relevant post, instead of creating a new posting/topic everytime I reply?<br><br>Thank you.<br><br>Regards,<br>Rayne<br><br>--- On <b>Wed, 10/15/08, Matt Olney <i><molney@...1935...></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px;
 padding-left: 5px;">From: Matt Olney <molney@...1935...><br>Subject: Re: [Snort-users] Reassembled packets from Frag3 and Stream5<br>To: wu_weidong@...131...<br>Cc: snort-users@lists.sourceforge.net<br>Date: Wednesday, October 15, 2008, 1:03 PM<br><br><div id="yiv1324443524"><div dir="ltr">Pseudo packets from the Frag3 processor are then eligible to be stream reassembled in stream5.  Snort does not differentiate between pseudo packets or regular packets for the purpose of reassembly.  To extend your question somewhat, it is possible to alert more than once on a single attack.  If that attack is contained within one fragment, Snort will alert again on the reassembled packet.  If that packet is part of a stream, Snort will alert a third time on the reassembled stream.<br>
<br>The performance gain comes from the use of the flowbits: and flow:.  By being aware of the state of the stream, and being able to bail early in the rules evaluation process based on that state, we can avoid unnecessary load.  For example, flow: is very important in the following rule:<br>
<br>alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"BACKDOOR bersek 1.0 runtime detection - init connection"; flow:to_server,established; flowbits:isset,Backdoor.Bersek.Init; content:"|23|[version]1.0"; depth:13; nocase; threshold:type limit, track by_src, count 1, seconds 300; metadata:policy security-ips alert; reference:url,<a rel="nofollow" target="_blank" href="http://www.megasecurity.org/trojans/b/bersek/Bersek1.0.html">www.megasecurity.org/trojans/b/bersek/Bersek1.0.html</a>; classtype:trojan-activity; sid:9657; rev:3;)<br>
<br>Because of the nature of the backdoor, we won't know for sure what tcp port it is listening on.  However, Stream5 tells us whether a packet is destined for a server or a client and using the "flow: to_server, established" check means we don't have to do any of the other checks if the packet is going the wrong way.  Further, the use of the Backdoor.Bersek.Init flowbit means that the stream must have already been tagged with a flowbit or, once again, we'll bail on the detection, avoiding unnecessary processing.<br>
<br>You might want to check out the performance rules slides at <a rel="nofollow" target="_blank" href="http://www.snort.org/vrt/docs/white_papers/">http://www.snort.org/vrt/docs/white_papers/</a>, it might make some of this more clear.<br><br>Matt<br>
<br><br><div class="gmail_quote">On Tue, Oct 14, 2008 at 8:53 PM, Wu Wei Dong <span dir="ltr"><<a rel="nofollow" target="_blank" href="mailto:wu_weidong@...131...">wu_weidong@...131...</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So it's possible for the pseudo-packets reassembled by Frag3 and Stream5 to be identical, in terms of both the headers and payload, if the fragments are the same? Do the pseudo-packets go through the preprocessors again, since the decoder comes before the preprocessors?<br>

<br>
Also, what do you mean by "performance increase that is gained by handling flows with an understanding of the stream state."?<br>
<br>
Thank you.<br>
<br>
Regards,<br>
Rayne<br>
<br>
--- On Tue, 10/14/08, Matt Olney <<a rel="nofollow" target="_blank" href="mailto:molney@...1935...">molney@...1935...</a>> wrote:<br>
<br>
> From: Matt Olney <<a rel="nofollow" target="_blank" href="mailto:molney@...1935...">molney@...1935...</a>><br>
> Subject: Re: [Snort-users] Reassembled packets from Frag3 and Stream5<br>
> To: <a rel="nofollow" target="_blank" href="mailto:hjazz6@...14432...">hjazz6@...14432...</a><br>
> Cc: <a rel="nofollow" target="_blank" href="mailto:snort-users@lists.sourceforge.net">snort-users@lists.sourceforge.net</a><br>
> Date: Tuesday, October 14, 2008, 9:00 PM<br>
<div><div></div><div class="Wj3C7c">> The reassembled packets are identical to the combined<br>
> payloads of the<br>
> packets that are reassembled.  Snort reinjects the<br>
> reassembled packets<br>
> (pseudopackets) at the decoder level and detection is run<br>
> against the<br>
> reassembled packets.  While this does indeed add load to<br>
> the system, this<br>
> cost is entirely acceptable given the decrease in trivial<br>
> evasion<br>
> possibilies and is more than offset by the by performance<br>
> increase that is<br>
> gained by handling flows with an understanding of the<br>
> stream state.<br>
><br>
> Matt<br>
><br>
> On Tue, Oct 14, 2008 at 4:42 AM, Rayne<br>
> <<a rel="nofollow" target="_blank" href="mailto:hjazz6@...14432...">hjazz6@...14432...</a>> wrote:<br>
><br>
> > Hi all,<br>
> ><br>
> > I know that Frag3 reassembles IP fragments, and<br>
> Stream5 reassembles TCP<br>
> > fragments. So are the reassembled packets identical,<br>
> i.e. in terms of<br>
> > payload? And wouldn't this increase the volume of<br>
> traffic passed into the<br>
> > detection engine and cause it to run slower, since<br>
> there are now more<br>
> > packets to check against the rules?<br>
> ><br>
> > Thank you.<br>
> ><br>
> > Regards,<br>
> > Rayne<br></div></div></blockquote></div></div></div></blockquote></td></tr></table><br>