An IDS suppression silences one signature for a scanner's whole /16 — what does an intruder inside that range gain?
answer
- output stage, not the packet path
- the alert stops, the traffic does not
- scope is addresses, not a device
- everything in the range inherits the excuse
- narrowest scope that kills the noise
basics
~10 sA 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.
solid answer
~50 sA suppression is a rule at the sensor's output stage: for this signature, in this address scope, emit no event. The engine still matches the traffic; only the record disappears. So the scope is the blind spot. If the noise came from one weekly scanner but the line was written as the whole /16 it lives in, then every host in that /16 — a compromised print server, a laptop on the same VLAN, or the scanner itself once someone owns it — can do the thing that signature detects and nothing is written down. The scanner is an attractive place to stand precisely because it is the box everyone excused. The fix is to write the narrowest scope that actually removes the noise (signature plus source plus, where you can, destination and time window), and to record what the line hides so someone can price it later.
go deeper
Be ready to say plainly that a suppression removes the event, not the packets, and that its scope is an address range rather than a machine. Know that every host in that range inherits the silence.
Explain where suppression sits in the sensor pipeline — after matching, before output — and how a line written for one noisy host widens into a subnet over time. Be able to list the axes you can narrow on.
Show the judgment: the narrowest scope that removes the noise, a compensating view where the risk warrants one, and a record of what the line hides so it can be re-argued later rather than inherited blindly.
Own the position that an exception without a named owner and an expiry is an undocumented reduction in coverage, and that the estate needs a place where such reductions are visible rather than buried in a sensor config.
## What a suppression actually is A network intrusion sensor evaluates traffic against signatures and emits an event when one matches. A **suppression** is a rule at the sensor's *output* stage: for a named signature, within a named address scope, emit nothing. It is not a filter on traffic, not an edit to the signature's logic, and not a decision about whether the packet is allowed. The engine still inspects and still matches. What disappears is the record. That distinction is the whole question, and it is where a weak answer goes wrong. "We suppressed the scanner" sounds like the scanner was dealt with. Nothing was dealt with. On a sensor that only alerts, the traffic was never being stopped in the first place, so the only change is that you can no longer see it. On an inline sensor, whether an enforcement action survives the suppression depends on how that sensor separates *emit an event* from *act on the packet* — treat them as two knobs and verify which one you actually turned, because the worst outcome is a rule that still drops while nothing at all is logged, leaving help-desk tickets as your only telemetry. ## Why the scope ends up wider than the noise The noise that justifies a suppression is usually specific and boring: a vulnerability scanner walks a campus every Sunday and one scan signature fires ten thousand times. The fastest fix is one line naming that scanner. But a single host address breaks when the scanner is rebuilt on a new address, and it breaks again when a second scanner appears, so the line gets widened to the subnet, then to the management range, and in the worst case the address clause is dropped altogether and the signature is silenced estate-wide. Each widening is a trade made in one direction only: the quiet is immediate and certain, the blindness is contingent on an adversary who has not arrived yet. Nobody is in the room to argue for the cost. | Suppression written as | What it silences | What an intruder needs | | --- | --- | --- | | signature, no address clause | that signature, everywhere | nothing at all | | signature + /16 | every host in the range | any address in the range | | signature + scanner host | one host | that host, or its address after it moves | | signature + host + destinations + window | one host, known targets, Sunday | that host, in that window, to those targets | ## What the intruder actually gets They get a place to stand where one class of behaviour is free. It does not require compromising the scanner: a workstation on a wall socket in the same range inherits the excuse. Compromising the scanner is better still, because a scanning host is trusted enough to be excluded from detection *and* it usually reaches every segment on the site, which is precisely why it was noisy enough to suppress in the first place. The uncomfortable property of this blind spot is that it is silent in both directions. A suppression produces no alerts by definition, so there is no signal that says "this line is now covering someone". The only way to find out is to look on purpose. ## The debt part Every suppression line is an assertion about the world: *traffic matching this signature from this scope is benign*. Assertions decay. The scanner is retired, the range is re-purposed for a lecture theatre's wireless clients, the signature is rewritten upstream and now means something narrower or broader than it did. Nothing in the sensor tells you the assertion has expired, and the person who could have told you has left. So the line needs the things a comment cannot supply on its own: a **named owner** who can still be asked, a **stated reason** that names the noise it was written against, and an **expiry date** after which it must be re-argued rather than inherited. If no living person will own a line, that is itself the decision — delete it and accept the noise for a week while you write a narrower one. ## What a good exception looks like - The narrowest scope that removes the noise, including destination and time where the sensor supports it. - A threshold rather than a suppression wherever a sample of the events is enough, so evidence survives. - A record of what it hides, written at the moment it is written, not reconstructed later. - A compensating view where the risk warrants one — the same traffic still visible at lower severity, or on a sensor that does not carry the exception file — so the silence is recoverable. - A review when the address plan changes, because the scope is written in addresses and the addresses move.
- The scanner is rebuilt on a new address every quarter. What does that do to a host-scoped suppression?It stops matching, the noise returns, and someone widens the line to a subnet to make it stop again — which is exactly how /16-wide suppressions get written. The better answer is to pin the scanner's address, or scope by source and destination and the scan window together, so the line is stable without being broad.
- How would you write the same exception so an intruder inside the range still shows up?Add every axis the sensor gives you: the specific signature, the specific source, the destinations the scanner is supposed to touch, and the window it runs in. Or use a rate threshold instead, so the noise is capped but a sample survives. Anything left outside the intersection still alerts.
- Someone argues another signature would still catch an intruder in that range. How do you check?Do not take it on trust — name the other signature and confirm it is loaded, that it is not itself suppressed for that scope, and that it fires on the same behaviour rather than a narrower variant. Then test it deliberately from inside the range so the claim is evidence rather than an assumption.
It is like taping over a smoke detector because the toaster sets it off, then moving house and leaving the tape on. The tape covers the whole kitchen, not the toaster, and nothing reminds you it is there.
saying these in an interview costs you the question
- Says the suppression stops the scanner's traffic
- Assumes the line only affects the scanner host
- Treats suppression as permanent tuning, never revisited
- Cannot say what the line hides or who owns it
- Assumes another signature covers it without checking