A service you run answered forged requests in a stranger's flood; why won't patching it help?

## Why the instruction is wrong "Patch it" assumes a defect. Walk through what your host actually did. It received a well-formed request on a service it was intentionally running. It parsed that request successfully. It produced the answer the specification says that request deserves. It addressed the answer to the sender address the request carried, because that is the only destination information a connectionless request supplies. Every step is correct behaviour. No memory was corrupted, no authentication was bypassed, no code ran that you did not install, and no attacker holds anything on the host. There is therefore no upstream fix to consume. The current release does this. The next release does this. A vendor cannot ship a change that makes the service stop answering the address it was handed, because answering the address it was handed *is the service*. This is the single most common wrong answer in the area, and it is a wrong answer given by experienced engineers, because "our box participated in an attack" pattern-matches so strongly to "our box is owned". The classification you want is **abused as designed**, not compromised. ## The vocabulary that keeps the analysis straight - The **victim** has an availability problem caused by traffic they did not solicit. - The **answerer** — you — has an abuse cost: capacity spent on someone else's flood, and your addresses appearing as the source of an attack. You have no defect and no symptom. - The **attacker** never touched either host beyond sending well-formed requests to one of them. Getting this straight matters practically, because the response is entirely different. A compromise means eviction and re-entry hunting. Abuse-as-designed means a configuration or design decision, made calmly, with no urgency of your own — which is exactly why it so often does not get made. ## What actually changes the outcome ### Lever one: scope Decide which networks may reach the service. An internal lookup service that never needed to answer arbitrary internet clients should not; a service that legitimately serves a known set of customer networks can be constrained to them. This does not repair anything — the behaviour is unchanged for anyone still permitted to ask — but it removes your hosts from the population an attacker can address. Scope is the cheapest and most common remedy, and it is a decision about who your service is for, taken by whoever owns that answer. ### Lever two: a return-path proof in the exchange The attack depends on one thing it cannot substitute for: the answerer commits a large payload to an address on nothing but the request's own claim. Remove that and the technique dies. The general control class is a **return-routability check** — before spending the expensive answer, send something small to the claimed address and require it back. A cookie or token echoed in a cheap second exchange does this without a full connection setup. Why the attacker cannot work around it: they can put whatever address they like in a request, but the cheap challenge goes to that address, not to them. Completing the exchange requires receiving at the address, and receiving is the part reflection cannot fake. The economics also invert — the pre-answer exchange is small in both directions, so the factor collapses to roughly 1 and the technique stops being worth its cost. ### Lever three, partial: shrink the answer If a specific bulky request is what makes your service attractive, retiring or gating that request type reduces the factor without changing anything else. This is how several protocols have historically responded: the enormous-answer request is removed from default builds. It reduces the ratio; it does not remove reflection, since a smaller answer still goes to a third party. ## Be precise about what a patch could and could not do One honest nuance: a *release* can change a default. If a maintainer ships a build that binds to a local interface by default, or drops the bulk request from the default configuration, then upgrading does reduce your exposure. But notice what happened — the release changed a **default configuration**, not a defect. The mechanism is still exactly as it was for anyone who turns the option back on. Saying "we upgraded and it went away" without knowing which default moved leaves you unable to answer the only question that matters: can a client on an arbitrary network still make this host send bytes to a third party? ## How to answer this in an interview Refuse the framing first, in one sentence: nothing is broken, so there is nothing to patch. Then classify: abused as designed, an availability problem for a stranger and an abuse cost for you. Then give the two levers and say which one you would reach for and why, and name the property the attacker cannot substitute — receiving at the address they claimed.