Why DDoS Protection Has Become the No. 1 Priority for Internet Service Providers in 2026

During the first half of 2026, Cloudflare mitigated 935 network-layer DDoS attacks exceeding 1 Tbps, while their number increased by 519% quarter over quarter, according to the Cloudflare DDoS Threat Report H1 2026. For a telecom operator, this is not an abstract statistic: every such attack travels through the backbone capacity you lease and the subscriber access infrastructure you operate. DDoS protection is no longer an optional feature for large internet service providers. It has become a fundamental network architecture requirement.

At COSMONOVA, we see this challenge from two perspectives: as an operator maintaining connectivity and data centers, and as a partner to ISPs that need predictable network infrastructure. Below, we examine how attacks disrupt networks, how to build detection and filtering capabilities and a scrubbing center, and what procedures NOC and SOC teams should have in place before the first traffic spike occurs.

Attention

One of the most common ISP mistakes is assuming that a “100 Gbps link can handle anything.” An attack reaching 31.4 Tbps, recorded in late 2025 according to SentinelOne DDoS Attack Statistics 2026, can overwhelm any commercial upstream link. Without filtering at the source, you end up paying for traffic you do not need.

How Network- and Transport-Layer Attacks Disrupt ISP Infrastructure

Network- and transport-layer attacks target bandwidth rather than applications. Their goal is to overwhelm a link and deny service to all subscribers connected to the affected network segment.

Network and Transport Layers: Floods, Link Congestion, and Packet Traffic Density

At the network layer, attackers use ICMP floods, fragmentation, and source address spoofing. At the transport layer, common techniques include SYN floods, UDP floods, and amplification attacks through open resolvers. The key metric is not traffic volume in gigabits, but packet traffic density: millions of small packets per second can bring down a router before the available bandwidth is exhausted.

That is why backbone packet filtering must operate according to defined rules, not just traffic-volume thresholds. SentinelOne reported a 168.2% year-over-year increase in network-layer attacks in early 2026. Treating these incidents as rare exceptions is no longer realistic (DDoS Attack Statistics 2026: 41 Key Facts and Trends).

Application Layer: Flood Requests to DNS and Subscriber Services

The application layer is more dangerous because the traffic can look legitimate. DNS query floods, repeated requests to a self-service portal, and abnormal activity in billing APIs may all remain within expected traffic volumes while still taking a service offline.

Two attack vectors are particularly important for ISPs: their own recursive resolvers and subscriber-facing services such as personal accounts, IPTV, and VoIP. These require rate limiting, web application firewalls, and behavioral analysis—not simply blocking traffic sources.

Detecting DDoS Attacks on a Network: Metrics, Traffic Anomalies, and Response Time

Network DDoS detection relies on continuously comparing current traffic patterns against a baseline for each network segment and subscriber. A simple threshold such as “too many gigabits” is not enough. Anomalies can be identified through packet-to-byte ratios, source distribution, and sudden increases in new sessions.

What to monitor first:

• Packets per second on every upstream link and peering connection.

• Packet-to-byte ratio: small-packet floods become visible almost immediately.

• Source entropy: an increase in the number of unique addresses per minute.

• Detection time and mitigation time—the two metrics that determine the scale of the damage.

If detection takes 10 minutes and mitigation takes another 15, subscribers may already have switched to a competitor. The target for an operator should be automatic activation of filtering rules within one minute after an anomaly is confirmed.

DDoS Traffic Filtering: Rules, Rate Limiting, and Protection for Legitimate Subscribers

DDoS traffic filtering is a set of rules applied at the network perimeter and within a scrubbing center to discard malicious traffic while allowing legitimate traffic through. The main risk is not only failing to stop an attack, but also blocking your own subscribers.

A practical set of filtering rules for an ISP:

• Signature-based packet filtering: SYN without ACK, invalid flags, and RFC1918 address spoofing on external interfaces.

• Rate limiting for DNS, NTP, and portals, applied per source and per destination.

• Geographic filtering only as a temporary measure when an attack from a specific region has been confirmed.

• Source blocking through BGP announcements (blackholing), with a mandatory rule expiration time.

• Exception lists for critical subscribers and partner networks.

Professional Tip

A blackhole rule without a timer is one of the most expensive filtering mistakes. Configure automatic withdrawal of the announcement within no more than 30 minutes and log every occurrence. Otherwise, a single incorrect prefix can cut off a subscriber's entire traffic flow for a full day.

False positives can be more costly than a missed medium-scale attack. That is why filtering rules should be introduced in stages: first in monitoring mode, then with bandwidth restrictions, and only afterward with full blocking.

Scrubbing Centers for Internet Service Providers: Traffic-Cleaning Architecture and Routing

NOC engineer wearing a headset in front of multiple monitors displaying network traffic graphs in a modern control center, dim lighting, focused expression.

A scrubbing center for an ISP is not simply a “box with filters.” It is a facility with sufficient capacity, traffic-cleaning equipment, and, most importantly, a carefully designed traffic redirection and return-routing scheme. The key challenge is directing traffic to the center and returning it without losing the route or degrading service for legitimate subscribers.

