skip to content

IDS/IPS

You will learn how Snort and Suricata detect attacks via signatures and anomalies, when to deploy inline as an IPS versus passively off a SPAN port, and how attackers evade detection with fragmentation and encoding. Interviewers probe the detection-vs-prevention trade-off and false-positive tuning because both dominate real deployments.

on this pageshow

explore

questions

page 1 of 2

A Zeek-style sensor holds state per connection: what does it log about an intruder's session on a protocol no analyzer supports?

level: juniorimportance: must knowfreq 52%

answer

  1. one record per flow, nothing above it
  2. the service field stays empty
  3. no filenames, no hashes, no certificate subject
  4. raw payload is still searchable for bytes
  5. records exist before anyone is suspicious

basics

~20 s

Only a connection record - five-tuple, duration, byte counts, connection state - with the service field empty. No protocol facts, no filenames, no hashes, no certificate subjects. A byte-matching engine can still search that same payload for a fixed string.

solid answer

~50 s

A protocol-parsing sensor turns a stream into typed session facts only when an analyzer for that protocol exists and attaches. On a partner's proprietary protocol with no analyzer, dynamic protocol detection attaches nothing, so you get one connection record: source and destination addresses and ports, protocol, duration, bytes each way, connection state and TCP history, with the `service` field empty. You learn that 240 MB left your estate over eight hours; you learn nothing about what moved. The byte-matching sensor fails the other way round: it has no parsed fields either, but a `content` match over the raw payload still fires on a fixed marker - a filename, a magic number, a hardcoded token - because it needs no protocol understanding at all. That asymmetry is the point: parsing gives you rich facts only where somebody wrote an analyzer; matching gives you a thin answer anywhere, but only to a question you asked in advance.

code

text · 8 lines
text
ts=2026-03-14T02:11:07Z  uid=CHhAvV1
id.orig_h=10.20.4.9   id.orig_p=51422
id.resp_h=203.0.113.40 id.resp_p=9443
proto=tcp  service=(empty)
duration=812.4  orig_bytes=18442  resp_bytes=244102931
conn_state=SF  history=ShADadFf
...
(no TLS, HTTP or file record carries this uid - no analyzer attached)

go deeper

for a junior

Be ready to say exactly which fields survive when no analyzer attaches: addresses, ports, protocol, duration, byte counts, connection state. And be ready to say what does not: filenames, hashes, certificate subjects, anything above transport.

for a middle

Explain why dynamic protocol detection attaches nothing here, and why a raw content match still works on the same bytes. An interviewer wants the mechanism behind the asymmetry, not just the outcome.

for a senior

Show that you know which question each artefact can answer a month later. Records generated before suspicion support retrospective work; alerts only exist where somebody anticipated the pattern.

for a principal

Be able to argue what coverage on partner traffic you are actually buying, and what you would tell an auditor who asks what left the estate through an interface where neither sensor can name the protocol.

