DDoS Basics for Enterprise Engineers

By Taylor Thomas · 2026-09-01

A distributed denial-of-service attack targets availability, not access: it makes a service unreachable, most commonly by exhausting something finite — link capacity, connection state, or server resources. That framing organizes the whole defensive playbook: each of those three targets anchors an attack class, and each class is best stopped at a different place in the path. Real campaigns combine vectors, which strengthens rather than weakens the point — the recurring mistake in enterprise designs is expecting one box to handle all three.

Three Ways to Exhaust a Target

Volumetric attacks aim at link capacity: enough traffic to saturate the victim’s ingress connection, so legitimate packets are dropped in the congestion upstream. Many of the largest floods use reflection and amplification — the attacker sends small requests with the victim’s address spoofed as the source to internet-facing services whose responses are many times larger, and the responses converge on the victim. DNS and NTP have both been abused this way. The enabling condition is source-address spoofing, which is why ingress filtering — BCP 38 — is the internet-hygiene fix: a network that verifies its customers’ source addresses cannot originate spoofed-source reflection attacks, though the protection is only as broad as the deployment.

Protocol attacks aim at the machinery of packet and connection handling rather than bandwidth — most classically, at connection state. The signature example is the SYN flood: half-open TCP connections that each consume a table entry until the table is full and legitimate handshakes are refused. The documented countermeasure, SYN cookies, encodes the connection information in the sequence number instead of storing it, so the endpoint commits no per-connection state until the handshake completes — the processing cost remains, but the table does not fill. The uncomfortable truth for network engineers is that every stateful middlebox — firewall, NAT, load balancer — carries a state table and is therefore itself a target of this class.

Application-layer attacks aim at the server’s own capacity for work. Requests often look individually legitimate — a completed handshake, a valid TLS session, a well-formed HTTP request against an expensive endpoint — though the class also includes deliberately slow and incomplete requests that hold connections open. Either way the attack is the aggregate, and packet-level controls, while useful for rate and connection limits, generally lack the application context to make the final discrimination.

Matching Defense to Class

Placement follows from the mechanics. A volumetric flood that exceeds your ingress link is decided before any on-premises device sees a packet — the congestion is upstream, so the defense must be too: provider-side mitigation, a cloud scrubbing service that diverts and filters traffic before forwarding the clean remainder, or an anycast-fronted architecture that can distribute the load across many sites. Destination-based remotely triggered black hole filtering is the blunt upstream tool — the provider discards all traffic matching the route installed for the target, a host route or a whole prefix, which protects your links, and the services outside the black-holed route, by completing the outage for everything that route covers. It is a sacrifice play, and knowing in advance which addresses you would sacrifice is part of the runbook.

State-exhaustion attacks are fought at or ahead of the stateful tier — SYN-flood protections, carefully tuned timeouts, and honest capacity math for each state table in the path. Application-layer attacks are fought where the application context lives: per-client rate limiting, challenge mechanisms, and web application firewall policy — which is exactly why the SCAZT 300-740 blueprint asks how web application firewalls protect against DDoS. Detection is a telemetry problem, with the signal living where the attack does: volumetric floods show up in flow data and interface counters, state attacks in connection-table occupancy and half-open counts on the devices holding the state, and low-rate application-layer attacks may first appear as latency and error rates in application telemetry. In every case a baseline is what makes the signal legible.

The Runbook Beats the Reflex

DDoS response is one of the few security scenarios where much of the decision-making can be done in advance, because the attack classes are known. A usable runbook answers, before the flood: who at the provider or scrubbing service is called and what contractual mitigation exists; which prefixes would be black-holed if it came to that, and who owns that decision; which services front through a CDN or anycast layer and which terminate on links you must defend; and what normal looks like, in flow baselines, so the first minutes are spent classifying the attack rather than discovering the network. Exercising the diversion path matters as much as having it — a scrubbing arrangement first tested during an attack can fail on the mechanics: routing announcements, unplanned return-path asymmetry, allow-lists nobody updated.

Blueprint and Practice

DDoS sits in the threat vocabulary every Cisco security exam assumes: SCOR 350-701 v2 objective 1.1 places DoS and DDoS among the attack threats an engineer explains against on-premises, hybrid, and cloud environments, and the WAF angle appears in SCAZT. The SCOR course covers the attack classes and the placement logic; the SCAZT course picks up the cloud-edge side. For the wider defensive map — segmentation, telemetry, response — start at the course catalog.

Frequently Asked Questions

Can my firewall stop a DDoS attack?

It depends on the class. A firewall can help against smaller state-exhaustion attacks — and, if it is application-aware, some application-layer attacks — but it is itself a stateful device with finite connection tables, which makes it a target of exactly those attacks. A volumetric flood that fills your ingress link is decided before the firewall ever sees a packet — that class must be absorbed upstream, by a provider or cloud scrubbing service.

What is the difference between RTBH and scrubbing?

Remotely triggered black hole filtering tells the upstream network to drop all traffic to the attacked address or prefix, which stops the flood from congesting your links but also completes the outage for whatever the black-holed route covers — it sacrifices the target to save the infrastructure. A scrubbing service instead diverts traffic through a filtering center that separates attack traffic from legitimate traffic and forwards the clean remainder, preserving the service at the cost of added complexity.

Why do application-layer DDoS attacks get past network defenses?

Because requests often look legitimate on their own: a completed TCP handshake, a valid TLS session, a well-formed HTTP request — and the slow-and-incomplete variants hide by doing very little at the packet level. The damage comes from aggregate volume and from targeting expensive operations. Defenses at this layer need application context — per-client rate limiting, challenge mechanisms, and web application firewall policies — rather than packet-level signatures alone.