Deployment Options: On-Premises, Cloud, and Hybrid Scrubbing

There are three basic deployment models for an ISP. The choice depends on the attack profile and the economics of the network.

On-premises scrubbing center. Traffic-cleaning equipment is installed at your facility, usually near an internet exchange point or in a data center where upstream links converge. Advantages include full control, predictable latency, and no dependence on an external provider. Disadvantages include capital expenditure on capacity that may remain idle most of the time and the need to maintain in-house engineering expertise.

Cloud scrubbing. Traffic is redirected to the service provider's center through a GRE tunnel or a dedicated connection. Advantages include on-demand scalability, with the provider responsible for signature updates and 24/7 monitoring. Disadvantages include dependence on an external connection, additional latency along the “you → center → back” route, and the need to define an SLA contractually.

Hybrid model. An on-premises center handles fast, high-volume attacks, while a cloud service is activated when traffic peaks exceed local capacity. In practice, most medium-sized ISPs move toward a hybrid model: local filtering handles routine attacks, while cloud capacity is activated when a defined threshold is reached.

Choosing a model means balancing total cost of ownership, response time, and control over traffic. There is no universal answer, but a useful rule applies: if your peak attack profile exceeds local scrubbing capacity by at least a factor of two, a hybrid or cloud solution is almost always cheaper than expanding your own hardware infrastructure.

How Traffic Cleaning Works: BGP Announcements, GRE Tunnels, and Clean Traffic Return

The standard process works as follows:

1. Once an anomaly is confirmed, the router announces a more specific prefix through BGP toward the scrubbing center. For an attack targeting an individual subscriber, this may be a /32; for an attack targeting a network segment, it may be a /24.

2. Traffic reaches the center through a GRE tunnel or a dedicated connection. The tunnel must be configured and tested in advance—there is no time to set it up during an attack.

3. The cleaning equipment applies filtering rules and sends clean traffic back to your network. The return route must be symmetrical; otherwise, some traffic may bypass the cleaning process.

4. Once the attack ends, the announcement is withdrawn and traffic returns to its direct route. Withdrawal must happen automatically through a timer rather than manually. Otherwise, a forgotten announcement may keep redirecting traffic to the center indefinitely.

For targeted backbone filtering, use BGP FlowSpec. It allows filtering rules based on source address, port, and protocol to be sent directly to upstream routers without redirecting all traffic. This is faster and cheaper than routing the entire traffic flow through a scrubbing center, but it requires FlowSpec support on upstream equipment.

Working with Upstream Providers and Building Link Redundancy

No scrubbing center can replace proper agreements with upstream providers. In practice, this means three things: an agreed communication channel with the upstream NOC, a pre-approved announcement procedure, and a backup route in case the primary upstream link becomes congested.

What should be included in the upstream procedure:

• Who is authorized to announce RTBH (Remotely Triggered Black Hole), and at what threshold. This is usually the on-duty NOC team, with mandatory notification to the upstream provider.

• Maximum blackhole announcement lifetime: no more than 30 minutes without renewal.

• 24/7 upstream NOC contact details and a backup communication channel, such as a phone number rather than a ticketing system alone.

• Link redundancy must be physically independent. Two links from the same upstream provider in the same building are effectively one link. If both upstream connections pass through the same exchange point, an attack on that point can disable the entire protection system.

Attention

The most common mistake when building a scrubbing center is failing to provide a symmetrical return route. If cleaned traffic returns through a different path, some of it may bypass the filter and the attack can continue. Test routing symmetry before an incident, not during one.

DDoS Incident Response Plan for NOC and SOC: Step-by-Step Procedure

A DDoS incident response plan is a document that NOC and SOC teams should execute without debate during an incident. Below is a practical framework that should be adapted to your own network.

1. Detection (within 5 minutes)

Responsible: NOC On-Call Engineer.

Confirm anomalous activity based on monitoring metrics and open an incident.

2. Classification (within 10 minutes)

Responsible: SOC.

Identify the attack type and vector: network, transport, or application layer.

3. Localization (within 10 minutes)

Responsible: NOC.

Identify the affected network prefixes and subscribers.

4. Mitigation (within 15 minutes)

Responsible: NOC + SOC.

Activate traffic filtering rules and, if necessary, announce the route to the traffic scrubbing system (Scrubbing Center).

5. Escalation (within 30 minutes)

Responsible: On-Call Manager.

Notify the upstream provider and management when the incident reaches the defined escalation threshold.

6. Stabilization (ongoing)

Responsible: Support Team.

Monitor false positives from protection systems and subscriber complaints while network operations are being stabilized.

7. Post-Incident Review (within 72 hours)

Responsible: NOC + SOC.

Conduct a post-incident analysis, evaluate the effectiveness of the response, and update protection rules.

Key Takeaway

A procedure only works if it has been tested in an exercise. Run a drill once every quarter: announce a test route, send traffic through the scrubbing center, and measure the actual mitigation time. Without exercises, the table above remains theoretical.