## Two ways of writing a detection down A network sensor can express what it knows about traffic in two very different forms. **Parsing into session facts.** A protocol-parsing sensor (Zeek is the reference implementation of this style) runs a per-protocol *analyzer* over each stream. The analyzer understands the grammar of the protocol, so it can emit typed records: a connection record for every flow, a DNS record with the query name and type, an HTTP record with method, host and URI, a TLS record with the client's SNI and the server certificate's subject and issuer, a file record with a MIME type and, if enabled, a SHA-256 of the reassembled object. Those records are produced whether or not anything is suspicious. The output is *evidence*, not a verdict. **Matching bytes.** A signature engine (Suricata is the reference implementation) takes rules that specify header preconditions and then look for byte content in the payload. The output is an *alert*: a rule fired, and nothing else was written down about that flow unless you asked for it. ## The correction most candidates need The common wrong answer is "Zeek parses, Suricata matches bytes" as though these were disjoint tools. Suricata also has application-layer parsers and emits protocol records of its own (TLS, DNS, HTTP, flow, file metadata) in its EVE output. The honest distinction is one of *model*, not of capability: the parsing sensor's primary product is a comprehensive typed log of everything it could decode, extended by scripting that can hold state across a session; the matching engine's primary product is a decision, taken where a rule author anticipated the pattern. ## What happens when no analyzer exists This is the case an extranet forces on you. A partner speaks a bespoke B2B file-transfer protocol on port 9443. No vendor ships an analyzer for it and no rule author has ever seen its wire format. - The parsing sensor's dynamic protocol detection tries its analyzers against the first bytes, none claims the stream, and the result is a single connection record with an empty `service` field. Duration, direction, byte counts and connection state are real and useful; everything above the transport is gone. - The matching sensor is not better off at the protocol layer, but it is not empty-handed either. Because a `content` match is just a search over bytes, a rule can still hunt a fixed string that the protocol happens to carry in the clear - a filename extension, an archive magic number, a hardcoded authentication token, a beacon's constant preamble. It will fire on that string in a protocol nobody has ever named. So the two postures miss *different* things. Parsing misses everything above the connection record on any protocol you did not teach it. Matching misses everything you did not think to ask for, on every protocol, including ones it parses perfectly well. ## Reading the direction of the claim A connection record proves that **bytes moved between two endpoints for a period of time**. It does not prove what they were, that a file was transferred, that anything was stolen, or that a human was involved. An empty `service` field proves that **no analyzer claimed the stream** - not that the traffic was benign, not that it was encrypted, and not that it was unusual. Candidates routinely over-read both. ## The price side Neither posture is free, and the price is what makes this a design question rather than a preference. The parsing sensor keeps a state record per connection and, when file extraction is on, per file in flight - so its ceiling arrives on concurrent sessions and reassembly buffers, not on link speed. Every analyzer you add multiplies that. The matching engine still tracks flows and reassembles streams, but the state it keeps for a raw content match is far shallower. Choosing to parse a partner protocol means writing and maintaining an analyzer for a wire format the partner can change without telling you, and paying memory for every concurrent session of it. Choosing to match means shipping a rule this week and accepting that a single byte of change in the partner's format silently retires your detection. ## What to say in the room Name the artefact each side produces (typed session facts versus an alert), state what the unparsed case degrades to on each side, and say out loud which one you would still have evidence from a month later when someone asks what left the estate on the 14th. The parsing sensor answers that question from records that existed before anyone was suspicious; the matching sensor answers only if a rule happened to fire.

  • The service field is empty. Name two innocent reasons and one that should worry you.
    Innocent: the protocol is proprietary and no analyzer exists for it, or the sensor only saw part of the stream so detection never got the opening bytes. Worrying: something is deliberately not speaking the protocol its port advertises, so no analyzer claims it. The field records a failure to identify, not a verdict, and all three look identical in the record.
  • If both sensors are blind above the transport, what can the connection record alone still support?
    Volume and direction over time, session duration, who initiated, and whether the connection completed or was reset. That supports a question like "did anything move outbound to this partner outside the nightly window, and how much" - a baseline and an anomaly, not an identification. It is enough to open an investigation and never enough to close one.
  • Why does adding a byte rule for the partner protocol not make the empty service field go away?
    A content match is a search over payload; it produces an alert, not a parsed record. The connection record still shows no service because no analyzer attached, and the alert tells you only that a byte string appeared in that flow. To fill the service field you would have to write an analyzer, which is a different piece of work with a different ongoing cost.

Parsing is a court stenographer who can only transcribe languages they speak; for an unknown language they can still record who spoke, for how long, and how loudly. Byte matching is a listener waiting for one specific word, in any language.

saying these in an interview costs you the question

  • Claims a byte-matching engine cannot parse protocols at all
  • Reads an empty service field as evidence the traffic was benign
  • Says parsing is strictly better than matching in every case
  • Thinks a connection record shows what was transferred
  • Assumes an unrecognised protocol means encrypted traffic

context

open as a page

An intrusion rule that has alerted on intruder traffic for months is set to drop - what changes about the cost of a wrong match?

level: juniorimportance: must knowfreq 65%

basics

~20 s

In alert mode a wrong match costs an analyst an hour. Inline, the identical match severs a live session. The rule's accuracy does not change - only who pays for its mistakes, which moves to whoever owns that traffic.

open as a page

When an inline IPS reboots at a single-box branch, what does its bypass relay do, and what does that cost against an intruder?

level: juniorimportance: must knowfreq 58%

basics

~20 s

A hardware bypass relay shorts the two inline ports together when the engine stops, so the branch link keeps carrying packets. You buy availability with inspection: everything in that window, an intruder's traffic included, crosses unjudged.

open as a page

An IDS suppression silences one signature for a scanner's whole /16 — what does an intruder inside that range gain?

level: juniorimportance: must knowfreq 62%

basics

~10 s

A suppression scoped to a /16 blinds the sensor for every host in that range, not just the scanner. Any address inside it can generate the matching traffic and the sensor emits nothing.

open as a page

Your inline IPS reassembles only the first megabyte of each flow to hold its latency budget — what does that give an intruder?

level: juniorimportance: must knowfreq 58%

basics

~20 s

Everything past the first megabyte of that flow leaves uninspected, so an intruder puts the payload behind a benign prefix. The limit exists because deeper reassembly costs buffer memory on every concurrent flow and adds latency.

