Re: Issues with the Snort Manual (Patch)

[Ryan Jordan <ryan.jordan () sourcefire com>]

Hi Joshua,

I've incorporated most of your changes into the Snort manual. You
should notice a difference in the next release. In the meantime, let
me answer some of these questions inline...

On Mon, Nov 29, 2010 at 6:23 PM,  <Joshua.Kinard () us-cert gov> wrote:
> Thanks for this.  Will the developers be able to provide
> guidance/comments on the following items addressed in the documentation
> patch?:

Yes. :)

> - asn1: Are absolute_offset and relative_offset mutually exclusive?

They should be mutually exclusive, but the code does not do sufficient
error checking here. I've filed a bug so that in the future, using
both of them will generate a parser error. In the current version of
Snort, the second offset argument will overwrite the first one.

> - asn1: What is the purpose or function of the 'print' parameter?

This looks like old debug code. Specifying "asn1:print" will cause the
rule to dump ASN1 data to stdout through the use of printf statements.
Rather than document old debug code, we will be wrapping this inside
#ifdef DEBUG in the future.

> - byte_extract: Is 'offset' supposed to be able to hold a variable name
> extracted from a previous byte_extract keyword?

My mistake. At the time the documentation was written, I had the
intention of adding this ability. byte_extract does not currently
support the use of variables for its offset.

> - session: What is the purpose or function of the 'binary' parameter?

Rather than log packet payloads in ASCII, the raw bytes are appended
to a file. I've added some documentation for this option. The
"session" rule option does not log any protocol headers such as IP or
TCP, just the payload.

Since rule options are run on *both* individual and stream-reassembled
packets, this rule option will end up logging data twice into the same
file. Data may also appear out-of-order.

As already mentioned in the manual, using the "session" option is slow
and not recommended for live network traffic.

> - General: Is a space after a colon in a Snort rule option the preferred
> format, or is no space preferred?  Snort parses either-or, but as I
> mentioned, the main SourceFire product has choked on instances of these
> (specifically, importing a text file with a rule whose "sid" parameter
> contains such a space).

First off, Snort by itself will parse the rule regardless of spaces
after the colon. I have filed a bug with our UI team to get your
import issue cleared up.

In practice, all of our rules get written without the space. Thanks
for changing the manual to reflect that.

> - General: Are spaces between parameters in a rule option also the
> preferred format, or are no spaces preferred?  Similar to the last
> question.  I haven't noticed SourceFire mistreating options formatted as
> such, but the possibility probably exists.

I find rules to be more readable if there are spaces in between the
rule options. Those spaces have been kept in the manual to make it
easier to read. VRT tends to leave out those spaces for compactness,
especially if those parameters are short numbers.

For example:
byte_test:4,>,200,36;    vs.    byte_test:4, >, 200, 36;

This is just a matter of personal style; Snort should parse it both
ways. For documentation purposes, we'll use the spaces from here on
out.

> I had an additional thought over the weekend, that is not addressed in
> the manual nor reflected in my patch.  The manual states that HTTP
> content modifiers for pcre (U, I, P, H, D, M, C, K, S, & Y) cannot be
> used in combination with the 'R' relative modifier (or 'B' rawbytes).
> Content, however, disallows use of the 'rawbytes' option with the HTTP
> modifiers, but speaks nothing of the two relative modifiers, 'distance'
> or 'within'.
>
> Is a rule written as such valid?:
> alert tcp $HOME_NET 1024: -> $EXTERNAL_NET 80 (msg:"Bad HTTP URI
> /foobar"; flow:established,to_server; content:"GET"; http_method;
> content:"/foobar"; http_uri; distance:0; sid:42000001; rev:1; gid:1;
> priority:2;)
>
> Since the http_* modifiers affect where the two content matches look, is
> "distance:0;" applicable on the second content to force the match to
> continue directly after the end of the first?  This wouldn't be valid in
> a pcre option (i.e., content:"GET"; http_method; pcre:"/\/foobar/RU";).
> What about when using the http_raw_* modifiers with 'distance' and
> 'within'?
>
> Lastly, are 'distance' and 'within' valid on the 'uricontent' option?
> This has never been clearly addressed it seems and has a history of
> confusing people.  It also ties in with the previous question, since
> uricontent can be rendered as a content/http_uri pair.  Granted, both of
> these questions are more suitable for discussion on snort-users, but
> since I'm looking at further modifying the documentation if I can get
> some concrete explanation on them, I'm inquiring here instead.

I'll combine this into one explanation:

The HTTP Inspect preprocessor breaks up an HTTP request into multiple
distinct buffers. Those "http_cookie", "http_method", and other http
modifiers specify which buffer to use when looking for that content.
"rawbytes" means to use the original payload buffer, not any of these
normalized buffers.

When doing one content match relative to another, both contents have
to be in the same buffer. You can combine distance/within with an HTTP
modifier if the same HTTP modifier is used for both contents. If the
contents are in different buffers, the match will fail. "rawbytes"
cannot be used with an HTTP modifier because that would specify two
buffers for the same content.

For the same reason, distance/within are allowed with uricontent, but
only work when used in conjunction with another uricontent. You can't
have a uricontent match relative to an http_method content, for
example.*

The manual is correct when it says that PCRE does not support a
combination of R (relative) or B (rawbytes) with the HTTP modifiers.
It will throw an error if you try this. This was probably due to a
limitation in the implementation.

Short version:
- PCRE doesn't support R or B with HTTP modifiers.
- uricontent and http_* options allow distance/within, but it ONLY
works if both contents are in the same buffer.


Thanks for the help!
Ryan

*Snort 2.9.0 introduced a bug with uricontent. It tries to use a
byte_extract variable for your depth/offset/within/distance instead of
the value specified in the rule. This has been fixed in the upcoming
release. In the meantime, a content/http_uri pair still works
correctly.

------------------------------------------------------------------------------
This SF Dev2Dev email is sponsored by:

WikiLeaks The End of the Free Internet
http://p.sf.net/sfu/therealnews-com
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel