DDoS Protection: A Complete Guide

What a DDoS attack is and why they keep getting bigger

A distributed denial-of-service (DDoS) attack aims to overwhelm a target with more traffic than it can handle. The target might be a web server, a DNS resolver, or a network link. When the target cannot process legitimate requests, service becomes unavailable. That is the core definition. The word "distributed" matters: the attack comes from many sources, often thousands of compromised devices working together. A single source would be a DoS attack, easier to block. A DDoS attack uses a botnet, a collection of infected machines (servers, routers, IoT cameras) controlled by an attacker.

The traffic itself can take many forms. A flood of UDP packets, a pile of oversized HTTP requests, or a storm of DNS queries that look just valid enough to bypass simple filters. The goal is not to break into the system, but to break its capacity to respond. RFC 4732 defines DDoS in the context of Internet denial-of-service considerations, and RFC 6269 covers the effects of IPv6 on amplification attacks.

Attack size has grown from the early 2000s where a few hundred megabits per second could take down a website. By 2016, the Mirai botnet demonstrated that unsecured IoT cameras could generate over 600 Gbps. In 2020, AWS mitigated a CLDAP reflection attack peaking at 2.3 Tbps. The largest publicly recorded attack hit 3.47 Tbps in 2021, also using CLDAP amplification. Why do attacks keep growing? Three reasons.

First, bandwidth is cheap. Residential fiber connections offer symmetric gigabit speeds. Datacenter links run 40 Gbps or 100 Gbps. A botnet of 10,000 home routers each sending 100 Mbps can generate 1 Tbps. Second, amplification is easy. Protocols like DNS (port 53), NTP (port 123), and memcached (port 11211) allow an attacker to send a small query that triggers a large response, often 50x to 500x amplification. The attacker spoofs the source IP to make the reply go to the victim. The attacker uses little bandwidth while the victim drowns. Third, DDoS-for-hire services ("booters" or "stressers") lowered the skill requirement. Anyone with a credit card and a grudge can rent an attack for 20 dollars.

There is no sign of the trend reversing. As more devices connect and more servers run open protocols that can be abused, the pool of available firepower expands. Mitigation must scale with the threat.

Volumetric vs protocol vs application-layer attacks

DDoS attacks fall into three broad categories that target different parts of the network stack. Understanding the distinction matters because each type demands a different mitigation strategy. A single attack can combine all three, which is common in modern campaigns. But breaking them apart helps you pick the right countermeasures.

Volumetric attacks

These are the ones that make headlines. A volumetric attack aims to saturate the pipe. It floods the target link with more traffic than it can forward, choking legitimate packets. The classic example is a UDP flood. Attackers send high volumes of UDP packets to random ports on the target, forcing the server to send ICMP unreachable messages until the link or CPU gives out. Another common vector is ICMP flood (ping flood). Without rate limiting, a single large botnet can push multiple gigabits per second.

Amplification attacks, such as DNS reflection over UDP (port 53) or NTP monlist abuse (port 123), are also volumetric. They turn a small query into a large response, magnifying the attacker's bandwidth. Since they saturate bandwidth, volumetric attacks are measured in bps (bits per second) or pps (packets per second). The counter is usually a large enough pipe plus a scrubbing centre that drops malformed or spoofed traffic before it reaches your origin.

Protocol attacks

Protocol attacks exploit weaknesses in Layer 3 and Layer 4 protocols. They are more targeted than brute floods. A SYN flood is the textbook case. The attacker sends a torrent of TCP SYN packets with spoofed IP addresses to a server. The server allocates memory for each half-open connection, filling the connection table. Once the backlog overflows, no new connections, legitimate or not, can be made. SYN cookies (RFC 4987) mitigate this by encoding state in the SYN-ACK, but only work if applied before the table fills.

Other protocol attacks include Ping of Death (oversized ICMP packets that crash older kernels, fixed since the late 1990s) and fragmented packet floods that force the target to reassemble junk. Because protocol attacks consume state table entries, they are best measured in pps. Mitigation often involves connection tracking, SYN proxy at the edge, and dropping invalid TCP flags at the load balancer.

Application-layer attacks

Application-layer attacks target Layer 7. They look like legitimate traffic, making them harder to filter. HTTP GET or POST floods are the most common. The attacker sends thousands of requests for a single expensive dynamic page (a search endpoint, a checkout flow) using real browsers or headless clients. Since each request is a valid HTTP transaction, simple rate limiting based on IP alone fails: attackers rotate through thousands of residential proxies.

Slowloris (2009) is an older but instructive application-layer attack. It opens many HTTP connections and sends partial headers, keeping each one alive by trickling data. The server runs out of worker threads. Mitigation here requires a reverse proxy with a request timeout, a minimal header size requirement, and a limit on concurrent connections per source IP. WAF rules that block requests lacking a User-Agent or matching known bot fingerprints help against automated scripts. CDNs that terminate TLS on the edge and inspect request patterns are the standard defence.

Reflective amplification: how a small bot army hits terabits

Reflective amplification attacks exploit the connectionless nature of UDP and the asymmetry between small request and large reply in certain UDP-based protocols. An attacker sends a tiny query to an open UDP server, forging the source IP address to be the victim's IP. The server replies to the victim, not the attacker. Because the response is many times larger than the query, the attacker gets a multiplier on their available bandwidth.

This technique lets a modest botnet (a few thousand hosts) generate traffic volumes that once required hundreds of thousands of infected machines. The key metric is the amplification factor: the ratio of response size to request size.

Protocols commonly abused

DNS (RFC 1035). An ANY query (type ALL) sent to an open resolver returns all record types. A 60-byte query can produce a 4000-byte response, a factor of roughly 50x. Attackers use EDNS0 to request even larger payloads.

NTP (Network Time Protocol, RFC 5905). The monlist command (disabled in later versions) returned a list of the last 600 client IPs. A 90-byte query could trigger a 6-kB response, a factor of about 60x. Some NTP servers gave factors of 556x.

SSDP (Simple Service Discovery Protocol, UDP port 1900). Used by UPnP devices. A spoofed search request to a multicast group yields a response from each device, often 30x amplification.

Memcached (optional UDP support, port 11211). Before the 2018 GitHub attack, memcached servers with default settings and no firewall could amplify by a factor of 10,000 to 51,000. A 15-byte get request could generate a 750-kB or larger response if the server held a known value.

How small an army is needed?

Assume a 1-Gbps bot. Using DNS (50x), that bot can spray 50 Gbps toward the victim. With Memcached (50,000x), one bot equals 50 Tbps. In reality, overhead and network limits reduce these numbers, but the principle stands: a handful of compromised machines can saturate a typical data center uplink.

The 2016 Dyn DDoS attack used IoT bots and DNS reflection, reaching 1.2 Tbps. The 2018 GitHub attack used memcached reflection, peaking at 1.35 Tbps from fewer than 10,000 sources.

Closing the reflector door

Mitigation starts at the source: network operators should implement BCP38 (RFC 2827) to filter spoofed packets leaving their networks. End organizations can block inbound UDP fragments and rate-limit common reflection protocols (DNS, NTP, SSDP) at their edge. Anycast-based scrubbing centers absorb and discard amplification traffic by distributing the victim's IP across many PoPs.

Modern DDoS mitigation services maintain updated blocklists of open resolvers and monitor amplification trends. But the fundamental flaw remains: many UDP servers on the internet still respond to spoofed queries, making reflective amplification a persistent, low-cost tactic for attackers.

The economics of DDoS: ransom, extortion, and competition

A DDoS attack is rarely a technical end in itself. It is a tool used to achieve an economic or strategic goal. Understanding the motivations behind attacks helps a defender triage risk and budget responses rationally. The cost to launch an attack has fallen dramatically. Botnet rental services (stressers or booters) offer a 1-hour, 300 Gbps attack for as little as $20 USD, paid in cryptocurrency. At the same time, the cost of downtime for a mid-size e-commerce site can exceed $50,000 per hour. This imbalance is the fundamental economic driver of DDoS as a weapon.

Ransom DDoS (RDoS)

The most direct monetization model is extortion. An attacker sends a threatening email demanding payment (typically 5 to 50 Bitcoin, or several hundred thousand dollars) to avoid an imminent attack. Often, a short low-volume burst is sent to prove capability. The FBI and CISA have issued multiple advisories on RDoS, noting that paying does not guarantee the attack will stop; repeat extortion is common. Attack groups like Fancy Bear, Armada Collective, and the Lazarus Group have used this tactic, though many copycats send empty threats after a real group gains notoriety.

Competitive takedowns

DDoS-for-hire is used to disrupt competitors. Online gaming, gambling, and financial trading are prime targets. A rival might launch an attack during a product launch or a high-traffic sales event. Attribution is difficult, but civil lawsuits have revealed cases where a company hired a booter service to take down a competitor's site. The attack is relatively cheap compared to the competitive advantage gained.