open as a page

A 100G leaf uplink is mirrored to a 10G sensor port — what does the IDS miss when an intruder crosses at peak?

level: juniorimportance: must knowfreq 72%

basics

~20 s

Mirroring is best-effort: the switch copies up to the destination port's line rate and discards the rest without disrupting forwarding. At peak the sensor receives a fraction of the uplink, so an intruder's packets can simply never arrive.

open as a page

Why does a switch-port mirror miss an intruder pivoting between two containers on the same node, and what does capturing it cost?

level: juniorimportance: must knowfreq 62%

basics

~20 s

Two containers on one node exchange packets inside that node's kernel, so no frame ever reaches the switch a mirror copies. Seeing that hop means running capture inside every node, paid in CPU on the machines running production workloads.

open as a page

A provider mirror copies a TLS 1.3 session to your sensor - what can that sensor still tell you?

level: juniorimportance: must knowfreq 66%

basics

~20 s

Metadata only: the five-tuple, byte and packet counts in each direction, start, duration, record sizes and timing, the client handshake fingerprint, and the SNI when it is present. The payload stays encrypted, and in TLS 1.3 so does the server certificate.

open as a page

An IDS two hops upstream accepts a packet the server silently discards - is that insertion or evasion, and what must the sensor check?

level: middleimportance: must knowfreq 60%

basics

~20 s

That is insertion: the sensor holds bytes the endpoint never accepted, so the attack text is padded apart and no pattern matches. Avoiding it costs the sensor a model of the path - checksums, TTL, MTU and sequence sanity, all validated as the destination would.

open as a page

Which single-byte change from an attacker defeats a Suricata content match anchored with depth, and what does widening the anchor cost?

level: middleimportance: must knowfreq 45%

basics

~20 s

One byte of padding pushes the pattern past the depth window, and one changed letter defeats a match written without nocase. Widening the anchor means scanning the whole buffer on every packet and accepting more false positives, which on an inline sensor drops real traffic.

open as a page

Why won't a server's private key decrypt a TLS 1.3 session your sensor already captured?

level: middleimportance: must knowfreq 74%

basics

~20 s

TLS 1.3 derives session keys from ephemeral Diffie-Hellman shares that both endpoints discard, and the long-term key only signs the handshake. Escrowing it decrypts nothing - and on an outbound implant session you never held that key anyway.

open as a page

A purple-team replay of known-bad traffic raised no alert — how do you tell silent capture loss from a rule miss?

level: seniorimportance: must knowfreq 52%

basics

~20 s

Walk the delivery chain stage by stage and ask each one what it counted. If the sensor's own connection record for the replay is absent or truncated, packets were lost before matching; if the record is complete with the expected byte counts, the packets arrived and the detection is at fault.

open as a page

An attacker resends a TCP segment with different data - why can an IDS and the server rebuild different requests, and what must you configure per host?

level: juniorimportance: should knowfreq 48%

basics

~20 s

TCP does not define which copy of overlapping bytes wins, so different stacks keep different data - some the original, some the newer. A sensor several hops upstream must imitate the destination's choice, which means a reassembly policy set per address range.

open as a page

In a Suricata rule, what must an attacker's packet satisfy before the engine scans payload bytes, and what does that ordering save?

level: juniorimportance: should knowfreq 52%

basics

~20 s

The rule header - protocol, source and destination address and port, and direction - plus flow keywords are checked first. Only packets that pass reach the payload content match, so most traffic is discarded without any byte scanning.

open as a page

A protocol-parsing sensor is fed thousands of short sessions by an adversary - why does it exhaust memory on session count, not bandwidth?

level: middleimportance: should knowfreq 38%

basics

~20 s

State is held per connection and per file in flight, not per bit, so ten thousand tiny sessions cost far more table space than one large transfer. At the ceiling the sensor sheds records, not traffic.

open as a page

An inline IPS blocks intruder traffic into a plant zone - how do silent drop and reject differ for a device that never retries?

level: middleimportance: should knowfreq 48%

basics

~20 s

Drop discards silently, so a device that never retries hangs and the fault looks like broken equipment. Reject answers with a TCP reset or ICMP unreachable - fast, legible failure, but it confirms to the intruder that something is filtering.

open as a page

An inline IPS restarts while an intruder's session is open -- what can it judge about that flow when it returns?

level: middleimportance: should knowfreq 46%

basics

~20 s

Very little. It rejoins mid-stream with no handshake, no first request and no reassembly state, so it sees packets from a conversation it never saw begin. Its midstream policy decides whether to pass that flow blind or cut it.

open as a page

