DDoS Attacks: Types, Symptoms, and Mitigation

February 17, 2026 • 8 min read

DDoS is not a new phenomenon, but it has become much easier, cheaper, and more scalable. In the past, a few misconfigured servers or a small botnet were enough to disrupt a service. Today we regularly see attacks that can saturate links in fractions of a second, overwhelm firewalls, or bring applications to their knees with seemingly “normal” requests.

This post is not about fear-mongering. It is about context: what DDoS actually is, which attack classes matter in practice, how you spot them during operations, and which countermeasures are worth your time.

What is (D)DoS?

In a Denial-of-Service (DoS) attack, an attacker tries to make a service unusable not by stealing data, but by overloading it or exhausting its resources. The target is availability: your website no longer loads, your API times out, your VPN gateway stops accepting sessions, or your DNS resolvers cannot keep up.

The “D” in Distributed means the traffic does not come from one source, but from many. That can be a botnet of compromised devices, legitimate infrastructure (reflection/amplification), or a mix of both. For you as an operator, the result looks the same: you are not dealing with one attacker, but with a distributed flood.

Motivation: Why are DDoS attacks launched?

The motives are often boring, but effective:

Extortion: “Pay, or we will take you down again.”
Activism/politics: visibility, messaging, disruption.
Distraction: a DDoS can tie up your team while something else happens in parallel.
Competition/sabotage: at time-critical moments (ticketing, releases, launches), even a short outage hurts.
Cost pressure: not every attack aims for a full outage; sometimes the goal is to increase cloud spend, support load, or operational stress.

The important layers (and why they matter)

DDoS is often described in terms of layers because the layer tells you which signals to look at and which defenses are even possible.

Layer 3 (IP): where it comes from and where it should go.
Layer 4 (TCP/UDP): ports, connections, handshakes, state.
Layer 7 (Application): HTTP(S) requests, APIs, business endpoints.
“Layer 8” (Business logic): not official, but very real: expensive logic in your app that can be abused.

The key takeaway: a defense that works perfectly on Layer 3/4 can still fail against Layer-7 attacks, because the requests can look legitimate and only become expensive once they hit your application.

Attack class 1: Volume and amplification (often UDP)

Volumetric attacks aim to overwhelm bandwidth or packet processing (pps). A classic amplifier is reflection/amplification:

The attacker sends small requests to publicly reachable servers (for example open DNS resolvers).
They spoof the source address and set the victim’s IP as the “source”.
Those servers respond with much larger responses to the victim.

If a 100-byte request triggers a 1,000-byte response, you already have a factor of 10. Depending on protocol and payload, the factor can be much higher. The nasty part: from the victim’s perspective, the traffic comes from “normal” services you would rather not block.

Important point: amplification usually relies on source IP spoofing. That is why ingress filtering (BCP 38) is so important. If providers consistently block forged source addresses at the edge, this attack vector becomes significantly harder.

Attack class 2: Protocol and state exhaustion (TCP/Layer 4)

Not every DDoS is about maximum bandwidth. Often it is more efficient to create state on the target until tables or resources fill up.

A classic example is a SYN flood against TCP:

Normally, TCP establishes a connection via the three-way handshake (SYN -> SYN/ACK -> ACK).
In a SYN flood, the attacker sends huge numbers of SYN packets, but the final ACK never arrives.
The server keeps many half-open connections (state) and retries until timeouts kick in.

This consumes memory, CPU, and can also impact outbound bandwidth. And even if you have plenty of bandwidth: once session tracking is full, “down” is very close.

A related category is low and slow attacks: the attacker opens real connections and keeps them open with minimal traffic until your web server or load balancer hits connection limits. This can be far less visible than a large bandwidth spike.

Attack class 3: Layer 7 and “Layer 8” (HTTP, APIs, expensive endpoints)

Layer-7 attacks are often the most annoying because they are harder to distinguish from legitimate traffic. Examples include:

HTTP floods: lots of requests to dynamic pages, search endpoints, or login flows.
Slowloris/slow headers: connections are kept open by sending headers or bodies very slowly.
“Expensive” business logic: endpoints that trigger database queries, external API calls, PDF generation, cryptography, or even AI/agent workflows.

The trick is not necessarily “more traffic”, but more work per request. A small amount of well-chosen traffic can be more expensive than a big wave of cached static GETs.

How do you detect a DDoS in production?

If you only look at CPU and RAM, you will spot some attacks too late. In practice, baselines plus a few robust metrics help a lot:

