Re: file_data entry in snort manual

[Will Metcalf <william.metcalf () gmail com>]

Ok I'm confused then because in the manual it says it's similar to
dce_stub_data; which unless you perform relative matches to will
search anywhere in the payload correct?  For example when using
dce_stub_data the following is completely valid..  This sig will fire
even though "SMB" is not in the stub data but rather in the first 8
bytes of the payload, based on the description in the manual this
makes sense to me as all dce_stub_data does is set the inspection
pointer from which you have to perform relative matches.

alert tcp any any -> any 445 (msg:"dce_stub_data over smb distance";
dce_iface:4b324fc8-1670-01d3-1278-5a47bf6ee188; dce_opnum:28;
dce_stub_data; content:"|6f 3a 63 b0 07 00 00 00 00 00 00 00 07 00 00
00 72 00 77 00 61 00 4f 00 45 00 66 00 00 00 00 00|"; within:32;
content:"SMB"; classtype:bad-unknown; sid:56; rev:1;)

So the following entry suggests that file_data acts in a similar way.
Is this not the case?

"This option option will operate similarly to the
dce stub data option added with DCE/RPC2, in that it simply sets a
reference for other relative rule options ( byte
test, byte jump, pcre) to use. This file data can point to either a
file or a block of data."

Regards,

Will

On Tue, Aug 10, 2010 at 9:35 AM, Bhagya Bantwal <bbantwal () sourcefire com> wrote:
> On Mon, Aug 9, 2010 at 11:53 PM, Will Metcalf <william.metcalf () gmail com>
> wrote:
> > > From the snort manual (note "This option option" typo)....  Hmm I
> > think this example is a bit weird, it shows an example that will match
> > from the beginning of the payload and is no way relative to setting
> > the inspection pointer at the start of file_data so what is the point
> > ;-)?
>
>
> In case of HTTP decompression, file_data will point to the decode buffer
> which will have the decompressed data. In this case pcre searches the decode
> buffer rather than the packet payload. Hence the example is valid for this
> scenario.  But I agree the example suggested is a better one.
> > "This option matches if there is HTTP response body or SMTP body. This
> > option option will operate similarly to the
> > dce stub data option added with DCE/RPC2, in that it simply sets a
> > reference for other relative rule options ( byte
> > test, byte jump, pcre) to use. This file data can point to either a
> > file or a block of data.
>
> Typo will be fixed.
>
> -B
> > Example
> > alert tcp any any -> any any(msg:"foo at the start of the payload";
> > file_data; pcre:"/foo/i";)"
> >
> >
> > Perhaps this should be something like....
> >
> > alert tcp any 80 -> any any(msg:"foo at the start of http response
> > body"; file_data; content:"foo"; nocase; within:3;)
> >
> > Regards,
> >
> > Will
> >
> >
> > ------------------------------------------------------------------------------
> > This SF.net email is sponsored by
> >
> > Make an app they can't live without
> > Enter the BlackBerry Developer Challenge
> > http://p.sf.net/sfu/RIM-dev2dev
> > _______________________________________________
> > Snort-users mailing list
> > Snort-users () lists sourceforge net
> > Go to this URL to change user options or unsubscribe:
> > https://lists.sourceforge.net/lists/listinfo/snort-users
> > Snort-users list archive:
> > http://www.geocrawler.com/redir-sf.php3?list=snort-users

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users