A detection rule is a precise description of bytes and conditions, and the room teaches you to write one accurately. The more useful lesson sits one step further out: the questions a rule structurally cannot answer, and why treating its silence as evidence is the most expensive habit in the discipline.
I paired this companion with today's field note on agent traffic that scored 0.0 as a beacon, because the two are the same lesson from opposite directions. That piece is about a rule set that did not fire on traffic that was present. This one is about building the rule set and understanding, from the inside, what its silence does and does not mean.
01 · Scope and authorisation
This companion documents the public TryHackMe Snort room, a standard defensive-security room. I worked through it in my own session, everything below stays inside that environment, and I have published no flags, no quiz answers, no credentials, no target addresses and no copy-and-paste rules. Where the room asks you to write something, I describe the structure and the reasoning so you compose your own rather than replaying mine.
The room covers the concepts behind intrusion detection and prevention, the anatomy of a rule, the modes a sensor can run in, executing rules against a captured file, and reading the output. It sits underneath the challenge rooms that apply the same tools to a set of scenarios, which are the natural next step once the fundamentals are in place. The wider frame is CWE-693, protection mechanism failure: not a bug in the sensor, but a mismatch between what a control can express and what it was assumed to cover.
02 · Learning objectives
- Separate what a rule describes, which is bytes and conditions, from what an analyst assumes it describes, which is intent.
- Read a rule's header and options as two different decisions, one about consequence and one about recognition.
- Explain why the same rule set means different things in detection and prevention modes.
- Run rules against a capture and interpret the output as a property of the rule, not of the traffic.
- Name the four questions a signature cannot answer, and route each one to a control that can.
- Write up a detection gap without overstating it as a vulnerability in the sensor.
03 · Prerequisites and the loop I use
The room assumes basic networking, comfort with a terminal, and the ability to read a capture. The loop I applied is the one I use whenever I am tuning or assessing detection:
- Observe what the rule actually matched, at the level of the field it tested, not the alert text it produced.
- Hypothesise what the author intended that field to stand in for.
- Choose the least invasive test that would show whether the intent and the expression agree.
- Interpret a match or a non-match as a property of the rule, and only then as a property of the traffic.
- Update the model and decide whether the gap is a rule to be written, a layer that needs a different control, or a question no packet can answer.
The reason interpretation comes last is that the tempting reading of a clean run is that the network is clean. The room gives you enough control over both sides of that experiment to see why the tempting reading is wrong.
04 · The model: a rule describes bytes, not behaviour
Hold this apart before touching the tool. A signature is a statement about the contents and conditions of packets. It is not a statement about what those packets were for, who sent them, or whether sending them was allowed.
That distinction is easy to nod at and hard to hold, because alert text is written in behavioural language. A rule's message reads like "someone is doing something", and a reader naturally inherits the intent from the sentence rather than from the fields that actually matched. Most of the discipline of writing good rules is resisting that slide, and most of the operational risk is other people not resisting it.
The room gives you the mechanics to see this directly. You write a rule, you run it against traffic, and you watch it match, which is the moment the difference between describing bytes and describing behaviour becomes concrete rather than philosophical.
05 · Stage one: the anatomy of a rule, and the two decisions inside it
A rule has two parts and they answer different questions.
The header answers what should happen when the rule matches. It names the action, the protocol, the source and destination, and the direction. The action is the part to read first, because it is where a rule stops being an observation and becomes an enforcement. A sensor that alerts reports; a sensor configured to drop or reject acts. The rule text can be identical in both cases, which is why the mode a sensor runs in belongs in the same conversation as the rules it carries.
The options answer what the rule recognises. Options carry the content to look for, the conditions around it, the identity and version of the rule, and the message an analyst reads. The identity fields matter more than they look: a rule without a stable identifier and a version cannot be tracked across updates, and a rule set nobody can track is a rule set nobody can reason about after a change.
The observation worth recording at this stage is a column for each rule: what field does it test, and what does that field stand in for. A rule testing a content string is standing in for a behaviour that usually produces that string. Whether the substitution holds is the question the rest of the room answers.
06 · Stage two: the mode decides what a match means
The room draws the distinction between detecting and preventing, and it is worth restating as an operational fact rather than a definition.
In detection mode, a match produces a record. The traffic continues, the alert is written, and whether anything happens next depends entirely on a human or an automated responder reading it. In prevention mode, a match produces a decision about the traffic itself. The rule set can be the same file, the sensor's position in the network can be the same, and the consequence of a match changes completely.
Two practical consequences follow. The first is that a rule written for detection mode is not automatically safe to enable for prevention, because dropping on a signature means dropping on everything that matches it, including the false positives you have not yet counted. The second is that the value of an alert depends on the queue behind it. A rule that fires ten thousand times a day is not providing detection, it is providing a filtering problem for whoever reads the queue, and the room's exercises make that tangible by letting you see how easily a broadly written rule lights up.
This is where the discipline separates from the tooling. Writing a rule that matches is easy. Writing one whose matches are worth the attention they consume is the actual work.
07 · Stage three: running rules and reading what came back
The room has you point the sensor at a capture and read the output, and the habit to build here is reading the record rather than the verdict.
For each match, the useful reconstruction is: which rule fired, which option matched, what the packet actually contained, and what the rule's author intended that option to represent. The last of those four is not in the output. It lives in the author's head or in a comment, and the absence of it is why rule sets rot. When you find a rule whose intent cannot be recovered from its fields and its message, you have found a maintenance problem worth writing down.
The other habit is watching for the cases where nothing fired and asking the same question in reverse. Which rules were loaded, what did each one test, and would the behaviour you were looking for have produced any of those tests. A clean capture is only evidence about the rules that were actually present, and the room gives you enough visibility into the rule set to see how narrow that set is compared with the behaviour flowing past it.
08 · What a signature cannot express
Four questions, and none of them is a defect in the tool. They are limits of the instrument, and each one belongs to a different control.
Intent. The same bytes can be harmless in one deployment and hostile in another. A content match cannot distinguish a diagnostic request from an intrusion when the request is byte-identical, because the difference is in the context that produced it and the context is not on the wire. The control that answers this is knowledge of the systems, not a pattern.
Identity. Two flows can be indistinguishable in content, timing and volume while one is an approved agent and the other is an implant, which is precisely the measurement in today's field note. A signature can identify a protocol; it cannot verify a principal. The control that answers this is authentication with attribution, applied at the layer where the identity is known.
Authorisation. Whether an action was permitted is a property of a policy and a principal, not of a packet. A perfectly legitimate request to an endpoint nobody should be reaching produces traffic no signature has a reason to flag. The control that answers this is an access decision made where the resources are, which is the same conclusion I reached about object references in the IDOR companion.
Absence. This one is the most dangerous because it is the one that gets read as good news. A rule that never fires is a statement about the rule. It may mean the behaviour did not occur, or that it occurred in a form the rule does not test, or that the rule was never loaded, or that the sensor was not positioned to see the traffic. Four explanations, one of which is reassuring, and the alert output does not tell you which.
09 · Defensive controls and how to operate a rule set
| Gap | Durable control | What to log and review |
|---|---|---|
| Rule intent not recoverable from the rule | Require a message and identifier that state the behaviour, not just the bytes, so a reviewer can tell what the author assumed. | Rules with generic or missing messages, and rules whose content has not been reviewed since the protocol it targets changed. |
| Silence read as evidence | Test the rule set against known-positive traffic on a schedule, so you can distinguish a rule that does not fire from a rule that cannot. | The date each rule was last demonstrated to fire, kept per rule rather than per rule set. |
| Detection rules enabled for prevention | Promote a rule to a blocking action only after its false-positive rate is measured on production traffic, and keep the two stages separate. | Every change of action on a rule, with the evidence that justified the promotion. |
| Alert volume exceeding review capacity | Treat the queue as the constraint it is: a rule whose matches cannot be reviewed is not a detection. | Matches per rule per day, and the share of those a reviewer actually triaged. |
| Questions the instrument cannot answer | Route intent to system knowledge, identity to authenticated attribution, and authorisation to the resource layer. | Which of the four questions each control in the stack is responsible for, written down once and revisited when the estate changes. |
The second row is the one I would implement first, because it is cheap and it changes how the whole programme is read. If every rule has a date on which it was last shown to fire against traffic that should have triggered it, then silence stops being ambiguous and starts being a measurement.
10 · Misconceptions and troubleshooting
- "Nothing fired, so nothing happened." A non-match is a statement about the rule. The room's own exercises make the rule set visible enough to see how few behaviours it covers.
- "A signature detects an attack." A signature detects the bytes it describes. Whether those bytes constitute an attack is a judgement made by a human, or by a policy, using context the packet does not carry.
- "More rules means better coverage." More rules means more matches, and the constraint is review capacity. A rule set that exceeds it has traded detection for noise.
- "The sensor is the control." The sensor is instrumented visibility. The controls are authentication, authorisation and segmentation, and a signature is what you have when those have already failed to prevent something.
- "Tuning will eventually close the gap." Tuning improves the match rate against the behaviours you can describe. It cannot extend the instrument to questions that are not about bytes.
Troubleshooting comes down to the field. When a rule behaves unexpectedly, read which option matched rather than which message appeared, because the message is prose and the option is the test. When a rule behaves exactly as written, ask what the author was substituting for, because that gap between the test and the behaviour is where every future surprise lives.
11 · Memory aids and practice checklist
Memory aid: a rule describes packets, an analyst describes people. The work of reading detection output is translating between the two, and every error in that translation runs in one of two directions: attributing intent the bytes do not carry, or treating absence as evidence.
- Read the action before the content, and know which mode the sensor is in.
- For every rule, state what field it tests and what behaviour that field stands in for.
- Keep identifiers and versions current so the rule set can be reasoned about after a change.
- Demonstrate each rule firing against known-positive traffic on a schedule.
- Measure a rule's false-positive rate before promoting it to a blocking action.
- Track matches per rule and compare against review capacity.
- Route the four unanswerable questions to the controls that can answer them.
12 · What the room teaches
The lesson, once: a signature is a precise answer to a narrow question, and the discipline is knowing which question. The tool is honest about its scope. The risk is the reader who takes a clean alert log as a statement about the network rather than about the rules.
Read alongside the rest of this series it forms a pair with today's field note on agent traffic that scored 0.0 as a beacon, which is the same limit measured from the other side: there, a rule set did not fire on a class of traffic that was genuinely present, and the conclusion was not that the traffic was safe. The IDOR companion covers the third question in that list, authorisation, which no packet can answer.
Frequently asked questions
What is the difference between an IDS and an IPS?
They run the same rule logic in different modes. An intrusion detection system observes traffic and produces a record when a rule matches, leaving the traffic untouched. An intrusion prevention system sits inline and makes a decision about the traffic itself, dropping or rejecting what matches. The rule can be identical, which is why enabling prevention is a change in consequence rather than a change in detection.
What are the parts of a Snort rule?
Two parts. The header names the action, protocol, source, direction and destination, which together decide what happens on a match. The options carry the content and conditions to test, plus the rule's identifier, revision and the message an analyst reads. The header is about consequence and the options are about recognition, and reading them as separate decisions is most of what makes a rule set comprehensible later.
Why is a rule that never fires not proof of safety?
Because silence has four explanations and only one is reassuring: the behaviour did not occur, the behaviour occurred in a form the rule does not test, the rule was not loaded, or the sensor could not see the traffic. The alert output cannot distinguish between them, so the useful practice is to demonstrate each rule firing against traffic that should trigger it, on a schedule, and to record the date.
What can a signature not detect?
Four classes of question. Intent, because identical bytes can be harmless or hostile depending on context the packet does not carry. Identity, because an approved agent and an implant can be indistinguishable on the wire. Authorisation, because permission is a property of a policy and a principal rather than of a packet. And absence, because a non-match describes the rule rather than the traffic. Each belongs to a different control: system knowledge, authenticated attribution, and the resource layer respectively.
Primary references and further practice
- TryHackMe: Snort, official room
- Snort official documentation
- MITRE ATT&CK TA0005: Defense Evasion
- CWE-693: Protection Mechanism Failure
- MITRE ATT&CK DET0444: Detection of Command and Control Over Application Layer Protocols
- SANS: evaluating detection effectiveness of network monitoring tools against modern C2 frameworks