Distraction and cover for other attacks

In advanced persistent threat operations, a DDoS serves as a smoke screen. While the security team is busy restoring web access, the attacker may exfiltrate data, deploy malware, or modify financial records. This technique was observed in the 2016 BancABC attack, where a DDoS hit the frontend while fraudulent SWIFT transfers were processed.

Hacktivism and reputation damage

Not all attacks are directly financial. Groups such as Anonymous or Killnet target organizations to make a political statement. The cost to the victim is reputational damage, lost customer trust, and the cost of PR remediation. For a publicly traded company, a DDoS that disrupts service for hours can trigger a measurable stock price dip.

Defender economics

The defender must weigh the cost of protection against the cost of downtime. For a small business with $200k annual revenue, a $500/month always-on cloud scrubbing service might be economically rational. For a large enterprise with $10M/hour revenue impact, spending $1M/year on dedicated mitigation appliances and a multi-ISP anycast design is justified. This is why DDoS protection pricing varies so widely: you pay for capacity specifically sized to your risk.

Always-on vs on-demand mitigation

The choice between always-on and on-demand DDoS mitigation is one of the first architectural decisions a team makes when buying protection. Each model has a distinct trade-off in uptime, cost, and how it interacts with your normal traffic flow. Get this wrong, and you either overpay for capacity you rarely use or get caught without protection when a surge hits.

Always-on mitigation

In an always-on model, all your traffic passes through a scrubbing center or cloud provider before it reaches your origin. The provider inspects every packet, applies filtering rules, and only forwards clean traffic. This is the model used by services such as Cloudflare Magic Transit or Akamai Prolexic. Because the detection and mitigation are in the live path, there is no delay between an attack starting and filtering being applied. For organizations that cannot tolerate any window of exposure (for example, online payment gateways or real-time trading platforms), always-on is the straightforward choice.

The downside is latency. Even clean traffic takes an extra hop through the scrubbing infrastructure, adding 2 to 15 milliseconds of latency depending on geographic distance. There is also the cost of processing all traffic, not just attack traffic. Providers charge by committed bandwidth or by volume, which can be expensive for high-throughput services.

On-demand mitigation

On-demand mitigation sits out of the normal data path. Traffic flows directly to your origin until the provider detects an attack. At that point, the provider sends a BGP announcement (typically based on RFC 4271) to redirect affected IP prefixes to their scrubbing center. After cleanup, traffic is tunneled back to your network. Major examples include the DDoS protection bundled with many Content Delivery Networks and dedicated BGP-route services like those from Lumen (formerly CenturyLink) or Nexusguard.

The main advantage is that normal traffic avoids the latency and cost of the scrubbing infrastructure. You only pay for mitigation when you are under attack. The risk is the gap between the detection and the BGP switch. It can take 60 to 120 seconds for the route to propagate across the internet. For a slow volumetric attack that ramps up, that delay might be acceptable. For a fast application-layer attack (for example, a high-request-rate flood targeting an API endpoint), 60 seconds can be enough to overwhelm your origin servers.

Hybrid approaches

Some vendors bridge the gap using a hybrid model. They keep a lightweight always-on sensor or a small scrubbing capacity in the path, but route full capacity scrubbing only when an attack crosses a threshold. AWS Shield Advanced works this way: it has always-on flow monitoring and some baseline protection, but for large attacks it invokes a BGP reroute to dedicated scrubbers. Google Cloud Armor with Adaptive Protection does something similar on the application layer, using ML models to detect anomalies and then applying WAF rules only when needed.

Another variation is DNS-based redirection. Instead of BGP, the provider changes DNS records (low TTL, usually 30 seconds) to point traffic to a scrubbing proxy. This works only for web applications and has a longer detection-to-protection window, but it avoids the complexity of BGP administration.

BGP scrubbing: routing attack traffic to a cleaning centre

When an on-demand mitigation service activates, it does not install a firewall in front of you. It redirects your traffic. The mechanism that makes this possible is BGP, Border Gateway Protocol, the routing protocol that holds the internet together. By announcing your IP prefixes from the scrubbing centre's network, the service can pull all incoming traffic toward its own infrastructure before it reaches your origin. This process is called BGP-based traffic diversion, or BGP scrubbing.

