Why ISPs must police outbound DDoS traffic
before it takes a server down

The source-side problem

Every DDoS attack originates somewhere. Compromised IoT devices, botnet-infected servers, and misconfigured open resolvers all sit on ISP networks. When these devices send attack traffic, it traverses the ISP's own network, consumes the ISP's own upstream bandwidth, and causes harm to targets that may be thousands of miles away.

The vast majority of DDoS mitigation investment happens at the target end. Victims deploy cloud scrubbing services, hardware appliances, and detection platforms to handle the attack traffic when it arrives. This is necessary, but it is also fundamentally reactive. The attack traffic has already traversed the internet, consumed bandwidth at every hop, and saturated links at the target before any mitigation activates.

Source-side filtering flips this dynamic. If the ISP where the attack originates filters the traffic before it leaves the network, the attack never happens. No transit links saturated. No targets overwhelmed. No downstream collateral damage. The problem is solved at the point where it begins.

BCP38: the 25-year-old solution still waiting for adoption

BCP38 (Best Current Practice 38, also known as RFC 2827) was published in 2000. It describes a simple concept: ISPs should filter packets leaving their network that have source IP addresses not belonging to that network. This prevents IP address spoofing, which is the foundation of reflection and amplification DDoS attacks.

How spoofing enables amplification

Amplification attacks work by exploiting protocols that respond with more data than they receive. An attacker sends a small query to a DNS server, NTP server, or memcached instance, but spoofs the source IP address to be the victim's IP. The server sends its large response to the victim, not the attacker. The amplification factor varies by protocol:

• DNS: up to 54x amplification
• NTP: up to 556x amplification
• Memcached: up to 51,000x amplification
• CLDAP: up to 70x amplification
• SSDP: up to 30x amplification

Without IP spoofing, none of these amplification attacks work. The responses would go back to the attacker's actual IP address, which defeats the purpose entirely. BCP38 filtering at the source ISP prevents spoofing, and preventing spoofing eliminates amplification attacks.

Why adoption is still incomplete

Despite being 25 years old and technically straightforward to implement, BCP38 adoption remains incomplete. Various measurement projects (CAIDA Spoofer, Open Resolver Project) estimate that 20-30% of autonomous systems still allow spoofed traffic to exit their networks.

The reasons for non-adoption are a mix of legitimate concerns and institutional inertia:

• Asymmetric routing concerns: Strict uRPF (the most common BCP38 implementation) can drop legitimate packets in networks with asymmetric routing. This is a valid concern but is solved by using feasible-path uRPF or ACL-based filtering instead of strict uRPF.
• Operational overhead: Maintaining prefix filters for customer interfaces requires ongoing updates as customers add or change IP allocations. Automated systems and IRR-based prefix filter generation largely eliminate this burden.
• Tragedy of the commons: The ISP that implements BCP38 bears the cost, but the benefit accrues to others (the potential targets of spoofed attacks). This creates a rational but short-sighted incentive to let others do the work.
• Lack of enforcement: Until recently, there were no consequences for ISPs that failed to implement source-address validation. This is changing as regulators and peering partners begin requiring compliance.

Beyond spoofing: detecting compromised devices

BCP38 prevents spoofed traffic, but not all DDoS attacks use spoofing. Botnets like Mirai, Aisuru, and their variants use compromised devices to send attack traffic with legitimate (non-spoofed) source addresses. Filtering based on source address alone does not stop these attacks.

Detecting compromised devices on your network requires monitoring outbound traffic patterns for anomalies. A residential IoT device that suddenly starts sending 10,000 UDP packets per second to a single destination is almost certainly participating in a DDoS attack. A server that starts generating SYN floods to external targets has been compromised.

Outbound anomaly detection

The same per-node monitoring that detects inbound DDoS attacks can detect outbound attack participation. Flowtriq agents monitor all traffic on a server, both inbound and outbound. A sudden spike in outbound packets to a single destination triggers an alert, identifying potentially compromised devices before they can contribute significantly to an attack.

For ISPs managing customer servers or CPE, this outbound monitoring provides early warning of compromised devices. You can quarantine or remediate the compromised device before it causes damage to external targets, before upstream providers start complaining, and before your network's reputation suffers.

IOC pattern matching

Flowtriq's IOC (Indicator of Compromise) pattern matching identifies known botnet command-and-control communication patterns, attack tool signatures, and malware traffic characteristics. When a device on your network communicates with known botnet C2 infrastructure or generates traffic matching Mirai, LOIC, or other attack tool signatures, the system flags it immediately.

This is proactive defence rather than reactive incident response. Instead of waiting for an abuse complaint from a downstream target, you identify and remediate the compromised device based on its traffic behavior.

The regulatory pressure is building

For years, ISPs could ignore source-side DDoS filtering without consequences. That era is ending. Regulatory frameworks around the world are increasingly requiring ISPs to implement reasonable security measures, and source-address validation is increasingly cited as a baseline expectation.

European NIS2 Directive

