Key takeaways

  • CISA describes a DDoS attack as many machines flooding one target so that legitimate users cannot reach it, and recommends enrolling in a protection service, keeping a disaster recovery plan and watching traffic so you can tell an attack from an outage.
  • If an attack is larger than your internet link, nothing on your own servers can help, because the link is full before the packets arrive. Filtering has to happen upstream or in a service with more capacity than the attacker.
  • XDP runs a small program in the network driver before the kernel allocates a packet buffer, so dropping obvious junk costs very little CPU. It is excellent for protecting your own hosts and edge routers, and it does not add link capacity.
  • BGP FlowSpec (RFC 8955) distributes match-and-act rules, such as 'drop UDP from port 123 with packets of this size to this prefix', to many routers at once. Validation rules limit who can install a rule against whom.
  • RTBH uses the BLACKHOLE community (RFC 7999, 65535:666) to ask a neighbor to discard traffic to a victim address. It ends the attack and the victim's service together, so treat it as a tool to protect everything else.
  • Ingress filtering against spoofed sources (BCP 38, RFC 3704) and SYN-flood defenses (RFC 4987) are still the unglamorous basics, and they matter.

What a flood does

CISA's guidance describes a denial-of-service attack as one that floods a host or network with traffic so that legitimate users cannot reach services such as websites, email or accounts. In a distributed attack, many machines do it at once, often a botnet of hijacked devices, and attackers can rent botnets as a service. CISA lists the familiar forms: floods of illegitimate requests, smurf attacks that abuse ICMP broadcast with a spoofed victim address, and SYN floods that start TCP connections and never finish them. It also notes that an attack on your internet or cloud provider can take you down even when you were not the target, and that attackers sometimes use a flood as a distraction while they attempt something else.

Engineers usually sort floods by what they exhaust. Volumetric attacks fill the internet link, measured in bits per second. Packet-rate attacks overwhelm the forwarding capacity of routers and firewalls, measured in packets per second. Protocol attacks, like SYN floods, exhaust connection state. Application attacks look like legitimate requests and exhaust application servers. A defense plan needs an answer for each, and the answers sit in different places.

Start with the plan, not the box

CISA's advice is practical. Enroll in a protection service that detects abnormal traffic and filters it before it reaches your network. Keep a disaster recovery plan that covers communications, mitigation and recovery. Keep devices secure, because compromised devices, especially internet-facing ones with default passwords, make up the botnets. When symptoms appear (slow performance, a site that is unreachable) first confirm whether it is an attack, a maintenance problem or an ISP outage, then involve your provider, then watch other systems in case the flood is a distraction. Traffic monitoring and analysis through a firewall or intrusion detection system is, in CISA's words, the best way to detect an attack.

Turn that into a one-page runbook before you need it: who declares an incident, who calls the carrier, what telephone numbers and portal accounts exist, which prefixes are the crown jewels, what you will sacrifice first (a marketing site before a payment API), and what the customer message says. The most common failure in a real attack is not technology. It is that nobody knows who is allowed to push the button.

Layer 1: stop spoofing at the edge

Many floods rely on forged source addresses, either to hide the attacker or to reflect traffic off third parties. RFC 3704 (BCP 84) explains ingress filtering: drop packets whose source address a network should not be sending. It describes strict reverse path forwarding, which accepts a packet only if it arrives on the interface the router would use to reach the source; feasible path RPF, which tolerates multihoming; and loose RPF, which merely checks that some route exists and is mainly useful for catching unrouted sources. Its recommendation is to apply ingress filtering between an ISP and a single-homed customer, and to use feasible or strict RPF toward multihomed networks where it works. Do this for your own customers and sites. It stops you from being a source of attacks and it makes attacks easier to trace.

For TCP floods, RFC 4987 lists the standard defenses: filtering, a bigger backlog, shorter timers, a SYN cache, SYN cookies, hybrid schemes and firewalls or proxies that complete the handshake for the server. Modern operating systems already include a SYN cache or cookies, but the defaults and kernel parameters matter, so check them on any internet-facing host.

Layer 2: drop junk early with XDP

XDP, the eXpress Data Path, lets a small verified eBPF program run in a network card driver at the earliest point a packet is seen, before the kernel builds a socket buffer for it. The program returns a verdict: XDP_DROP to discard, XDP_PASS to continue, XDP_TX to send the packet back out of the same interface, XDP_REDIRECT to send it to another interface or to user space, or XDP_ABORTED for errors. Programs attach in native mode, which needs driver support, in a generic fallback mode that runs later in the stack, or, on some cards, in an offloaded mode on the card itself. Native mode is where the performance is.

That position makes XDP good at one job: dropping unwanted packets cheaply. Typical rules drop UDP traffic to ports your server does not use, malformed packets, traffic from a blocklist held in a BPF map, and reflection responses such as DNS or NTP replies when your host did not send a request. Because the map can be updated from user space while the program runs, a controller can add and remove entries in seconds. For packets that need deeper inspection, XDP_REDIRECT can hand frames to an AF_XDP socket, which the kernel documentation describes as optimized for high-performance packet processing, with shared-memory rings and a zero-copy mode when the driver supports it.

