mailing list archives
Re: Issues with the Snort Manual (Patch)
From: <Joshua.Kinard () us-cert gov>
Date: Wed, 8 Dec 2010 20:17:34 -0500
Thank you very much for the below explanations! They shed a lot of light on things.
- session: What is the purpose or function of the 'binary' parameter?
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.
This sounds like something that can be boiled down into one of those notification blocks for the session keyword, so
that those using it are aware of this.
- 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.
Sounds good to me. The patch only addresses rule examples in the rule options section of the manual, as that's what
I'm more knowledgeable on. I didn't want to tread on doing similar for the various configuration directives, because
even though they can resemble a rule option syntaxically, they're much more flexible. Might be worth a review for
- 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.
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.
This makes sense, thanks for the clarification.
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'
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
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
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.*
This is extremely useful information. Possible to distill this down into a format for inclusion in the Snort manual?
Might also be worth for the SourceFire documentation team to review as well for inclusion in the next Analyst Guide
Has there been any thought given to organizing the various content modifiers a bit differently? Rough brainstorming
suggests an organization based on modifier function/buffer type:
Normalized HTTP Buffer modifiers:
http_client_body, http_cookie, http_header, http_method, http_uri, http_stat_code, http_stat_msg
Unnormalized HTTP Buffer modifiers:
http_raw_cookie, http_raw_header, http_raw_uri
Detection Engine modifier(s):
I also think mentioning, in reference to content and its family, that rule options with a "relative" type parameter,
act as a modifier (of sorts), and provide PDF anchor links (or whatever they're called in LaTeX) to jump to that
specific rule option's explanation in the manual.
Conditional modifiers (that test a condition in a relative buffer):
byte_test, isdataat, pcre
Operational modifiers (that take action on data in a relative buffer):
asn1, base64_decode, byte_extract, byte_jump
On the same/similar topic, "uricontent" could use some fleshing out. Its explanation in Snort is vague and I think is
a source of confusion. It doesn't even exist in SourceFire (one mention in the manual, in a rule example only, but not
available in the UI), since it's just an anagram for content with an http_uri modifier.
Probably the most important/confusing line is this:
For a description of the parameters to this function, see the content rule options in Section 3.5.1.
I think that can lead people to think that all (or most) of content's modifiers are available to uricontent. While a
mention is made about uricontent and rawbytes as being incompatible, uricontent and http_stat_code would equally be
incompatible, since they are modifiers that point to different buffers.
Based on your explanation, I can draw the following conclusion regarding modifier compatibility with uricontent:
nocase, depth, offset
ONLY valid IF relative to an _existing_ uricontent:
http_client_body, http_cookie, http_raw_cookie, http_header, http_raw_header, http_method, http_uri, http_raw_uri,
http_stat_code, http_stat_msg, & rawbytes.
Uncertain about fast_pattern. I've seen examples of 'content:"/foobar"; http_uri; fast_pattern;', which would imply
that 'uricontent:"foobar"; fast_pattern;' is valid. Do any of fast_pattern's parameters affect (or are incompatible
with) the operation of uricontent?
And what about the other options that contain a "relative" type parameter (but are not necessarily chained to
content/uricontent)? Is that relative to the primary pattern buffer (i.e., content w/ rawbytes), or the last used
buffer (such as pointed at by http_uri/uricontent)?
Almost in a sense, a dependency graph/chart/matrix would be useful to describe the compatible/incompatible mix of these
modifiers/rule options. Snort doesn't look to have the facilities to test every possible combination and toss back an
error, so enshrining it in the manual might be worthwhile so users don't inadvently write bad or
ineffective/inefficient rules. The fast_pattern option especially deserves its own compatibility matrix just about.
Lastly, an an issue raised by someone on my internal team today stated that Snort will ignore the "flow" option when
applied to UDP streams. I knew this was inaccurate, however, the explanation in the Snort manual for the "flow" option
doesn't address UDP at all. The SourceFire manual DOES address this on Page 1035 (System Analyst Guide, 4.9.1):
UDP stream preprocessing occurs when the rules engine processes packets
against a UDP rule that includes the flow keyword using any of the following
* To Client
* From Client
* To Server
* From Server
UDP is a connectionless protocol that does not provide a means for two
endpoints to establish a communication channel, exchange data, and close the
channel. UDP data streams are not typically thought of in terms of sessions.
However, the stream preprocessor uses the source and destination IP address
fields in the encapsulating IP datagram header and the port fields in the UDP
header to determine the direction of flow and identify a session. A session ends
when a configurable timer is exceeded, or when either endpoint receives an
ICMP message that the other endpoint is unreachable or the requested service is
Adding this to flow's description (in some form) would be really helpful, especially highlighting which flow parameters
are valid for TCP vs. UDP. Maybe even ICMP, since it has a stream5 configuration directive?
This SF Dev2Dev email is sponsored by:
WikiLeaks The End of the Free Internet
Snort-devel mailing list
Snort-devel () lists sourceforge net