Upstream filtering DDoS: stopping attack traffic before it saturates your infrastructure

Definition of the problem

The core problem is that many architectures put the real filtering layer too low in the path. Traffic first reaches a carrier port, crosses a router and may then hit a firewall, load balancer or server. A UDP reflection attack, a high-PPS TCP flood or a mix of tiny packets can saturate the first link long before your local logic sees enough samples to react.

Upstream filtering moves part of the decision higher in the path. The upstream provider can apply volumetric rules, ACLs, BGP FlowSpec, targeted rate-limits or redirection to a scrubbing center. This layer does not replace fine-grained mitigation because it often has less application context. Its job is to shave the attack down before physical or billing saturation turns into an outage.

You also need to separate three ideas: blackholing a prefix, filtering an attack pattern and delivering clean traffic. Blackholing protects the provider network but kills the service. Intelligent upstream filtering reduces the attack while trying to preserve users. Clean delivery then keeps the service reachable.

Why it matters

This matters for hosting providers, operators, game servers and exposed platforms because the cost of a bad first reaction is immediate: lost players, customer tickets, saturated ports, 95th-percentile billing spikes or blackhole communities activated too early. A 40 Gbps attack against a 10 Gbps connected service is not primarily a firewall problem; it is an ingress capacity problem.

Upstream filtering also reduces the risk of huge false positives. If the only available response is “blackhole the /32” or “drop all UDP”, the service remains unavailable even if the attack is technically handled. A good upstream strategy should use the smallest effective action: protocol, ports, packet lengths, flags or obvious reflection sources, with a short lifetime and a clear rollback.

It also affects commercial trust. A B2B buyer does not only want to hear about terabits of capacity. They want to know where the attack is stopped, how long the rule stays active, how legitimate traffic is preserved and how support will explain the action during the incident.

Possible solutions

The first option is BGP blackholing, useful as a last resort when the priority is to save the rest of the network. It is simple, fast and widely supported by transit providers, but it is destructive for the targeted service. It should not be sold as true availability protection.

The second option is static provider-side filtering: ACLs or classic anti-amplification profiles for DNS, NTP, SSDP, memcached and similar vectors. It works well against obvious attacks but is weaker when the attack imitates normal traffic or changes shape quickly.

The third option is controlled BGP FlowSpec. FlowSpec can propagate rules matching several traffic fields, not only a destination. Used well, it relieves the port without dropping the entire prefix. Used badly, it breaks legitimate traffic as quickly as it stops the flood.

The fourth option is upstream scrubbing with clean traffic returned through GRE, IPIP, VXLAN, cross-connect or a router VM. This is often the cleanest model when the customer needs to stay online during the attack and keep more precise logic behind the first layer.

Filtering upstream without breaking customer traffic

At Peeryx, upstream filtering is treated as a relief layer, not as the whole product. The network first absorbs and reduces volumetric floods. Then a more precise mitigation logic handles cases where legitimate traffic and attack traffic look closer to each other.

BGP FlowSpec can be useful to remove an obvious pattern quickly, for example a combination of protocol, source or destination ports, packet length or TCP flags. But it must be short-lived, targeted and monitored. A broad permanent rule is usually a bad operational signal.

The critical point is the handoff. Peeryx can return clean traffic through tunnels, cross-connect or a BGP design depending on the customer control model. The customer should understand the path: where the attack enters, where it is reduced, where clean traffic exits and what logic remains under their control.

Concrete use case

Consider a hosting provider exposing several game servers behind a 10G port. A 70 Gbps UDP reflection flood arrives with highly recognizable packets. If everything reaches the customer port, the service disappears. The correct response is not to block all UDP because the games need UDP to work.

A cleaner strategy applies a short upstream rule on attack characteristics such as reflection source ports, a packet-length range and a precise destination. The volume falls below available capacity. Then the specialized mitigation layer continues separating legitimate flows from suspicious ones.

The customer still sees the service online while the attack continues. Support can explain the rule, duration, expected impact and removal plan. That is the difference between “we absorbed traffic” and “we protected the service without unnecessary collateral damage”.

Frequent mistakes

• Confusing upstream filtering with total blackholing of the service.
• Applying a rule that is too broad on UDP or TCP without understanding legitimate traffic.
• Leaving a FlowSpec rule active after the attack ends.
• Not measuring 95th percentile and real saturation thresholds.
• Not preparing the clean return path before the incident.
• Buying only on advertised capacity without asking how filtering decisions are made.

FAQ