[Snort-users] file_data entry in snort manual

Bhagya Bantwal bbantwal at ...1935...
Tue Aug 10 12:38:51 EDT 2010


file_data as mentioned in the manual is similar to dce_stub_data.

But in case of gzip decompressed data the rule mentioned in the manual will
work.

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.

But it wont work in other scenarios ( non-gzipped). So I agree that we need
to change the example to the one you suggested.

-B


On Tue, Aug 10, 2010 at 11:25 AM, Will Metcalf <william.metcalf at ...11827...>wrote:

> 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 at ...1935...>
> wrote:
> >
> >
> > On Mon, Aug 9, 2010 at 11:53 PM, Will Metcalf <william.metcalf at ...11827...
> >
> > 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 at 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20100810/a87ade42/attachment.html>


More information about the Snort-users mailing list