An IDS two hops upstream accepts a packet the server silently discards - is that insertion or evasion, and what must the sensor check?
answer
- two opposite errors, one identical symptom
- extra bytes versus missing bytes
- the sensor stands several hops away
- TTL, MTU and checksums do the work
- closing it needs a model of the path
basics
~20 sThat 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.
solid answer
~50 sThe two failure directions are opposites and interviewers ask them together. **Insertion** is the sensor accepting data the endpoint rejects: the sensor's reconstruction contains extra bytes, so a pattern that would have matched is split apart. **Evasion** is the endpoint accepting data the sensor rejected or never saw: the sensor's reconstruction is missing bytes, so the attack is only complete at the destination. A packet the sensor accepts and the server drops is insertion - and the attacker gets it cheaply, because the sensor stands several hops upstream with a different view of the path. Set a TTL that expires between sensor and host, exceed a downstream link's MTU with the do-not-fragment bit set, or send a deliberately bad checksum: in each case the sensor sees bytes that never arrive. Closing it means the sensor must validate what the path and the destination would reject, which is exactly the per-path knowledge it does not naturally have.
go deeper
Learn the two words and which way each runs: insertion means the sensor holds bytes the host rejected, evasion means the host holds bytes the sensor never had.
Be able to give a concrete mechanism for each - a TTL that expires past the sensor, a bad checksum, an overlapping retransmission - and explain why the sensor's distance from the host is what makes them work.
Explain what closing each direction actually costs: local validity checks are cheap, path-dependent checks need per-destination hop and MTU knowledge that goes stale with every routing change.
Own the choice between maintaining a per-path model and putting a device in line to remove the ambiguity, including who absorbs the latency, the state and the false drops that choice creates.
## Two names for two opposite mistakes A sensor's whole job here is to reconstruct the stream the destination will see. There are exactly two ways for that reconstruction to be wrong, and they are worth naming precisely because candidates routinely collapse them into a vague *the IDS missed it*. **Insertion.** The sensor accepts data the endpoint does not. Its reconstruction contains bytes the application will never process. The attacker uses this as padding: sprinkle segments that only the sensor will keep through the middle of the attack, and any anchored pattern is broken up by garbage that only exists in the sensor's copy. **Evasion.** The endpoint accepts data the sensor does not. The sensor's reconstruction is missing bytes, so the attack is only whole at the destination. Overlap resolution is the classic route: the sensor keeps one version of the conflicting bytes, the host keeps the other. Both end in a missed detection, so the outcome looks the same from the console. The cause and the fix do not. ## Why the sensor is easy to feed The sensor is not the destination and does not stand where the destination stands. It is several hops upstream, and everything between the two is invisible to it unless it is told. That distance is the resource the attacker spends. - **TTL differential.** Every forwarding hop decrements the IP time-to-live and discards the packet at zero. Craft a packet whose TTL is just large enough to reach the sensor and not the host, and the sensor holds bytes that expired in transit. - **MTU differential.** A packet larger than a downstream link's maximum transmission unit, with the do-not-fragment bit set, is dropped by that link. The sensor saw it; the destination did not. - **Validity the sensor does not check.** A deliberately bad checksum, a segment outside the receiver's advertised window, a bad or malformed option: the host discards it, and a sensor that does not model those rules keeps it. - **Overlap resolution.** Covered above, and it is the route that produces evasion rather than insertion when the attacker gets it right. None of this requires a position on the path or any compromise. It requires knowing roughly what sits between the sensor and the server, which a few probes will tell you. ## The price of closing each direction This is the half a weak candidate skips. Insertion is closed by making the sensor behave like a strict receiver: verify checksums, enforce window and sequence sanity, discard what a real stack would discard. That work is cheap in principle and costs per-packet processing at line rate. The path-dependent parts - TTL and MTU - are not cheap at all, because they demand knowledge the sensor cannot derive from the traffic: how many hops lie beyond it to each destination, and what the smallest link on that path is. Both change under you when routing changes, and neither is expressible as a single global number. Evasion is closed by knowing the destination's reassembly behaviour, which is the address-range policy map and its ongoing maintenance cost. So the honest summary is that a passive sensor closes these by carrying a model of the estate and the paths through it, and that model is a configuration artefact somebody has to keep true. The alternative posture - having an in-path device rewrite ambiguous traffic so there is only one interpretation - trades that maintenance for latency, state and the risk of breaking legitimate flows. ## Getting the direction of the claim right A sensor's silence is not evidence that nothing happened; under insertion the sensor is looking at a stream that never existed anywhere. Conversely, an alert on reconstructed content is evidence that the sensor's reconstruction matched, not that the destination received or acted on those bytes. On an inline device that distinction stops being philosophical: a reconstruction the destination would never have assembled becomes a dropped connection for a real user, and somebody will ask you to justify it. ## What a good answer sounds like Name both directions, give one concrete mechanism for each, and then say what closing them costs. If the candidate can add that insertion and evasion can be combined - insert padding into the sensor's view while the endpoint's overlap resolution quietly assembles the real request - they have understood that the sensor's reconstruction is a prediction rather than an observation.
- Give an example that produces evasion rather than insertion.Overlapping segments where the sensor keeps the first copy and the destination lets the later copy overwrite. The sensor assembles a harmless request, the server assembles the attack. Fragment overlap does the same thing at the IP layer, and a sensor whose fragment timeout is shorter than the host's gives you another route.
- Which of the two is cheaper for a defender to close, and why?Insertion by validity checking is the cheaper half: checksum, window and option sanity are local rules the sensor can apply without knowing anything about the path. The TTL and MTU variants are expensive because they need per-destination path knowledge that changes when routing does. Evasion needs the reassembly-policy map and its upkeep.
- Does an inline device that drops what it cannot resolve solve both directions?It removes much of the ambiguity, because a single interpretation is forwarded and nothing else reaches the host. What you buy it with is state, latency, a new in-path failure point and a decision about what happens to traffic when the device is overwhelmed - and a strict device drops some legitimate traffic that the destination would have accepted.
saying these in an interview costs you the question
- Uses insertion and evasion interchangeably for any missed detection
- Says a low TTL causes evasion rather than insertion
- Claims all sensors validate checksums by default
- Thinks the attacker needs on-path access to exploit the distance
- Treats no alert as evidence that nothing reached the server