The basic workflow has three phases. First, the scrubbing centre announces your IP prefix via BGP, typically using a shorter AS path or a more specific prefix (a /24 instead of a /23) to make its route more attractive. Second, upstream networks update their routing tables and send all traffic for that prefix to the scrubbing centre. Third, the centre's hardware filters out attack traffic and forwards only the clean traffic back to you, usually over a GRE tunnel or IPsec tunnel.

Route hijack or legitimate mitigation

From a routing perspective, BGP diversion looks identical to a prefix hijack. The scrubbing centre announces a route it does not own. The difference is authorisation. The customer authorises the diversion. Many providers use RPKI (Resource Public Key Infrastructure) or IRR records to limit the damage if a scrubbing announcement leaks. RPKI ROAs can be configured to grant the scrubbing centre permission to announce the prefix only during an active attack.

Tunnel backhaul and latency tradeoffs

After scrubbing, clean traffic must reach you. The most common method is a GRE tunnel from the scrubbing centre to your edge router. This tunnel can traverse any network, so the scrubbing centre does not need to be a transit provider for your ISP. The downside is extra latency. Every packet takes an additional round trip to the scrubbing centre and back. For a centre in Dallas and an origin in London, that can add 30-50 ms. Some providers offer a geographically distributed set of scrubbing centres to minimise this. You pick the nearest one, and the tunnel terminates close to your edge.

BGP diversion triggers

On-demand services monitor your traffic. They look at volume, packet rates, or protocol anomalies. When a threshold is crossed, the provider automatically injects the BGP route. This can happen within 30 seconds to a few minutes, depending on the provider and the BGP convergence time. Manual triggers via a dashboard or an API are also common. A well-designed BGP diversion process includes a withdraw step: when the attack stops, the route is withdrawn, and traffic flows to you directly again.

Example BGP announcement from a scrubbing centre:
 * Prefix: 203.0.113.0/24
 * AS Path: 64500 64501
 * Community: 64500:100 (trigger: customer-initiated)
 * Next-hop: 198.51.100.1

One caution: BGP diversion protects against volumetric attacks far better than against application-layer attacks. A 1 Tbps flood can be absorbed by a scrubbing centre with 10 Tbps of capacity. But an HTTP flood that looks like normal traffic, 1000 requests per second from different source IPs, may pass through a scrubbing centre undetected unless the provider inspects application-layer data beyond layer 4. For that reason, BGP scrubbing is frequently paired with a WAF or a reverse proxy that sits downstream.

Rate limiting, WAFs, and bot management

While scrubbing centers and BGP rerouting handle the firehose of volumetric attacks, application-layer DDoS requires surgical tools. Layer 7 attacks target the logic of your application itself. A single well-crafted HTTP request can tie up a database connection or exhaust a PHP process pool. Three complementary tools exist to stop them at the edge: rate limiting, a Web Application Firewall (WAF), and bot management.

Rate limiting

Rate limiting is the simplest defense. It sets a ceiling on how many requests a single client (IP, session, or API key) can send within a window. Nginx and Apache have modules for this: limit_req_zone in nginx, mod_evasive in Apache. A common rule is 100 requests per minute per IP for a login endpoint. Higher limits go to authenticated users via token-based counters in Redis. Rate limiting alone stops slow-and-low attacks and credential stuffing, but it cannot distinguish a real browser from a headless script with rotating proxies.

Web application firewalls

A WAF inspects HTTP request payloads and headers for known attack signatures and anomalous patterns. ModSecurity (with the OWASP Core Rule Set, version 3.3.5 as of mid-2024) is the reference open source option. It blocks SQL injection attempts, cross-site scripting, and path traversal attacks that sometimes accompany DDoS events. Managed WAFs (Cloudflare, AWS WAF, Fastly) also support IP reputation lists and geo-blocking. The key tradeoff: a WAF adds latency per request, and a poorly tuned rule set will false-positive legitimate traffic. Use a staged rollout, logging violations first before switching to block mode.

Bot management

DDoS bots have evolved. They execute JavaScript, handle cookies, and rotate user agents. Bot management systems use client-side challenges (CAPTCHA, JavaScript proof-of-work) and behavioral analysis (mouse movements, scroll speed, request timing) to separate humans from scripts. Google's reCAPTCHA v3 returns a score from 0.0 to 1.0 without user interaction. Akamai Bot Manager and Datadome fingerprint hundreds of browser attributes. For API endpoints, a proof-of-work challenge like Hashcash can stall attackers without affecting legitimate clients. The best approach layers all three: rate limiting for bandwidth abuse, a WAF for payload threats, and bot management for session-level impersonation.

