A Zeek-style sensor holds state per connection: what does it log about an intruder's session on a protocol no analyzer supports?
answer
- one record per flow, nothing above it
- the service field stays empty
- no filenames, no hashes, no certificate subject
- raw payload is still searchable for bytes
- records exist before anyone is suspicious
basics
~20 sOnly 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 sA 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 linests=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
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.
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.
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.
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