The limit is arithmetic. XDP runs on your machine, after the packet has crossed your link. If a flood fills a 10 Gb/s port, dropping it on the server changes nothing for the packets that were dropped by the switch upstream. XDP protects CPU, state and applications; it does not create bandwidth. Its best role is as the last local filter behind upstream protection, and as the first responder against packet-rate attacks that a firewall's connection tracking would not survive.

Layer 3: distribute rules with BGP FlowSpec

When a flood is bigger than one host can handle, the filter has to move toward the sources. RFC 8955 defines BGP Flow Specification, which distributes traffic rules in BGP. A rule has match components: destination prefix, source prefix, IP protocol, port, destination port, source port, ICMP type and code, TCP flags, packet length, DSCP and fragment. All components must match together. The action is carried as an extended community. The simplest is traffic-rate with a rate of zero, which discards matching traffic. Others rate-limit, redirect to a VRF, or mark the traffic for different treatment. IPv4 FlowSpec uses AFI 1, SAFI 133, and a VPN variant uses SAFI 134.

This is far more precise than a blackhole. A memcached or NTP reflection flood, for instance, can be described as UDP traffic from the reflector's service port to your prefix, with a packet length range, and dropped while normal traffic keeps flowing. Because a rule travels in BGP, it can reach many edge routers within seconds, which is why large providers and some enterprises use it to automate mitigation.

It is also dangerous, which is why the RFC includes validation. For a rule received from an external peer to be accepted, it must have a destination prefix, its originator must match the originator of the best unicast route for that destination, and no more-specific unicast routes may come from a different neighbor AS. In plain terms, you can only install a rule about address space that you are the legitimate originator of. The RFC warns that relaxing these checks can let unwanted rules in, and advises strict inbound policy and rate limits on rules from third parties. Hardware also limits how many rules a router can hold, so test your platform's FlowSpec scale.

Layer 4: blackhole as a last resort

Remotely triggered blackholing is the oldest tool. RFC 7999 standardizes a well-known BGP community, BLACKHOLE, with the value 65535:666. A network under attack announces a prefix covering the victim with that community, and a neighbor that has agreed to honor it discards traffic destined for the prefix. The RFC advises using the most specific prefix, normally a /32 for IPv4 or a /128 for IPv6, to limit collateral damage, and notes that prefixes longer than /24 or /48 are often filtered elsewhere. A receiver should only honor the community on prefixes the neighbor is authorized to announce, and should attach NO_EXPORT or a similar community so the route stays local.

The trade-off is blunt. A blackhole makes the attack succeed against that one address, because it takes the target offline, but it protects the link and everything else behind it. Use it when one address is drawing a flood that threatens the whole site, and combine it with moving the service to a different address when possible. Log every blackhole announcement, as the RFC encourages, and make sure no one can add the community by accident.

Layer 5: scrubbing services

Beyond a certain size, the answer is a provider with more capacity than the attacker. A scrubbing service attracts your traffic, typically by announcing your prefixes with BGP or by changing DNS, filters out the attack and forwards clean traffic back to you over a tunnel or a direct connection. Always-on services scrub continuously. On-demand services are switched on when an attack starts, which saves money but adds a few minutes of delay and risks missing the first wave. For web applications, a content delivery network or reverse proxy in front of the origin hides your addresses and absorbs both volumetric and application-layer floods. Your origin must then accept traffic only from the service, or attackers will simply go around it.

Cloud platforms include their own layers. On Amazon Web Services (AWS), AWS Shield Advanced adds expanded DDoS protection and AWS WAF filters web requests. Google Cloud Armor shields Google Cloud resources from DDoS attacks and web exploits. Microsoft Azure DDoS Protection defends at layers 3 and 4 and is paired with a web application firewall for layer 7. Oracle Cloud Infrastructure (OCI) has the OCI Web Application Firewall. They protect what runs inside that cloud, not your office circuit.

A contract with a scrubbing provider should specify the maximum attack size they will absorb, the time to mitigate, how traffic returns to you, who may start mitigation, and whether your upstream carriers will cooperate. Test it. A drill that routes a low-risk prefix through the service is worth more than a datasheet.

How the layers fit together

  • Always on: ingress filtering, hardened TCP settings, XDP rules for unused ports, rate limits for expensive application endpoints.
  • At detection: flow telemetry (NetFlow, sFlow or IPFIX) shows the top sources, protocols and ports within a minute, and alerts start the runbook.
  • First response: a narrow FlowSpec rule or an ACL toward the attack's signature, plus a call to the carrier.
  • Escalation: divert the affected prefix to the scrubbing service.
  • Last resort: blackhole the single victim address, and shift the service to a clean one.
  • After the event: preserve logs, review what the attack taught you, update the runbook and ask whether the same attack would now be survivable.

Our team designs and operates this kind of layered defense, from edge routing and BGP policy to host-level filtering and provider contracts. We start by finding what you cannot afford to lose, and work outward from there. Related reading: DNS Security: DNSSEC, Response Policy Zones and Encrypted DNS; Anycast DNS and Edge Load Balancing: BGP, Health Checks and DDoS Absorption.

Sources

This article is general technical information, not a guarantee of protection against any attack. No design can promise to withstand every flood. Test mitigation steps with your carriers and providers in advance. The statement that XDP native mode needs driver support, and the offload option, come from the Linux kernel and eBPF documentation as summarized when we reviewed it. Last reviewed .

Keep reading

Need help with this?

We find out whether everything you run is safe from attackers, then we fix it.

Cybersecurity