DDoS and Availability Attacks

Availability Is Security

The A in the CIA triad is availability, and Domain 4 treats an offline service as a genuine security failure, not just an IT inconvenience. A denial-of-service (DoS) attack tries to make a service, network, or application unreachable. A distributed denial-of-service (DDoS) attack uses many sources at once — compromised endpoints, rented cloud instances, open reflectors, or a botnet — to overwhelm the target and to hide the true origin.

Recognizing DDoS Evidence

A DDoS scenario typically shows traffic far above baseline, a large and shifting set of source addresses, a saturated internet circuit, overloaded firewalls or load balancers, high connection counts, web servers returning timeouts, and external users unable to reach a public site while internal systems stay healthy. Depending on the type, logs may show a UDP packet flood, many half-open TCP connections, or repeated requests for one expensive page.

The Three Attack Categories (plus Reflection)

In a reflection attack the attacker spoofs the victim's IP as the source; innocent third-party servers send their replies to the victim. Amplification adds a size multiplier: a tiny query triggers a huge response. DNS, NTP, memcached, and other UDP services have historically been abused this way when left open to the internet.

Mitigation Concepts

The single most-tested DDoS idea: a rule on the victim's own firewall is often useless against a large volumetric flood, because the upstream internet link is already saturated before traffic reaches that firewall. Effective defense moves upstream:

• Internet service provider (ISP) filtering or blackholing the bad traffic.
• A DDoS scrubbing service or cloud provider that absorbs and cleans traffic.
• A content delivery network (CDN) and anycast to spread load across many locations.
• A web application firewall (WAF), rate limiting, caching, and bot controls for application-layer floods.
• Autoscaling to add capacity, and business continuity plans for failover and communication.

Common Traps

Do not treat "the site is slow" as proof of an attack. A failed database, a bad code deploy, an expired TLS certificate, a broken DNS record, or a legitimate traffic surge all produce the same user complaint. The trap answer "add more CPU/RAM to the web server" does nothing when the bottleneck is a saturated link. Distinguish by evidence: inbound traffic 10x baseline from thousands of sources with a saturated edge = plausible DDoS; one endpoint slow right after a release = likely application or database.

Worked Scenario

An enrollment portal goes down during peak registration. Monitoring shows the edge circuit at 100 percent, firewall logs show UDP from thousands of sources, and the app servers are mostly idle because traffic never arrives cleanly. That is a volumetric DDoS. Adding application CPU cannot fix link saturation; the answer is upstream filtering, the DDoS provider, and traffic scrubbing.

Contrast: a portal with normal bandwidth but a slow login function, with many valid-looking login attempts from a smaller set of sources. That reads as credential stuffing or an application-layer issue, answered with rate limiting, MFA, bot detection, account-lockout tuning, and monitoring — not by buying bandwidth. The CC habit is always: what resource is exhausted, where is it exhausted, and what evidence proves it?

DoS Versus DDoS, and Why Distribution Matters

A plain DoS attack comes from a single source, which makes it relatively easy to identify and block: one offending IP address can be filtered at the firewall, and the attack stops. The shift to DDoS changes everything for the defender. With thousands of sources, there is no single address to block; filtering one barely dents the flood, and the sources are often legitimate-but-compromised machines whose owners are unaware. Distribution also multiplies the raw volume far beyond what one attacker's bandwidth could ever produce, and it lets the attacker hide behind innocent intermediaries.

This is exactly why CC stresses upstream mitigation: the problem is the aggregate volume and the breadth of sources, not any one packet.

A Quick Field Guide to Triage

When a scenario presents an outage, work through these questions in order before choosing an answer:

• Is the edge link saturated? If inbound bandwidth is at capacity from many sources, suspect a volumetric flood and look upstream.
• Are connection tables full? Half-open connections piling up on a firewall or server point to a protocol attack such as a SYN flood.
• Is only one expensive function slow? Many requests to a costly search or login page suggest an application-layer attack, answered with rate limiting and caching.
• Did something change recently? A fresh deployment, an expired certificate, or a broken DNS record explains many "outages" that are not attacks at all.
• Who is affected? External users locked out while internal systems are fine fits an internet-facing flood; everyone affected including internal users may point to an internal failure.

This disciplined triage is what separates a correct CC answer from a panicked one. The exam consistently rewards the choice that names the specific exhausted resource and applies the matching control at the correct layer, and it punishes the reflexive "add more hardware" or "block the IP" answers that ignore how a distributed flood actually works.