None of these tools work alone. They must feed logs into a centralized alerting system (Splunk, Elasticsearch, or a SIEM). Tune throttle thresholds weekly during the first month of deployment. A common mistake is setting rate limits too aggressively during a quiet day, then forgetting to raise them when a flash crowd arrives.

Picking DDoS protection: capacity, latency, and pricing

Once you understand the mechanics of scrubbing and the difference between always-on and on-demand models, the actual selection process narrows to three variables: how much attack traffic the provider can absorb, how much delay they add to your legitimate traffic, and what that costs per month or per gigabit. These three tradeoffs dominate every vendor comparison, and no single provider excels at all of them simultaneously.

Capacity: the raw throughput ceiling

Every DDoS protection provider publishes a headline number: 10 Tbps, 20 Tbps, some claim 100 Tbps across their fabric. That figure matters most for volumetric attacks. You need a provider whose total anycast network capacity exceeds the largest attack your industry segment has seen in the past 12 months. For a typical SaaS company, a 1 Tbps capacity might be sufficient. For a gaming platform or a cryptocurrency exchange, you should look for 5 Tbps or more. Check independent tests from sources like NETSCOUT or Cloudflare’s own transparency reports. Also ask the provider about per-scrub-center capacity. A vendor with 20 Tbps total might only have 500 Gbps of scrubbing capacity in Frankfurt. If you route traffic through that single site, your ceiling is 500 Gbps, not 20 Tbps.

Latency: the cost of scrubbing

Always-on scrubbing adds at least one network hop through the provider’s proxy or cleaning center. On a good anycast network that hop adds 1-3 ms. On a poorly peered provider it can add 10-15 ms, which breaks real-time applications like VoIP, trading, or multiplayer games. Run a traceroute to your origin IP and then again to the IP the mitigation provider gives you. Compare the RTT. If the delta exceeds 5 ms for a latency-sensitive app, test another provider. On-demand BGP redirect models (often called “DDoS on demand”) add zero latency during peacetime because traffic flows directly to your origin. The tradeoff is a 30-120 second gap between attack detection and rerouting, during which your origin may be overwhelmed. For most web applications that 30 second window is acceptable; for financial APIs it is not.

Pricing models: committed vs consumption

DDoS protection pricing generally falls into three buckets. All-you-can-eat flat fee: you pay a single monthly price (often $200-$5,000 depending on capacity tier) and get unlimited attack mitigation. This is common at Cloudflare and Akamai. It is predictable but you pay for capacity you may never use. Committed + overage: you reserve a base level of scrubbing capacity (say 100 Gbps) and pay extra per Gbps above that during an attack. This is how Arbor (now NETSCOUT) and some ISP-managed services work. It can surprise you with a huge bill after a 24-hour attack. Read the overage terms carefully. Some providers cap overage at 1x or 2x the committed rate. Others charge market spot rates. Per-device or per-VM: some cloud-native tools like AWS Shield Advanced charge per protected resource (Shield Advanced is $3,000 per month per organization plus a consumption charge for data transfer out). A company with 100 load balancers will pay much more than one with 5. Always run a worst-case pricing scenario: take the largest attack you have experienced, multiply by the overage rate, and see if the invoice would bankrupt your team.

Hidden pricing traps

Watch for logging costs (some providers count every packet as a log event and bill per million events), SSL inspection fees (decrypting HTTPS traffic can cost extra on some proxy-based services), and exit fees for moving traffic off the mitigation network. These nickel-and-dime charges can double your monthly bill. Ask for a full price sheet before signing.

Anycast networks as a DDoS absorption layer

Anycast is a network routing technique where the same IP address is announced from multiple geographically distributed locations. When a client sends traffic to that IP, the internet's Border Gateway Protocol (BGP) automatically routes the request to the nearest or least congested location. For DDoS mitigation, anycast turns a single target into a distributed network of absorptive nodes.

Cloudflare, Akamai, and Amazon CloudFront all use anycast to spread incoming attack traffic across dozens or hundreds of data centers. Instead of one server farm absorbing a 2 Tbps flood, each of 200 data centers receives roughly 10 Gbps. That is within the capacity of standard transit links. The attack never concentrates at a single point.

How anycast absorbs volumetric attacks

Volumetric attacks aim to saturate a link. With anycast, the attacker's packets are distributed by BGP to the nearest anycast node to each attacking source. A botnet spread across 50 countries sends packets that land on 50 different nodes. No single node sees the full volume. The network as a whole absorbs the attack as long as total capacity exceeds the attack size.

