DDoS Protection in an Operator Network: How an Anti-DDoS System Works in Practice

A DDoS attack in an operator network rarely looks the way cloud providers' marketing materials portray it. It is not a single incident on one server, but a problem at the level of the link, the edge router and the entire address pool of customers. For an ISP, a data center or a telecom operator, the question is not "if it happens to us", but "what will happen when 20 Gbps of junk traffic hits our upstream in the middle of the night". This article is a practical look at DDoS protection from the perspective of an operator network: what types of attacks there are, what anti-DDoS really looks like at the infrastructure level, and why an anti-DDoS system running on-premise, on your own hardware, has a different rationale for an operator than for a single company with one website.

A DDoS attack is a distributed denial-of-service attack: traffic generated simultaneously from many sources, aimed at exhausting resources such as bandwidth, the connection table or CPU on edge devices. For a single company, the victim is usually one IP address or one domain. In an operator network, the scale of the problem is different: an attack can hit one address from a customer's pool and still saturate the entire upstream link, taking bandwidth away from all other customers connected to the same interconnect. This phenomenon, sometimes called "collateral damage", is more painful for an ISP than the mere unavailability of one service, because the whole network pays for it, not just the attacked customer.

The second problem specific to operators is so-called carpet bombing: an attack in which traffic is spread across many IP addresses from one subnet or a customer's entire block, so that no single address exceeds the alarm threshold, while the sum of traffic to the whole subnet floods the link anyway. Classic systems monitoring traffic per IP address will not catch such a pattern. Aggregation at the prefix level is needed.

Volumetric attacks are the easiest to understand and still the most common. Their goal is to saturate bandwidth: UDP flood, DNS amplification, NTP or other reflection/amplification techniques, where the attacker sends a small request with the victim's spoofed source address, and the response comes back many times larger. Defense against this type of attack must work at the interconnect with the upstream, before the traffic even enters the operator's network, hence the importance of mechanisms such as BGP FlowSpec and blackholing.

Protocol attacks target connection state, not bandwidth itself. A classic SYN flood can take down a router or server at a relatively small traffic volume, because it exhausts the connection table, not the link. This is precisely the type of attack that can be the most insidious: the volume-based alarm may not trigger, and the service is already not responding.

A variant is also increasingly appearing that combines a stateful protocol attack with an attempt to bypass classic volumetric protection: a wave of SYN-ACK, ACK or RST packets with no corresponding outgoing SYN, aimed directly at the BRAS/concentrator interconnect. The volume is sometimes too low to trigger a reaction from a system based solely on traffic thresholds, and yet it can clog connection state on access devices.

Effective DDoS protection for an operator rests on several complementary mechanisms, not on one universal solution.

Detection through traffic analysis. An anti-DDoS system must see traffic to detect anything, most often via a SPAN port or an optical Link TAP, in receive-only mode from the upstream direction, with no interference in the packet path. As a result, detection introduces no risk to production traffic: if the detection system itself fails, the network keeps running normally.

Mitigation through BGP FlowSpec. When the system detects an attack, it generates FlowSpec rules and passes them to the operator's edge router over a BGP session. The router programs the rules in hardware and filters traffic at an early stage, before it burdens the rest of the infrastructure. This solution works locally, between the anti-DDoS system and the operator's own routers. It does not require FlowSpec support from the upstream provider, it is enough that the upstream honors standard blackholing communities. The condition is hardware with FlowSpec support in hardware; the proven list includes Juniper MX/PTX and Cisco ASR1k/9k/NCS5500 SE/8000, among others. With other hardware, e.g. Huawei, standard RTBH should work, but FlowSpec support requires verification per model.

Blackholing and selective RTBH. Where FlowSpec is not enough, because the attack exceeds the capacity of the upstreams or the hardware does not support it, RTBH remains, that is, redirecting traffic to the attacked address into a null route. The difference between simple blackholing of a whole subnet and selective blackholing of individual /32 addresses is crucial for an operator: the latter makes it possible to cut off only the address actually under attack, instead of sacrificing the customer's entire pool, including addresses that are not the target of the attack at all.

Protection against carpet bombing. Requires aggregation of traffic at the prefix level, not the individual IP address, otherwise a distributed attack on the whole subnet will go unnoticed even though in total it floods the link.

Stateful inline filtering. For protocol attacks of the SYN-ACK/ACK/RST type with no corresponding outgoing connection, DDoS protection at the FlowSpec or RTBH level is not enough: this is an attack on connection state, not on volume. What is needed here is an engine that tracks the state of TCP connections bidirectionally, placed inline between the edge router and the BRAS or concentrator, which drops packets that match no known session. This solution makes sense as a complementary layer, not a replacement for volumetric protection: if the attack saturates the upstream link itself, no stateful filter will fix that until RTBH relieves the link.

For a company with one website, a cloud service is often the natural choice: redirecting traffic through an external data center at the moment of an attack. For an operator that is itself a link provider, the situation is different. Redirecting all customer traffic through external infrastructure means additional latency, dependence on a third party and loss of control over exactly how the traffic of one's own customers is filtered.

An anti-DDoS system running on-premise, on the operator's hardware, addresses this problem differently: detection and mitigation happen in the same network, without taking traffic outside, and the decisions about what is an attack and what is not are made by the operator, not by an external provider. This approach requires its own hardware and maintenance, but eliminates dependence on a third party at the most critical moment, during the attack.

DDoS protection today is not only a matter of service availability but also a regulatory obligation. Operators of essential and important services covered by the NIS2 directive and the national act on the national cybersecurity system must implement appropriate technical and organizational risk-management measures, and DDoS incidents of an appropriate scale are subject to the obligation to report to the CSIRT. An anti-DDoS system that generates ready reports in the required scope of data shortens the time needed to fulfill this obligation, although actually submitting the report in the CSIRT system still remains the operator's responsibility.

DDoS protection for an operator is not one product but a set of complementary mechanisms matched to the attack layer: FlowSpec and selective RTBH at the network level for volumetric attacks, per-prefix aggregation for carpet bombing, stateful inline filtering for protocol attacks that bypass classic volume thresholds. An anti-DDoS system running on-premise, on your own hardware and in your own network, gives the operator something a cloud service cannot: full control over how and when traffic is filtered, with no intermediary at the most critical moment.

If you are wondering what deploying the LiveShield anti-DDoS system in your network looks like, what hardware will be needed at your traffic volume and which edge routers support FlowSpec, the simplest starting point is a conversation about your specific network topology.