Traffic: bps and pps at the edge (router, firewall, load balancer).
Connection metrics: new connections/s, open sessions, SYN backlog, TLS handshakes/s.
HTTP metrics: RPS, latency (p95/p99), 4xx/5xx ratios, timeouts.
Upstream symptoms: packet loss, increased RTT, saturated links, BGP events.
Log and WAF signals: unusual paths, invalid headers, many requests without complete requests, suspicious user agents/patterns.

The most important part is simple: you need a baseline. Without it, everything is “kind of a lot”. With a baseline, you suddenly see that, for example, “small packets” or “incomplete requests” deviate heavily from normal.

Mitigation: What actually works in practice

There are two basic approaches: make (build yourself) or buy (use a service). For most teams, “buy” is more realistic, because DDoS mitigation quickly grows into a problem you cannot run as a side project.

1) Put something in front of the app: CDN/WAF/DDoS provider

For websites and APIs this is often the most effective measure:

Anycast networks distribute traffic across many locations.
WAF rules can filter obvious Layer-7 patterns.
Bot management, rate limits, and challenge/response mechanisms reduce “cheap” attacks.

Important: not every attack is HTTP. If you expose services like VPN, VoIP, game servers, or other UDP-based protocols, you will need different layers of protection depending on your setup.

2) Get rate limiting and timeouts right

Simple, but effective if implemented properly:

ICMP/“ping”: limit it, do not ban it completely (you still need it for troubleshooting).
HTTP: limit by IP/token/route, especially for expensive endpoints.
Slow requests: hard timeouts for incomplete headers/bodies.

Example (Nginx, heavily simplified) for request limits on a route:

limit_req_zone $binary_remote_addr zone=api_per_ip:10m rate=10r/s;

location /api/ {
  limit_req zone=api_per_ip burst=40 nodelay;
}

This is not a silver bullet, but it changes the economics: “cheap” attacks become harder.

3) Architecture: Decouple expensive work

Layer-7 DDoS often does not hit your bandwidth. It hits the parts where a single request is disproportionately expensive. And in normal company setups there are plenty of those: login, search, PDF exports, reports, uploads, anything with complex DB queries, or anything that calls external APIs.

A typical real-world example: a customer portal has an export button (“invoice as PDF”, “generate report”, “download everything as ZIP”). In normal operation, someone clicks it every few minutes. In an attack, someone triggers that endpoint hundreds or thousands of times per minute. Bandwidth is not the problem; CPU (rendering), the database (queries), and worker pools (threads/connections) are. From the outside it just looks like “the site is slow”. Internally you suddenly see timeouts, queueing, and a database that is no longer keeping up.

The good news: you do not have to rebuild everything to improve this. Often a few architectural choices are enough to separate the expensive part from the request path and add a brake:

Caching (including error pages), sensible TTLs, edge caching.
Asynchronous processing (queues) for expensive jobs: instead of “PDF now”, trigger a job and deliver later.
Strict input validation and early aborts: limit query complexity, hard limits per request.
Separate protection for login, search, upload, export, and similar endpoints: dedicated rate limits, dedicated timeouts, and potentially dedicated worker pools.
“Degraded mode” switches (feature flags): temporarily disable individual functions without deployment stress.

4) Upstream options: filtering, scrubbing, emergency plans

If it gets really big, you have to filter traffic before it reaches your connection:

Provider-side filtering / scrubbing center
Temporary block rules (for example: “why is there any UDP hitting my web server at all?”)
Emergency routing (for example: switch traffic to a “protected” IP)

This only works if you have discussed it with your provider in advance. Starting “ad hoc” in the middle of an incident is expensive and slow.

A pragmatic checklist (for teams without DDoS specialists)

Inventory: which services are public? HTTP, DNS, VPN, mail, gaming, VoIP?
Single points of failure: DNS provider, reverse proxy, load balancer, a single region?
Observability: bps/pps, RPS, latencies, errors, connection counts, alerts with baselines.
Harden defaults: timeouts, limits, maximum header sizes, connection limits, backpressure.
Provider plan: who scrubs, who can filter, which escalation paths exist?
Runbook: “if X happens, then Y”, including contacts, thresholds, and switches (feature flags).
Practice: controlled load tests and incident drills (legal and coordinated).

Finally: Test, but keep it legal and useful

Testing DDoS is a sensitive topic. Anything that touches the public internet, third-party systems, or infrastructure you do not have explicit permission for is off limits. What you can and should do:

Load tests in your own staging environment (for example performance tests for expensive endpoints).
Chaos tests for dependencies (cache down, DB slow, tighter rate limits).
Practice your DDoS response process: alerts, comms, provider escalation, emergency measures.

Sources and further reading

Until next time, Joe