How does raising an IDS signature's rate threshold differ from suppressing it, and which still records an intruder?

level: middleimportance: should knowfreq 48%

basics

~20 s

A threshold caps how many events a signature emits per tracking key per interval, so a sample survives. A suppression emits nothing at all for its scope — and a threshold only keeps evidence if its key isolates each source.

open as a page

Your inline IPS fast-paths a flow to hardware after its first verdict to hold line rate — what does that give an intruder?

level: middleimportance: should knowfreq 46%

basics

~10 s

The verdict is bought with the opening bytes and then the rest of the connection is switched, not inspected. An intruder opens benignly and moves everything that matters afterwards, inside one long-lived flow.

open as a page

An inline sensor normalizes overlapping fragments so an attacker's traffic has one meaning - what does that cost you?

level: seniorimportance: should knowfreq 42%

basics

~20 s

You stop guessing each host's reassembly and start paying in state, latency and blame. The device buffers every partial reassembly, becomes a failure point in the path, needs a signed-for behaviour when it is overwhelmed, and drops some traffic the destination would have accepted.

open as a page

A partner protocol has no analyzer: do you parse it or byte-match it, and what does each cost when an intruder adapts?

level: seniorimportance: should knowfreq 40%

basics

~20 s

Byte matching ships this week, costs almost no state, and dies silently the day a byte changes. An analyzer gives durable session facts and answers to questions you never anticipated, but costs per-session state and permanent maintenance on a format the partner controls.

open as a page

Your Suricata rules read $EXTERNAL_NET -> $HOME_NET, but every employee is now a tunnel client in one address pool. Which attacker traffic is never evaluated, and what does fixing it cost?

level: seniorimportance: should knowfreq 34%

basics

~20 s

Client-to-client traffic inside the pool is home-to-home, so it never matches an external-to-home rule at all: a compromised laptop attacking a colleague over the tunnel is invisible. Widening both variables to any restores coverage and removes the cheap pre-filter, so payload evaluation runs on everything and the sensor starts dropping packets.

open as a page

An IPS rule matched only intruder traffic for 90 days - what does that license, and what does it not, before it may drop on a ward network?

level: seniorimportance: should knowfreq 52%

basics

~20 s

It licenses one claim: on traffic that actually crossed that sensor in that window, nothing benign matched. It says nothing about flows the window never contained - twice-yearly vendor maintenance, a rare failover - nor about firmware that changes next month.

open as a page

You must upgrade the one inline IPS at each of forty branches -- how do you sequence the bypass windows an intruder could ride?

level: seniorimportance: should knowfreq 37%

basics

~20 s

Never all at once and never on a permanently fixed slot. Pilot on the least valuable branch to learn the real window, stagger the rest, put the most sensitive sites last, and cost the callout before you start.

open as a page

You inherit 140 unowned IDS suppression lines — how do you retire them without a noise flood or leaving an intruder covered?

level: seniorimportance: should knowfreq 45%

basics

~10 s

Measure before deleting: find what each line currently swallows, rank by scope width against signature severity, remove the worst in staffed batches. Survivors need an owner, a reason and an expiry.

open as a page

Peak traffic exceeds your inline IPS pair's inspection capacity — which budget do you surrender first, and what does an intruder gain?

level: seniorimportance: should knowfreq 41%

basics

~20 s

Decide the degradation order in advance rather than letting the box choose. Surrender depth on low-value bulk paths before breadth, never fall into blanket bypass unannounced, and alert on entering degraded mode — because an intruder can time a transfer to your predictable peaks.

open as a page

East-west sensing on 300 nodes to catch an intruder's lateral hops: what grows fastest, and what does it consume?

level: seniorimportance: should knowfreq 41%

basics

~20 s

Sensor count grows with nodes, not links, and interior traffic volume dwarfs the perimeter feed you sized against. What it consumes first is node CPU and the uplink you backhaul copies over — the same link you are trying to monitor.

open as a page

An incident lead wants the payload of an implant's mirrored TLS session - what do you tell them?

level: seniorimportance: should knowfreq 47%

basics

~20 s

The plaintext never existed anywhere on the network path, so no retention setting or budget recovers it. Give them what the copy does support - volume, direction, destination, timing - and point the payload question at the endpoint.

open as a page

Finance refuses the broker upgrade: how do you state the peak blind window an intruder could cross so an owner can sign for it?

level: principalimportance: should knowfreq 38%

basics

~20 s

Express it as fabric coverage in a named time window, not as alert counts: at the busy hour we deliver only part of the mirrored traffic to the sensors, so a stated share of it is uninspected. Then convert random loss into chosen loss with a named owner and a review trigger.

open as a page

showing 1–30 of 40