DDoS and Availability Attacks
Key Takeaways
- A denial-of-service attack attempts to make a service unavailable; distributed attacks use many sources.
- DDoS symptoms include traffic floods, resource exhaustion, service timeouts, and many source addresses.
- Volume attacks consume bandwidth, protocol attacks stress network or transport handling, and application attacks exhaust service logic.
- Mitigation often requires upstream filtering, rate limiting, content delivery networks, scrubbing, autoscaling, or emergency provider support.
- Do not assume every outage is DDoS; configuration errors, capacity limits, DNS failures, and expired certificates can look similar to users.
DDoS and Availability Attacks
Availability is part of security. A system that keeps data confidential but cannot serve users during business hours still creates risk. Denial-of-service attacks try to make a service, network, or application unavailable. A distributed denial-of-service attack uses many sources, often compromised systems, cloud instances, open reflectors, or botnets, to overwhelm the target.
Common DDoS Clues
A DDoS scenario often includes many source addresses, sudden traffic spikes, exhausted bandwidth, overloaded firewalls, high connection counts, web servers returning timeouts, or users reporting that a public site is unreachable while internal systems remain healthy. The source may appear geographically broad and may shift quickly. Logs may show repeated requests for the same expensive page, a flood of UDP packets, or excessive half-open connections depending on the attack type.
Do not treat "site is slow" as proof of DDoS. A failed database, bad deployment, expired certificate, broken DNS record, or normal traffic surge can also cause an outage. The exam may test whether you can distinguish evidence. If monitoring shows inbound traffic ten times normal from thousands of external sources and the edge circuit is saturated, DDoS is plausible. If only one application endpoint is slow after a code release, application performance or database behavior may be more likely.
Types of Availability Attacks
| Type | What is exhausted | Scenario clue |
|---|---|---|
| Volumetric flood | Bandwidth or network capacity | Link saturation, huge packet volume |
| Protocol attack | Network or transport state | Firewall, load balancer, or server connection table exhaustion |
| Application-layer attack | Application resources | Many expensive searches, logins, or dynamic page requests |
| Reflection or amplification | Third-party responses sent to victim | Spoofed requests cause larger replies toward target |
In a reflection attack, the attacker sends requests with the victim's address spoofed as the source. Third-party systems reply to the victim, amplifying traffic and hiding the attacker. DNS, NTP, and other UDP-based services have historically been abused this way when misconfigured or exposed.
Mitigation Concepts
DDoS defense is not just a firewall rule on the victim server. If the internet connection is saturated upstream, the local firewall may never get a useful chance to help. Mitigation may require the internet service provider, cloud provider, DDoS scrubbing service, content delivery network, web application firewall, rate limiting, anycast distribution, autoscaling, or temporary filtering. Application-layer attacks may require rate limits, caching, bot controls, queue protection, and blocking abusive sessions. Business continuity planning matters because some events require communication, failover, or prioritizing critical services.
Practical Scenario
An online registration portal is unavailable during enrollment. Network monitoring shows the edge internet link at capacity. Firewall logs show UDP traffic from thousands of sources, and the application servers are mostly idle because traffic is not reaching them reliably. This points to a volumetric DDoS. Adding CPU to the application server will not solve link saturation. The response should involve upstream filtering, DDoS provider support, and traffic scrubbing.
Another portal has normal bandwidth but the login function is slow. Logs show repeated valid-looking login attempts from a smaller number of sources. That may be credential stuffing or an application-layer availability issue. Controls might include rate limiting, MFA, bot detection, account lockout tuning, and monitoring, not simply buying more bandwidth.
Good CC reasoning asks: what resource is exhausted, where is it exhausted, and what evidence supports that conclusion?
A public website is unreachable, and monitoring shows the internet circuit is saturated by traffic from thousands of external sources. What attack is most likely?
Why might a local firewall rule be insufficient during a large volumetric DDoS?
Which observations support a DDoS assessment? Choose two.
Select all that apply