file_data as mentioned in the manual is similar to dce_stub_data. <br><br>But in case of gzip decompressed data the rule mentioned in the manual will work. <br><br>Reason: file_data will point to the start of the decoded buffer also called as the alt decode buffer. When the packet has alt decode buffer pcre will also look at the alt decode buffer. So since both rule options look at the same buffer the rule will work even though it is not the proper usage of file_data.<br>
<br>But it wont work in other scenarios ( non-gzipped). So I agree that we need to change the example to the one you suggested.<br><br>-B<br><br><br><div class="gmail_quote">On Tue, Aug 10, 2010 at 11:25 AM, Will Metcalf <span dir="ltr"><<a href="mailto:william.metcalf@...11827...">william.metcalf@...11827...</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;">Ok I'm confused then because in the manual it says it's similar to<br>
dce_stub_data; which unless you perform relative matches to will<br>
search anywhere in the payload correct?  For example when using<br>
dce_stub_data the following is completely valid..  This sig will fire<br>
even though "SMB" is not in the stub data but rather in the first 8<br>
bytes of the payload, based on the description in the manual this<br>
makes sense to me as all dce_stub_data does is set the inspection<br>
pointer from which you have to perform relative matches.<br>
<br>
alert tcp any any -> any 445 (msg:"dce_stub_data over smb distance";<br>
dce_iface:4b324fc8-1670-01d3-1278-5a47bf6ee188; dce_opnum:28;<br>
dce_stub_data; content:"|6f 3a 63 b0 07 00 00 00 00 00 00 00 07 00 00<br>
00 72 00 77 00 61 00 4f 00 45 00 66 00 00 00 00 00|"; within:32;<br>
content:"SMB"; classtype:bad-unknown; sid:56; rev:1;)<br>
<br>
So the following entry suggests that file_data acts in a similar way.<br>
Is this not the case?<br>
<div class="im"><br>
"This option option will operate similarly to the<br>
dce stub data option added with DCE/RPC2, in that it simply sets a<br>
reference for other relative rule options ( byte<br>
test, byte jump, pcre) to use. This file data can point to either a<br>
file or a block of data."<br>
<br>
</div>Regards,<br>
<font color="#888888"><br>
Will<br>
</font><div><div></div><div class="h5"><br>
On Tue, Aug 10, 2010 at 9:35 AM, Bhagya Bantwal <<a href="mailto:bbantwal@...1935...">bbantwal@...1935...</a>> wrote:<br>
><br>
><br>
> On Mon, Aug 9, 2010 at 11:53 PM, Will Metcalf <<a href="mailto:william.metcalf@...11827...">william.metcalf@...11827...</a>><br>
> wrote:<br>
>><br>
>> >From the snort manual (note "This option option" typo)....  Hmm I<br>
>> think this example is a bit weird, it shows an example that will match<br>
>> from the beginning of the payload and is no way relative to setting<br>
>> the inspection pointer at the start of file_data so what is the point<br>
>> ;-)?<br>
><br>
><br>
> In case of HTTP decompression, file_data will point to the decode buffer<br>
> which will have the decompressed data. In this case pcre searches the decode<br>
> buffer rather than the packet payload. Hence the example is valid for this<br>
> scenario.  But I agree the example suggested is a better one.<br>
>><br>
>><br>
>> "This option matches if there is HTTP response body or SMTP body. This<br>
>> option option will operate similarly to the<br>
>> dce stub data option added with DCE/RPC2, in that it simply sets a<br>
>> reference for other relative rule options ( byte<br>
>> test, byte jump, pcre) to use. This file data can point to either a<br>
>> file or a block of data.<br>
>><br>
><br>
> Typo will be fixed.<br>
><br>
> -B<br>
>><br>
>> Example<br>
>> alert tcp any any -> any any(msg:"foo at the start of the payload";<br>
>> file_data; pcre:"/foo/i";)"<br>
>><br>
>><br>
>> Perhaps this should be something like....<br>
>><br>
>> alert tcp any 80 -> any any(msg:"foo at the start of http response<br>
>> body"; file_data; content:"foo"; nocase; within:3;)<br>
>><br>
>> Regards,<br>
>><br>
>> Will<br>
>><br>
>><br>
>> ------------------------------------------------------------------------------<br>
>> This SF.net email is sponsored by<br>
>><br>
>> Make an app they can't live without<br>
>> Enter the BlackBerry Developer Challenge<br>
>> <a href="http://p.sf.net/sfu/RIM-dev2dev" target="_blank">http://p.sf.net/sfu/RIM-dev2dev</a><br>
>> _______________________________________________<br>
>> Snort-users mailing list<br>
>> <a href="mailto:Snort-users@lists.sourceforge.net">Snort-users@...2902...ists.sourceforge.net</a><br>
>> Go to this URL to change user options or unsubscribe:<br>
>> <a href="https://lists.sourceforge.net/lists/listinfo/snort-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/snort-users</a><br>
>> Snort-users list archive:<br>
>> <a href="http://www.geocrawler.com/redir-sf.php3?list=snort-users" target="_blank">http://www.geocrawler.com/redir-sf.php3?list=snort-users</a><br>
><br>
><br>
</div></div></blockquote></div><br>