Anatomy of a Signature

## What the anchoring keywords actually assert A `content` match on its own says "these bytes appear somewhere in this buffer". That is cheap to write and expensive to run, and it matches far too much. The anchoring keywords narrow it: - **`offset:N`** - do not start searching until N bytes into the buffer. - **`depth:N`** - search only the first N bytes (measured from the buffer start, or from `offset` if one is given). - **`distance:N`** - relative to the end of the *previous* content match, skip at least N bytes before looking. - **`within:N`** - relative to the end of the previous match, this content must be found within the next N bytes. `offset` and `depth` are absolute; `distance` and `within` are relative and only make sense chained after another content. Together they turn a vague "contains" into a statement about structure: this token is the first thing in the request line, this parameter follows that one closely, this magic value sits at a fixed offset in the header. That precision is what makes a rule cheap and specific. It is also exactly the surface an adversary works on, because every bound is a prediction about the attacker's formatting, and the attacker controls the formatting. ## The one-byte moves **Padding shifts the offset.** A rule written to catch a token at the start of a buffer with `depth` equal to the token length has asserted position 0. One extra byte in front - a leading slash, a space, a duplicated separator, an extra path segment - and the token now begins at position 1. The pattern is still there in full, and the rule does not fire. **Case defeats a match written without `nocase`.** Content matching is byte-exact by default. Suricata's normalised HTTP URI buffer decodes percent-encoding and resolves directory traversal, but it does not lowercase the path. `/ADMIN/login` therefore carries the same meaning to most application stacks and a different byte string to the rule. **A separator breaks a relative chain.** Two contents joined by `within:4` assert that the second follows the first closely. An inserted byte, a doubled delimiter, or extra whitespace where the parser tolerates it pushes the second match outside the window. **Encoding changes the bytes without changing the meaning.** Whether the sensor sees the encoded or decoded form depends on which buffer the rule is written against. A rule on a raw buffer sees what was on the wire; a rule on a normalised buffer sees what the parser produced. Writing against the wrong one is a common way to produce a rule that passes a lab test and misses in production. None of this is clever. That is the point of the question: the cost of an anchored rule is that it is defeated by trivial, meaning-preserving edits, and the author must know which ones. ## What loosening costs The naive answer is "so remove `depth` and add `nocase`". Both have a price, and it lands on the sensor and on the business: | Change | What it buys | What it costs | | --- | --- | --- | | Remove `depth` | Matches the pattern anywhere in the buffer | Full-buffer search on every candidate packet | | Add `nocase` | Survives case changes | Case-insensitive search is more expensive per byte | | Add a `pcre` for variants | Catches many spellings at once | The most expensive test in the engine; must stay anchored behind a cheap content or it runs constantly | | Widen to a shorter content | Harder to shift out of range | Short, common strings make weak fast patterns, so far more rules get fully evaluated | And the second bill is false positives. On a passive sensor, a false positive costs someone's attention. On an inline sensor with a drop action, a false positive drops a legitimate session - a payment call, a build fetching a dependency, a customer's upload. That asymmetry is the reason a rule author cannot simply widen everything until nothing evades. ## The honest posture A well-written content rule is deliberately narrow and its narrowness is documented. The author should be able to say: this matches the technique when the token appears in this buffer within this window in this case; it does not match padded, re-cased or differently-encoded variants; here is why widening was rejected. That statement is worth more than an unqualified claim of coverage, because the person consuming it can decide what else to fund. The corollary is that a single content rule is a narrow instrument, not a control. It is at its best when it is cheap, specific and known-narrow, sitting alongside detections built on different observations entirely.