Disaster recovery and business continuity must be planned in advance: who to call at 3 a.m., who is authorized to announce a blackhole, and where backup configurations are stored.

Metrics and Criteria for Choosing DDoS Protection for a Telecom Operator

Choosing DDoS protection for a telecom operator should be based on measurable criteria, not on the length of a feature list in a presentation. Evaluate providers using metrics that can be tested against your own traffic and scenarios that matter specifically to an ISP.

Key Metrics: Capacity, PPS, Response Time, and False Positives

Scrubbing capacity is the amount of traffic, measured in Tbps and millions of packets per second (PPS), that a center can process. An ISP needs to consider not only the advertised peak capacity but also the capacity of each individual connection. If a center accepts traffic through only one 100 Gbps port, a 200 Gbps attack will overwhelm it.

Detection time is the number of seconds between the start of an attack and the alert. A target for operators is no more than 60 seconds for volumetric attacks and no more than 5 minutes for application-layer attacks.

Mitigation time is the time between the alert and the application of filtering rules. The target for automatic activation should be no more than 1–2 minutes.

Testing Scenarios: How to Test Protection Before Signing a Contract

Before signing a contract, request a trial period and run your actual traffic profile through the protection system. Here is what to test:

• Volumetric attack. Generate a UDP flood or amplification traffic using a test environment. Measure how many seconds it takes for mitigation to activate and how much legitimate traffic gets through.

• Application-layer attack. Test DNS query floods or HTTP request floods against a subscriber portal. Check whether the protection system blocks legitimate subscribers.

• Attack targeting an individual subscriber. Check whether the system can filter a specific /32 without affecting the entire network segment.

• Announcement withdrawal. Make sure that after the attack ends, traffic automatically returns to its direct route without packet loss.

• False positive. Generate legitimate traffic that resembles an attack and observe how the filter responds.

If a provider does not allow you to test mitigation time on your own network, you are buying a promise rather than protection.

Total Cost of Ownership and the Economics of ISP Protection

The cost of protection includes more than the subscription fee. Calculate the total cost of ownership:

• Capital expenditure on on-premises traffic-cleaning equipment if you choose a local deployment model.

• Subscription fees for cloud scrubbing, which usually depend on peak capacity and the volume of cleaned traffic.

• The cost of links used to redirect traffic to the scrubbing center. A GRE tunnel also consumes bandwidth.

For an ISP with a small network, cloud scrubbing is almost always cheaper at the beginning than deploying a local center. However, as the subscriber base grows and attacks become more frequent, a local center may pay for itself by eliminating variable service fees. The break-even point depends on the attack profile and provider pricing, so calculate it using your own figures.

Professional Tip

Ask the provider not only for a price list but also for a sample cost calculation based on your network's traffic profile. If the provider cannot show a calculation using your figures, it may lack experience working with ISPs of your scale.

At COSMONOVA, we recommend that clients start with a pilot project on a single network segment: connect protection to the most vulnerable part of the network, measure the metrics for a month, and only then decide whether to scale. Our connectivity and data center facilities are designed to make it possible to run such a pilot without service interruptions. Architecture and SLA questions are handled by our engineering team, not the sales department.

Frequently Asked Questions

How can an internet service provider detect a DDoS attack on its network?

Look for sudden deviations from the baseline: an increase in packets per second, upstream link saturation, spikes in DNS flood requests, and abnormal activity from multiple sources. Network DDoS detection relies on continuous traffic monitoring and thresholds for attack volume and packet traffic density. During the first half of 2026, Cloudflare recorded 935 network attacks exceeding 1 Tbps. Detection thresholds must therefore account for high-bandwidth attacks, not just sudden spikes in request volume.

How can an ISP filter DDoS traffic without blocking legitimate subscribers?

DDoS filtering should be multi-layered: first, remove clearly malicious patterns and sources, then apply rate limiting with allowlists for critical services. Filtering rules should be tested in monitoring mode to measure false positives. Geographic filtering and source blocking are useful only when clear anomalies have been confirmed. Strict rules without network event analysis can disconnect real subscribers and partners.

Why does an internet service provider need its own scrubbing center?

A scrubbing center allows an ISP to clean traffic close to the attack source and prevent upstream congestion from affecting subscriber access. This approach processes traffic near the point where it enters the network. In practice, it means backbone filtering, 24/7 monitoring, and returning clean traffic through tunnels. Without an in-house or partner scrubbing center, a 1 Tbps attack can quickly exhaust upstream capacity.

What should a DDoS incident response plan include, and which metrics matter?

A DDoS incident response plan defines NOC and SOC responsibilities, escalation channels, filtering activation procedures, and upstream provider contacts. It should cover attacks targeting subscribers as well as the provider's own infrastructure, together with procedures for incident reviews. Key metrics include detection time, mitigation time, false-positive rate, and SLA compliance. Regular exercises and filtering-rule tests show whether protection works before a real incident occurs.