The EU's NIS2 Directive, which took effect in 2024, expands cybersecurity obligations to include digital infrastructure providers (ISPs, DNS operators, cloud providers). It requires "appropriate and proportionate technical, operational, and organizational measures to manage the risks posed to the security of network and information systems." For ISPs, BCP38 implementation falls squarely within the scope of "appropriate and proportionate" security measures.

National frameworks

Individual countries are implementing their own requirements. Australia's Telecommunications Sector Security Reforms require providers to "do their best to protect the networks and facilities they own and operate from unauthorized interference." The UK's Telecommunications Security Act sets specific security requirements for network operators. In the United States, the FCC has signaled increasing focus on ISP security practices.

Peering and transit requirements

Beyond government regulation, peering partners and transit providers are increasingly requiring BCP38 compliance as a condition of interconnection. Major Internet Exchange Points are beginning to mandate source-address validation for connected networks. This creates market-driven pressure that may prove more effective than regulatory mandates.

The business case for source-side filtering

Beyond regulatory compliance, there are direct business benefits to policing outbound DDoS traffic from your network.

Reduced transit costs

Outbound attack traffic from compromised devices on your network consumes your upstream bandwidth. If you are billed on 95th percentile, DDoS traffic from compromised devices on your network directly increases your transit bill. On a 10 Gbps transit link billed at $0.50/Mbps, a sustained 1 Gbps botnet on your network adds $500/month to your transit costs. Detecting and stopping that traffic saves real money.

Reputation protection

ISPs with high volumes of outbound attack traffic develop poor reputations. Their IP ranges appear on blocklists. Upstream providers receive abuse complaints. Peering partners become reluctant to exchange traffic. In severe cases, upstream providers may de-peer networks that are persistent sources of attack traffic.

Proactive outbound monitoring and remediation protects your network's reputation. It demonstrates to upstream providers, peering partners, and regulators that you take security seriously and are actively managing your network's contribution to the threat landscape.

Customer protection

Customers whose devices are participating in botnets are themselves victims of compromise. Notifying them and helping them remediate is a customer service action, not just a security action. Customers appreciate being told that their device has been compromised, and the remediation process strengthens the customer relationship.

Reduced abuse handling costs

Every abuse complaint about outbound attack traffic from your network requires staff time to investigate and respond. Proactive detection and remediation reduces the volume of abuse complaints, freeing your abuse desk for other work.

Practical implementation for ISPs

Implementing comprehensive source-side DDoS policing involves three layers:

Layer 1: BCP38/BCP84 source-address validation

Deploy uRPF (Unicast Reverse Path Forwarding) on all customer-facing interfaces. Use feasible-path mode rather than strict mode to handle asymmetric routing scenarios. For customer connections where you know the exact assigned prefixes, use ACL-based filtering for more precise control.

This layer prevents all spoofed traffic from leaving your network, eliminating your network as a source of amplification attacks. It is the highest-impact, lowest-cost action available.

Layer 2: Per-node outbound monitoring

Deploy Flowtriq agents on managed servers and infrastructure. The agents monitor both inbound and outbound traffic, establishing baselines and alerting on anomalies in either direction. Outbound spikes to single destinations, unusual protocol distributions, and sudden increases in packet rate all indicate potential compromise.

For managed hosting customers, this is straightforward: deploy the agent during server provisioning. For residential broadband customers where agent deployment is not practical, flow-based analysis of customer traffic at the aggregation layer provides less granular but still valuable outbound monitoring.

Layer 3: IOC and botnet detection

Flowtriq's IOC pattern matching identifies known botnet signatures, C2 communication patterns, and attack tool traffic. This catches compromised devices that are participating in botnets even when their traffic volume has not yet reached alerting thresholds. Early detection of botnet enrollment allows remediation before the device is commanded to attack.

The network effect of source-side filtering

The impact of source-side filtering scales with adoption. Each ISP that implements BCP38 and outbound monitoring removes their network as a potential attack source. As more ISPs participate, the total volume of DDoS traffic on the internet decreases, transit costs decrease for everyone, and the DDoS-for-hire industry loses attack capacity.

This is a collective action problem with a clear solution. The ISPs that lead the way benefit from lower transit costs, better reputation, and regulatory compliance. As the number of compliant networks grows, the pressure on non-compliant networks increases through peer pressure, transit requirements, and regulatory enforcement.

The question is not whether source-side DDoS policing will become standard practice. The question is whether your network will be among the leaders or among the laggards being forced to comply by external pressure.

Getting started

If your ISP has not yet implemented comprehensive source-side filtering:

1. Enable uRPF on all customer-facing interfaces. Start with feasible-path mode and monitor for legitimate traffic that might be affected. This single action prevents your network from being used in amplification attacks.
2. Deploy Flowtriq agents on your managed infrastructure. Get visibility into both inbound attacks targeting your customers and outbound attack traffic from compromised devices.
3. Set up outbound anomaly alerts. Configure alerts for outbound traffic spikes that indicate compromised devices participating in DDoS attacks.
4. Establish a remediation process for compromised devices. When you detect a device generating attack traffic, have a documented process for quarantining the device, notifying the customer, and helping them remediate.

Back to Blog

Related Articles