Block the attack. Not the customer.
Why operator IPs get blocklisted
Banking portals, government services and payment processors run their own abuse detection. They do not see your subscriber — behind CGNAT they see your public address. When a compromised CPE, a botnet client or a credential-stuffing script hammers their login endpoint, the address that gets listed is yours, and it is shared by hundreds of innocent subscribers.
The damage is collective
One infected device. One shared public IP. Every subscriber behind it starts seeing CAPTCHAs, refused logins and blocked payments — for something none of them did.
Delisting is slow and manual
Getting removed from a bank's or a reputation provider's list is a support ticket measured in days, not minutes — and it recurs the moment the same device resumes.
You often find out from customers
The first signal is usually a complaint, not an alarm. By then the listing already exists and the abuse has been running for hours.
Cutting the customer off is its own cost
Suspending the line stops the abuse and starts a support call, an angry customer and a truck roll — for a device fault the subscriber may not even know about.
Blunt versus surgical
Every abuse response is a choice about blast radius. The conventional options act on the subscriber. Surgical blocking acts on the flow.
What actually happens, automatically
Surgical blocking is not a manual tool an engineer reaches for after the damage. It is wired into the abuse escalation the BNG already runs on every subscriber, in the forwarding path, continuously.
What the operator sees
Nothing about this is a black box. The block is visible, named, counted and explainable to a customer who asks why one thing stopped working.
Option A — do nothing. The abuse continues, the listing happens, hundreds of innocent subscribers are affected, and delisting takes days.
Option B — punish the subscriber. Rate-limit or suspend the line. The abuse stops, and so does everything the customer legitimately does. One support call per incident, minimum.
The attack flow is dropped at the BNG. The destination under attack stops receiving anything from that subscriber, so no reputation damage accrues to your address.
The customer keeps working. Email, browsing, VPN, streaming, gaming — untouched. Most subscribers never learn it happened, and the block lifts itself when the device is cleaned or stops.
Why this is hard to do anywhere else
The capability sounds simple and is not, because of where the decision has to be made. Three things must be true at the same moment, and only the BNG has all three.
1 · You must still know who the subscriber is
After CGNAT, the subscriber's identity is gone — hundreds of customers share one public address. A firewall, scrubbing appliance or upstream router placed after the BNG sees only the shared address, so it cannot block one customer's flow without blocking everyone's. The BNG is the last place the subscriber is still individually known.
2 · You must track behaviour per subscriber, per destination
Deciding that this subscriber is attacking that destination needs per-subscriber, per-destination state maintained continuously at line rate — for every subscriber on the box, not a sampled few. That is a data-path capability, not a management-plane report.
3 · The rule must be installed and removed in seconds
An abuse block that requires a config commit, a CLI change or a device reload is an incident-response process, not a control. This one is written into the forwarding table by the detector itself and expires on its own.
What conventional designs do instead
Static ACLs block a destination for everyone, which is unacceptable when the destination is a bank. Subscriber policers are blunt by construction — they act on the whole line. Detection-only tooling reports abuse to a human hours later. None of these is a per-subscriber, per-flow, automatic control.
| Capability | Upstream firewall / scrubber | Router ACL | Subscriber policer | BNGSOFT surgical |
|---|---|---|---|---|
| Knows which subscriber behind CGNAT | No — sees shared IP | No | Yes | Yes |
| Blocks one flow, not the whole line | Not per subscriber | Blocks for everyone | Whole line | Exact ip:port:proto |
| Armed automatically on detection | Usually manual | Manual | Manual / static | Automatic |
| Releases itself when abuse stops | Manual | Manual | Manual | Automatic |
| Customer stays fully in service | n/a | No | No | Yes |
Measured, not asserted
The figures below were taken on a live BNG carrying 1,600 concurrent subscriber sessions, with a controlled attack generated from one of them. They describe the behaviour of the shipping implementation, not a model.
| What was measured | Result |
|---|---|
| Time from attack start to block armed | ~12 seconds |
| Attack traffic dropped once armed | the attacked flow, in full |
| Subscriber's other traffic affected | none — same host on another port, and other destinations, both continued |
| Subscriber rate-limited or quarantined as a whole | no |
| Other subscribers on the box affected | none of the remaining ~1,600 |
| Block released after the attack stopped | automatically, on expiry of the idle hold |
| Forwarding cost when no block is armed | a single flag test per packet |
Where it fits
Surgical blocking is the precise end of a graduated response, not a replacement for the rest of it. A subscriber spraying thousands of destinations is a different problem from one hammering a single bank, and the BNG treats them differently.
Focused abuse → surgical
Credential stuffing, login-page hammering, a script attacking one endpoint. Few destinations, high intensity. Block the flow; the customer keeps their service.
Spray abuse → isolation
Port scanning and botnet fan-out across many destinations. Here the subscriber-level response is the correct one — quarantine and, if configured, a move to a dedicated penalty address so the shared pool's reputation is protected.
Both run from the same per-subscriber measurement in the data path, and both release themselves when the behaviour stops. The operator chooses the posture; the box chooses which response fits the observed behaviour.
{subscriber, destination IP, destination port, protocol}; only packets matching that exact tuple are dropped. Entries are released automatically once no packets have matched for the configured idle period, and the enable flag is reconciled against the real table so the data path stops paying for the feature when nothing is armed. An observe mode counts what would be dropped without dropping it, and operators can add, list and remove entries manually at any time via bngxdpctl protect surgical. The figures in "Measured, not asserted" come from a controlled test on a lab BNG carrying ~1,600 sessions in which a single subscriber attacked a single destination; timings depend on attack intensity and on the configured thresholds, and a low-intensity attack that stays below the detection thresholds will not arm a block. The comparison table describes architectural categories of equipment placement and control granularity, not benchmarks of specific competing products. Surgical blocking reduces the abuse leaving your network; it cannot remove an address from a third party's blocklist, and it does not clean the compromised customer device. Spray-pattern abuse across many destinations is handled by subscriber-level quarantine and optional penalty-IP isolation instead. Related briefs: CGNAT Abuser Auto-Isolation, Edge DDoS Protection, Full CGNAT.