This works because anycast is stateless from the routing perspective. BGP does not care if traffic is legitimate or malicious. It just forwards packets to the nearest advertisement. The anycast nodes themselves must then distinguish good traffic from bad, typically by passing everything through a scrubbing pipeline before forwarding clean traffic to the origin server over a private backhaul.

Limitations of anycast for DDoS

Anycast is not a silver bullet. It struggles with stateful protocols. A TCP connection that starts at one anycast node and then sees routing changes (due to BGP flapping or node failure) may get moved to a different node mid-session. The new node does not have the TCP state, so the connection drops. This is why many anycast providers terminate TCP at the edge and use tunnels or GRE encapsulation to forward clean traffic to the origin.

Another limitation: anycast does not help against application-layer attacks that target a specific origin server. A slow loris attack or a sophisticated HTTP flood that mimics legitimate user behavior still needs to be filtered at the application layer. Anycast distributes the raw packet volume, but the filtering logic must still be smart enough to drop malicious requests.

Finally, anycast requires that you control the IP address and can announce it from multiple locations. This usually means using a CDN or DDoS protection provider that operates its own anycast network. Running your own anycast setup is possible but expensive. You need multiple data centers, BGP peering with multiple transit providers, and the operational expertise to manage BGP announcements.

Despite these caveats, anycast remains the foundation of most large-scale DDoS mitigation services. It is the reason providers can claim multi-terabit capacity. Without anycast, a single data center would need to build and maintain enough transit capacity to handle the biggest attack on record. With anycast, the capacity is the sum of every node's transit links.

Incident response: what to do when you are under attack

The moment you suspect a DDoS attack, stop diagnosing and start acting. Your primary goal is to preserve service availability for legitimate users while you gather data for mitigation. Do not wait for confirmation from your upstream provider. Attack traffic can saturate your link in under 60 seconds.

First, verify the attack. Check your network interface counters, CPU load, and connection tables. A sudden spike in inbound traffic on a single port (often UDP port 53 or 80) combined with high packet loss is a strong indicator. Use tcpdump or netstat -s to confirm. If you see a flood of SYN packets with spoofed source IPs, you are dealing with a SYN flood. If the traffic is all UDP to random high ports, it is likely a volumetric reflection attack.

Second, engage your mitigation provider. If you have an always-on scrubbing service, it should already be filtering. If you use on-demand protection, call your provider and request BGP diversion. Most major providers (Cloudflare, Akamai, AWS Shield, Arbor) offer a phone hotline or a portal that can activate rerouting within 2-5 minutes. Provide them with your ASN, the target IPs, and the observed attack type and volume.

Short-term tactical steps

While waiting for upstream mitigation, apply local filters at your edge router or firewall. For a SYN flood, enable SYN cookies if your OS supports them. On Linux: sysctl -w net.ipv4.tcp_syncookies=1. For a UDP amplification attack, rate-limit inbound UDP on the targeted port using ACLs. Example Cisco ACL: access-list 100 deny udp any any eq 53 applied inbound on the WAN interface. This will drop legitimate DNS traffic too, but it keeps your link from collapsing.

If the attack targets a specific application (HTTP flood), block the offending source IP ranges or user-agent strings at your reverse proxy or WAF. Nginx can rate-limit with limit_req_zone. HAProxy can drop connections from IPs exceeding a threshold. These are stopgaps, not solutions.

Preserve logs and evidence

Start a packet capture on the affected interface. Use tcpdump -i eth0 -s 0 -w attack.pcap. Save netflow or sflow data. Record the exact time of attack onset, the traffic volume (in Mbps and pps), and any error messages. This data is essential for post-incident analysis, for reporting to your ISP, and for potential legal action if the attack is part of an extortion campaign.

Do not engage with the attacker. If you receive a ransom note, do not pay. Paying does not guarantee the attack will stop, and it marks you as a target for future extortion. Report the incident to your national cybersecurity authority (CISA in the US, NCSC in the UK, CERT in your region).

Post-attack review

After the attack subsides, conduct a formal incident review. Identify the attack vector, the mitigation response time, and any gaps in your protection. Update your runbook with lessons learned. Consider adding a dedicated DDoS response plan that includes pre-negotiated contracts with a scrubbing provider, pre-configured ACL templates, and a communication tree for internal and external stakeholders.