From: Adayadil T. <ada...@gm...> - 2008-08-07 20:14:43
|
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? |
From: Will M. <wil...@gm...> - 2008-08-07 21:03:25
|
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 > |
From: Adayadil T. <ada...@gm...> - 2008-08-07 21:25:28
|
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 >> > |
From: Will M. <wil...@gm...> - 2008-08-07 22:08:46
|
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 > >> > > > |
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 > |
From: Dave R. <dav...@gm...> - 2008-08-07 23:43:59
|
On Thu, Aug 7, 2008 at 4:30 PM, Victor Julien <li...@in...> wrote: > 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. > Yah, if you're seeing your match data in the reassembled packet, the horse has already left the barn, and is long gone. For grins and giggles, though, given the frailties of most TCP stacks, one could try crafting a packet with exactly the replacement data (and correct sequence and ack numbers for the match/replacement) and send that along. Probably work on some machines. > > 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 > > > > > ------------------------------------------------------------------------- > 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 > -- "Of course, someone who knows more about this will correct me if I'm wrong, and someone who knows less will correct me if I'm right." David Palmer (pa...@ty...) |