Layer 3, layer 4, and layer 7 attacks
Layer 3 attacks target the network layer (IP, ICMP) — examples are ICMP flood and IP fragmentation attacks. Layer 4 attacks target the transport layer (TCP, UDP) — examples are SYN flood, UDP amplification, and DNS amplification. Layer 7 attacks target the application layer (HTTP, HTTPS) — examples are HTTP GET/POST floods and Slowloris. Each layer requires different mitigation.
Volumetric attacks at layers 3 and 4 try to saturate the network pipe itself. The largest publicly disclosed attacks have crossed the multi-terabit-per-second threshold — Cloudflare reported mitigating a 7.3 Tbps attack in May 2025, and AWS Shield reported a 2.3 Tbps attack as far back as February 2020. These attacks work because amplification protocols (DNS, NTP, memcached, CLDAP) let a small spoofed query trigger a much larger response sent to the victim — amplification factors of 50x for DNS, 200x for NTP, and 50,000x for memcached have been documented. Protocol attacks at layer 4 — SYN floods, ACK floods, fragmented packet attacks — exhaust connection-tracking state on firewalls and load balancers rather than saturating bandwidth. Layer 7 attacks are the smallest by bytes but the hardest to filter: an HTTP flood from a 100,000-node botnet looks bit-for-bit like real users, and only application-aware logic can tell them apart.
BGP blackhole and remote-triggered black hole (RTBH)
BGP blackholing is the brutal-but-effective mitigation of last resort: the network operator advertises a /32 route for the attacked IP into a special 'blackhole' BGP community, telling all upstream peers to drop traffic to that IP entirely. The target stays offline, but the rest of the network stays up. RTBH is standardized in RFC 5635 and supported by every Tier 1 carrier.
RTBH is documented in RFC 5635 (August 2009) and works by tagging a route with a community attribute that upstream peers interpret as 'discard all traffic destined for this prefix.' The mitigation is total — the protected IP becomes unreachable from the entire internet, including from legitimate users — but it protects the rest of the customer fleet from collateral damage. Because of how blunt it is, RTBH is appropriate when a single IP is being saturated by a multi-hundred-gigabit attack and the cost of a broader outage outweighs keeping that one IP online. Many low-tier 'DDoS-protected' VPS plans actually mean exactly this: the provider will null-route your IP under attack to keep the rest of their fleet safe. That is denial-of-service mitigation by definition, but the protected resource is the provider's network, not yours.
Scrubbing centers and traffic diversion
A scrubbing center is a hardened network site where attack traffic is filtered out and clean traffic is forwarded to the origin. Traffic is diverted there via BGP announcement (always-on or on-demand) or DNS pointing. Per-Tbps scrubbing capacity is the headline metric — the largest providers operate 200+ Tbps of aggregate scrubbing, while specialty hosting providers typically advertise 1-10 Tbps.
Scrubbing centers run specialized appliances — Arbor TMS, Radware DefensePro, A10 Thunder, NSFOCUS ADS, or large-scale custom Linux/DPDK pipelines — that inspect every packet, classify benign versus malicious patterns, and forward only the clean fraction to the origin. The diversion is usually done by BGP: the customer's prefix is announced from the scrubbing provider's anycast network during an attack, sucking all traffic toward the nearest scrubbing site. After cleaning, traffic is tunneled (GRE, IPSec, dedicated cross-connect, or direct peering) back to the origin server. Scrubbing latency is typically 1-3 ms in-region, plus whatever extra path the diversion adds. Always-on scrubbing keeps the diversion permanent, eliminating mitigation startup time at the cost of a constant latency tax. On-demand scrubbing only diverts during detected attacks, which is cheaper but introduces a 30-180 second activation window during which the attack lands.
Always-on vs on-demand mitigation
Always-on mitigation routes all traffic through the scrubbing layer 24/7 — zero activation delay, but every packet pays a small latency tax (1-5 ms typical). On-demand mitigation activates only when an attack is detected, eliminating steady-state latency but exposing the origin during the activation window (typically 30-180 seconds). Hybrid setups combine both: always-on for HTTP/HTTPS, on-demand for raw IP traffic.
Choosing between always-on and on-demand is a tradeoff between steady-state latency and attack-window vulnerability. Latency-sensitive services — multiplayer game servers, low-latency trading, voice/video — generally pick on-demand and accept the activation gap because every millisecond of steady-state RTT costs them. Public-facing web services, APIs, and SaaS apps generally pick always-on or a fully proxied CDN-like topology where the origin IP isn't even publicly known, eliminating the attack window entirely. Modern cloud-edge providers (Cloudflare, Fastly, AWS Shield Advanced, Google Cloud Armor) lean always-on by default because their network already terminates traffic at hundreds of edge locations and the 'detour' is essentially zero.
Rate limiting, WAF, and application-layer defense
Rate limiting caps requests per source IP, per session, or per URL, blunting layer-7 floods without affecting legitimate traffic. A Web Application Firewall (WAF) inspects HTTP requests against rules — OWASP Top 10 protections, custom rate rules, geo-blocking, JS challenges, and CAPTCHA. Together they handle the layer-7 attacks that volumetric scrubbing alone cannot.
Volumetric scrubbing stops at the IP-and-port boundary. To stop an HTTP flood that looks like real Chrome traffic, you need rules that operate on URLs, headers, cookies, and behavior. Rate limiting is the simplest and most effective layer-7 control: cap a single IP at, say, 60 requests per minute on /login, drop the rest. A WAF goes further with content-aware rules: block requests with SQL-injection patterns, anomalous user agents, missing referrers, geographic origins outside your service area, or payload sizes far outside the legitimate range. Modern WAFs (AWS WAF, Cloudflare WAF, Fastly Next-Gen WAF, ModSecurity with the OWASP Core Rule Set) also run JavaScript challenges, hCaptcha, and bot-fingerprint heuristics that drop a botnet's hit rate by 99%+ without inconveniencing real browsers.
What hosting providers typically include vs charge extra for
Free or included tiers usually cover layer 3-4 volumetric attacks up to a fixed gigabit-per-second cap (often 10-100 Gbps) using basic rate limiting and BGP blackhole. Paid add-ons typically include always-on scrubbing, WAF, layer-7 mitigation, custom rule authoring, and SLA-backed mitigation guarantees. Read the contract — 'unlimited DDoS protection' often means 'we will null-route you above X Gbps.'
Hosting-provider DDoS marketing varies wildly. Genuinely useful protection includes three things: (1) a clear stated capacity in Gbps or Tbps, (2) layer-3 through layer-7 coverage including HTTP-flood mitigation, and (3) a written SLA with mitigation start-time and traffic-loss commitments. Less useful protection is a single 'DDoS protected' badge with no capacity number, which usually means BGP blackhole only — your IP gets null-routed under attack and you are offline for the duration. When evaluating, ask: what is the stated capacity per IP? Is it always-on or on-demand? Does it cover layer 7? What is the mitigation activation time SLA? What happens after the attack exceeds your tier's cap? The answers reveal whether you're buying real protection or a marketing label.