From: Victor J. <li...@in...> - 2008-08-07 22:31:07
|
It indeed appears that the reassembled payload is not treated differently. So the reassembled buffer is 'replaced' but that doesn't make much sense as it won't leave the box. Also keep in mind that in normal operation stream4 will reassemble ack'd data, so we can't beat that to the destination. In our sliding window stream4inline mode you could maybe try to achieve that, it would still require significant changes I think. You would want to try to modify the original packets payload based on the reassembled payload. But I don't think stream4 provides an easy way to do that. Hope this helps, Victor Will Metcalf wrote: > Victor would be better able to answer that question... he did most of > the heavy lifting inside of stream4inline. Last time I looked at the > code though I don't remember being a way to differentiate between a > regular packet and a reassembled packet after it left stream4 but I > could be wrong. > > Regards, > > Will > > On 8/7/08, Adayadil Thomas <ada...@gm...> wrote: > >> Will, >> >> Thanks for the reply. >> >> The code doesn't seem to differentiate based on whether the analyzed packet is >> a pseudo packet or not. >> >> detection-plugins/sp_pattern_match.c >> >> CheckANDPatternMatch(...) >> <snip> >> if (InlineMode() && found && idx->replace_buf) >> { >> //fix the packet buffer to have the new string >> detect_depth = (char *)doe_ptr - idx->pattern_size - dp; >> >> ret = PayloadReplace(p, otn_idx, fp_list, detect_depth); >> if (ret == 0) >> return 0; >> } >> <snip> >> >> Even inside PayloadReplace the differentiation was not present. >> >> Is that not handled now? >> >> Thanks >> >> >> >> On Thu, Aug 7, 2008 at 5:03 PM, Will Metcalf <wil...@gm...> wrote: >> >>> Yeah It can only work on a packet-by-packet basis. >>> >>> Regards, >>> >>> Will >>> >>> On 8/7/08, Adayadil Thomas <ada...@gm...> wrote: >>> >>>> Greetings. >>>> >>>> I have a question/concern regarding the "replace:" rule option - >>>> >>>> Example rule from the manual -- >>>> >>>> alert tcp any any <> any 80 (msg: "tcp replace"; content:"GET"; replace:"BET";) >>>> >>>> Although not specified in the manual it seems the functionality is >>>> meant to be used on a packet by packet basis and not on a stream (TCP >>>> stream). >>>> For example: >>>> For the above rule consider that the "GET" is spread across 3 segments >>>> each one byte long and all of them arrive in order. >>>> The first 2 bytes ('G' and 'E') will be forwarded to the destination >>>> before the rule is triggered; and at that point replacing "GET" >>>> with "BET" is not possible without the IPS retransmitting the previous >>>> 2 bytes and hope that the destination OS favors newer data. >>>> >>>> Thoughts? >>>> >>>> ------------------------------------------------------------------------- >>>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >>>> Build the coolest Linux based applications with Moblin SDK & win great prizes >>>> Grand prize is a trip for two to an Open Source event anywhere in the world >>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>> _______________________________________________ >>>> Snort-inline-users mailing list >>>> Sno...@li... >>>> https://lists.sourceforge.net/lists/listinfo/snort-inline-users >>>> >>>> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Snort-inline-users mailing list > Sno...@li... > https://lists.sourceforge.net/lists/listinfo/snort-inline-users > |