Study Guide
Distributed Denial of Service (DDoS)
Locate bandwidth, protocol and application bottlenecks and match layered mitigation to a fictional booking service.
Lesson 4.3 Network & Infrastructure Security
A service does not have to be broken into to be taken away from its users. This lesson works out how a service can be kept too busy to answer, how to find which part of it has run out of capacity, and why the defence has to match that part.
Stage: Think
The telephone shop
Think it through
A small shop takes orders by telephone. It has one phone line, one assistant and one stockroom. Without breaking in or stealing anything, how could someone stop genuine customers being served?
- Hint 1: Think about each of the three parts in turn.
- Hint 2: What happens if the line is always busy?
Show what happens
Keep the line engaged, tie the assistant up with silent callers, or swamp the stockroom with slow orders. Each makes the shop unavailable without breaking anything.
Think it through
Show the answer
Answer: B. Not necessarily; the cause matters.
Not necessarily. A genuine rush, or a fault, can look much the same as an attack, so the cause has to be investigated.
Stage: Explain
The idea
Picture a small shop that takes orders by telephone. It has one phone line, one assistant and one stockroom. Three different things can stop a genuine customer being served.
- The line is engaged. Hundreds of callers ring at once, and the customer cannot get through at all.
- The line is free, but the assistant is stuck. Callers ring, say nothing and stay on the line. The assistant is holding for them and cannot take another call.
- The assistant answers, but the stockroom cannot keep up. Callers ask for things that take ten minutes each to find. Orders are accepted and never finished.
Nothing was stolen and nothing was broken, and the shop is still out of action. That is a denial-of-service (DoS) attack: an attempt to stop a service being available to the people it is for. When the calls come from many places at once, it is a distributed denial-of-service (DDoS) attack. Being distributed is what defines it, not any particular size or method.
The many sources are often ordinary computers and devices that have been taken over without their owners knowing, controlled together as a botnet. Not every flood is an attack, though: a ticket sale or a news story can bring a genuine rush that looks much the same, and so can a fault.
Check your understanding
Show the answer
Answer: C. Availability
Availability: the aim is to stop the service being available to the people it is for.
DDoS mainly threatens availability. In DAD terms the outcome is Denial, which is different from Destruction: the data is still there, and nobody can get to it. The word DDoS alone does not show that anything was read or changed, the other CIA impacts.
Where the shop comparison stops. A shop’s callers are people. A website’s “callers” are programs that can each make thousands of requests a second, so the numbers involved are vastly larger.
Stage: Predict
Worked example: a fictional online booking service
A fictional clinic runs an online booking service. Customers open the website, search for an appointment and book it. Three things about the service have limits, and they match the shop’s line, assistant and stockroom.
Think it through
An online booking service has to carry traffic, accept new connections and look up appointments. Which of these matches the shop’s phone line, which its assistant and which its stockroom?
- Hint 1: Which part does every request pass through first?
Show what happens
The internet connection is the line, the equipment accepting connections is the assistant, and the database answering searches is the stockroom. The table gives each an invented limit.
| Part of the service | Its limit in this example | The shop’s equivalent |
|---|---|---|
| The internet connection | Carries 100 megabits of data a second (100 Mbit/s) | The phone line |
| The equipment that accepts new connections | Can start 200 new connections a second | The assistant |
| The database behind the search | Can run 5 appointment searches a second | The stockroom |
The same service is now attacked in three different ways. These are three possible bottlenecks, not three stages of one attack: in a real incident several can occur together, and the bottleneck can move as conditions change. In each case, look for which limit was reached, what the engineer on duty sees, and what would help.
Stage: Predict
A. Network bandwidth bottleneck
Think it through
Attackers send 400 Mbit/s of junk into the clinic’s 100 Mbit/s connection. Predict what the web server’s graphs show, and whether a more powerful server would help.
- Hint 1: Where is the narrow part?
Show what happens
The server is almost idle, because hardly anything gets through the full connection, so a bigger server would not help. The steps below confirm it.
- The attack. Thousands of devices send the clinic 400 Mbit/s of junk data.
- The limit reached. The connection carries 100 Mbit/s, a quarter of what is arriving. Three-quarters of everything is thrown away before it reaches the clinic, and genuine customers’ requests are thrown away with the junk.
- What the engineer sees. The graph for the internet connection is flat at 100%. The web server is almost idle, because hardly anything is reaching it.
- What does not help. A more powerful server: the server is not the part that is full. Filtering on the clinic’s own firewall does not help either, because the firewall sits after the connection that is already full.
- What helps. Removing the junk upstream, which means nearer the internet than the clinic’s own connection: at the internet provider, or at a specialist service that the traffic is diverted through. Such a service filters out attack traffic and passes on the rest, which is called scrubbing.
Check your understanding
Show the answer
Answer: B. It sits behind the full connection.
It sits after the connection that is already full, so the damage is done before it sees any traffic.
The point: traffic has to be stopped before the narrow part, and only someone further out can do that.
Stage: Predict
B. Connection or protocol exhaustion
Think it through
This time the attackers send only 5 Mbit/s, but 2,000 requests a second to open a connection, and never finish any of them. The connection is nearly empty. What could still run out?
- Hint 1: Which of the three limits is about new connections?
Show what happens
The equipment that accepts new connections: each unfinished one holds a place while it waits, and the places run out.
- The attack. The devices send very little data, only 5 Mbit/s, but it consists of 2,000 requests a second to open a connection, none of which is ever completed.
- The limit reached. The equipment can start 200 new connections a second. Each half-open connection holds a place in its memory while it waits for a reply that never comes. The places run out.
- What the engineer sees. The internet connection is at 5%, nowhere near full. New connections time out, and the count of half-open connections is at its maximum.
- What does not help. More bandwidth: the line was never busy. A control that inspects web requests does not help either, because no request gets far enough to be inspected.
- What helps. Protection that deals with connection attempts themselves: limiting how many one source may open, and techniques that avoid holding a place until the other side has proved it is really there. A firewall or a provider’s service can do this.
Check your understanding
Show the answer
Answer: B. No: the line was never full.
No. The line was at 5%; the limit reached was the equipment that accepts new connections.
The point: the device doing the protecting has limits of its own, and can be the thing that is exhausted.
Stage: Predict
C. Application-layer exhaustion
Think it through
Suppose every attacking request looks exactly like a real customer’s search, but asks for the slowest search the site offers. Which part fills up, and why would counting traffic not reveal it?
- Hint 1: Which part does a search depend on?
Show what happens
The database, which can run only a few searches a second. The traffic is small and every request looks legitimate, so only something that understands the application can pick out the abusive pattern.
- The attack. The devices behave like customers. Each connects properly and asks for the slowest thing the site offers, a search of every appointment for the next year. Together they make 50 searches a second.
- The limit reached. The database can run 5 searches a second. Ten times that many are arriving, so the queue grows without end.
- What the engineer sees. The connection is quiet and connections open normally. The home page loads. Searches hang, and the database is at 100%.
- What does not help. More bandwidth, or more web servers in front of the same single database.
- What helps. Limiting how many searches one visitor may make (rate limiting), rules that recognise and refuse the abusive pattern (a web application firewall), and remembering the answers to common searches so that they are not worked out again each time (caching).
The point: every request here looked legitimate. The defence has to understand the application, not just count traffic.
Caching is often done by a provider’s servers placed close to users, called the edge, which answer on behalf of the clinic’s own server, the origin. It helps with pages that are the same for everyone. A personal search or a booking still has to reach the origin.
OSI and TCP/IP Models explains the layers these three bottlenecks sit in.
The three bottlenecks look different from the outside. For the fictional booking service:
- Nothing loads, and the connection graphs are full. Customers’ requests are not arriving at all. This points to bandwidth.
- The link has spare capacity, but new connections time out. Requests arrive, but connection handling cannot keep up. This points to protocol or connection exhaustion.
- Pages begin to load, but searches hang and the database is busy. Requests are reaching the application, which cannot finish the work. This points to the application or backend.
Real incidents can mix these, and a surge of genuine customers can produce similar symptoms. The observations guide the investigation; they do not prove an attack on their own.
Check your understanding
Show the answer
Answer: C. The database.
The application or its database: requests arrive and connections open, but the expensive work cannot be finished.
Go deeper Reflected and amplified attacks
The Security+ objectives name two ways of making a bandwidth attack larger and harder to trace.
- Reflected. The attacker does not send traffic to the victim directly. They send requests to ordinary servers on the internet with the victim’s address forged as the sender, so the servers send their replies to the victim.
- Amplified. The attacker chooses a kind of request whose reply is many times larger than the request. A small amount of traffic from the attacker becomes a large amount arriving at the victim.
The two are usually combined. Both produce the bandwidth bottleneck in case A, and both are dealt with upstream.
Stage: Predict
Mitigation
Think it through
For each of the three clinic attacks, which kind of control would you reach for first?
- Hint 1: Where must each control act to protect the part that ran out?
Show what happens
Bandwidth: filtering further out, before the full connection. Connections: protection that handles connection attempts. Application: limiting and filtering the expensive searches, and remembering common answers. The comparison that follows sets out the main controls and what each cannot do.
The main mitigations are rate limiting, traffic filtering, load balancing and specialist DDoS protection. Traffic filtering uses the rule-based approach explained in Firewalls, Traffic Filtering and Segmentation. The following comparison expands those ideas with upstream, CDN and WAF distinctions.
Comparison table: scroll horizontally on narrow screens.
| Control | Purpose | Limitation to examine |
|---|---|---|
| Upstream mitigation or scrubbing | Filter or absorb attack traffic before it reaches the organisation’s constrained connection. | Effectiveness depends on provider capability, routing and attack characteristics; local filtering alone may not protect an already saturated upstream link. |
| Content Delivery Network (CDN) | Distribute suitable web traffic and serve appropriate content at the edge, reducing origin demand. | Coverage is service-specific. Unprotected services or a directly reachable origin may remain exposed, and not every dynamic request can be cached. |
| Rate limiting | Restrict requests or connections according to rules appropriate to the service. | Distributed sources can limit the effectiveness of per-address rules; overly strict limits can deny legitimate use. |
| Web Application Firewall (WAF) | Apply application-layer filtering rules to relevant web traffic. | It does not independently solve every network or transport-layer attack, and rules need tuning to the application’s legitimate behaviour. |
| Load balancing and scaling | Distribute permitted traffic across available resources and add suitable capacity. | These do not remove all attack traffic or guarantee capacity at shared dependencies or upstream links. Resource and cost limits remain. |
| Monitoring and incident response | Identify where service is failing, coordinate mitigation and assess legitimate-user access. | Detection alone does not stop an attack; alerts need responsible people, usable procedures and effective action. |
Stage: Predict
Why layers matter
This fictional traffic flow shows complementary responsibilities. It is not a universal topology: some controls may be combined by a provider, deployed elsewhere or absent from a particular architecture. Monitoring spans the path rather than waiting for a final step.
Traffic passes these points in order on its way to the booking service, one at a time. Permitted traffic can still cause harm, so the last point watches the whole path.
Internet and upstream provider
Step 1 of 6: Approach
Traffic approaches the service through provider infrastructure. Identify capacity and the available escalation or mitigation arrangements.
Provider
Step 2 of 6: Upstream mitigation
Suitable upstream protection may filter or absorb attack traffic before it reaches a constrained connection.
CDN or edge service
Step 3 of 6: Serve at the edge
Serve suitable requests away from the origin. Check which services and origin paths the arrangement actually covers.
Network and application controls
Step 4 of 6: Restrict and filter
Apply appropriate connection restrictions, filtering and rate limits, with attention to legitimate users and remaining capacity.
Load balancing and application resources
Step 5 of 6: Share the work
Distribute permitted work across suitable resources; verify that shared backends can handle it too.
Monitoring, across the path
Step 6 of 6: Observe service outcomes
Monitor errors, capacity and completion of legitimate bookings. Coordinate response and adjust mitigation when evidence shows a different bottleneck.
Check your understanding
Show the answer
Answer: B. Limit and cache searches.
Limit and cache the expensive searches, which reduces the work reaching the database.
If upstream traffic has already filled the link, a local application rule alone cannot restore that link’s capacity. If the link is healthy but the database is exhausted, simply buying more bandwidth misses the constrained resource. Layering means matching controls to different failure points, not assuming that a longer product list guarantees availability.
Think it through
An engineer sees one address sending a lot of traffic and blocks it. Why might that not be enough, and what might it break?
- Hint 1: How many sources does a distributed attack have?
Show what happens
The attack comes from many sources, which can change, so most of it continues. And one address can stand for a whole school or office sharing it, so blocking it may lock out genuine customers.
Why blocking one address may not be enough
Blocking one source can leave substantial distributed traffic unaffected. Addresses can change, and an address may represent many legitimate users. A school, business or shared network connection may send many customers’ requests through one public-facing address; a strict per-address limit could unintentionally restrict them together. The NAT/PAT explanation develops the addressing distinction.
Use available traffic and service evidence to select rules, monitor the effect and coordinate with upstream or application providers as appropriate. An apparently successful reduction in traffic is not enough if customers still cannot complete bookings. The objective is usable service for legitimate users, not merely a smaller traffic counter.
Organisations prepare for DDoS before it happens: knowing which services matter most, what their connection and provider protection can absorb, who to call at the provider, and how to tell whether real customers can still use the service. During an attack there is little time to find those answers.
Stage: Apply
Apply it in a new situation
These questions use the lesson in situations it has not shown. For the strongest test of your understanding, come back to them on another day and answer each one at the first attempt.
Apply it
Show the answer
Answer: A. Whether genuine buyers caused it.
Whether genuine demand explains the surge. The timing points that way; the cause still has to be investigated.
Apply it
Show the answer
Answer: B. Its users share one public address.
Its users share one public address through address translation, so the limit counts them all as one source.
Apply it
Show the answer
Answer: B. Nothing: DDoS is about denial.
Nothing either way: a DDoS denies access. Whether anything was read or changed needs separate evidence.
Stage: Check
Check your understanding
These questions come from the approved revision bank. Choose an answer and check it; the explanation and its sources follow.
Show answer
Answer: Investigate suitable upstream filtering or absorption before the constrained link.
The constraint is the incoming path. Filtering only after that link or adding server CPU may not protect it; provider capability and routing determine suitable mitigation.
Revision sources: Distributed Denial of Service (DDoS) (Supplementary Study Guide explanation)
Show answer
Answer: Connection-management resources are exhausted although bandwidth remains available.
Connection or protocol resources can become the bottleneck before application work completes. This differs from raw bandwidth saturation and expensive application processing.
Revision sources: Distributed Denial of Service (DDoS) (Supplementary Study Guide explanation)
Show answer
Answer: Examine application filtering, appropriate rate limits and the expensive backend work.
Mitigation should match application and backend demand. More bandwidth or frontends alone may leave the database constrained; legitimate booking access must be checked.
Revision sources: Distributed Denial of Service (DDoS) (Supplementary Study Guide explanation)
Show answer
Answer: Per-address limits may be less effective against distributed sources.; Overly strict filtering can deny legitimate users.
Distributed sources can weaken per-address limits, and false positives can harm availability. WAFs and load balancing have useful but bounded roles.
Revision sources: Distributed Denial of Service (DDoS) (Supplementary Study Guide explanation)
Study and revision
Practise selected concepts through the topic overview, quiz and flashcards. This revision is learning-only and is reached through the All topics track.
Stage: Consolidate
Revision takeaway
Ask which resource is exhausted, where a control must act to protect it, and how legitimate access will be checked. Risk connects the service’s importance, exposure and consequences to priorities; Defence in Depth explains complementary protection without relying on one measure.
Unlike the credential-led Attack Chain, a DDoS attack does not require the attacker first to steal a customer’s credentials or gain administrative access. Least privilege restricts what identities and processes can do; it is not a substitute for mitigating distributed traffic against a publicly reachable service. Both require context, monitoring and appropriate response.
What to remember
- A DoS attack stops a service being available; a DDoS does it from many sources at once, often a botnet.
- First find which resource is exhausted: bandwidth, connection handling, or the application and its database.
- A bandwidth attack must be stopped upstream, before the full connection; local controls act too late.
- Application-layer attacks look like customers, so the defence has to understand the application.
- Blocking one address is rarely enough, and may block many legitimate users who share it.
Key terms
- Denial of service (DoS: Denial of Service)
An attack that attempts to stop legitimate users from accessing a service, for example by exhausting the resources it depends on.
- DDoS (Distributed Denial of Service)
An attack that uses traffic from many sources to exhaust a service’s bandwidth, connection handling or application resources, so legitimate users cannot use it.
- Botnet
A group of compromised devices that an attacker can control remotely, for example to send attack traffic together.
Common misunderstandings
Its aim is to deny access. Stored information can be untouched while the service is unusable.
The traffic comes from many sources, which can change. One address may also represent many legitimate users behind NAT.
Only if the server is the bottleneck. A saturated link or an overloaded database needs a different response.
Legitimate demand and faults can look similar. The cause has to be investigated.
Lesson sources and acknowledgements
Sources and scope
- Taught in Session 2 (see the Session 2 Learning Log): DDoS as an example of denial, and the mitigation examples: limiting requests, filtering traffic, load balancing and specialist DDoS protection services, used in layers.
- Supplementary explanation: the bottleneck scenarios and defensive traffic walkthrough develop the supplied Session 2B educational reference. The telephone-shop comparison, the clinic’s three invented limits and the stepped cases built on them, the symptoms walkthrough, the upstream, scrubbing, edge, origin, CDN and WAF distinctions, the “Go deeper” note on reflected and amplified attacks, the practical note and the misunderstandings are also supplementary.
- Guided version (published 1 November 2026, awaiting the site owner’s editorial review): the telephone-shop opening questions, every question asked in the lesson with its feedback and hints, the application questions and the closing summary are supplementary explanation written for the Study Guide. The settings are fictional. The questions in the lesson’s steps are not revision-bank items; those in “Check your understanding” are, unchanged.
- No practical work is claimed. These are conceptual, fictional explanations, not an attack procedure or evidence that I performed DDoS testing, mitigation or incident response. The clinic and every figure in its example are invented; nothing was measured.
The security objective of keeping systems, services and information accessible to authorised users when required.
A group of compromised devices that an attacker can control remotely, for example to send attack traffic together.
A distributed set of servers that delivers suitable web content from locations close to users, reducing demand on the origin server.
A measure intended to modify risk, for example by restricting access, detecting misuse or supporting recovery.
An attack that uses traffic from many sources to exhaust a service’s bandwidth, connection handling or application resources, so legitimate users cannot use it.
Preventing authorised users from accessing information or services when required. Denial threatens availability.
An attack that attempts to stop legitimate users from accessing a service, for example by exhausting the resources it depends on.
How far a system, service or piece of information can be seen or reached by others, especially from the internet.
A control that allows or blocks network traffic according to configured rules.
Distributing incoming traffic or requests across several systems so that no single system is overwhelmed.
Translating IP addresses as traffic passes a device, commonly so that devices with private addresses can use a public-facing address.
Step-by-step instructions explaining how a particular task should be carried out.
An agreed set of rules for how data is formatted, transmitted and interpreted so that devices can communicate.
Restricting how many requests or connections a source can make in a given time.
A control that filters requests to a web application using rules about the application-layer content of those requests.
Your progress on this lesson
Saved in this browser only. It is not sent anywhere, does not follow you to another device, and is lost if you clear this site’s data.
This browser is not allowing the site to save progress, so it will be forgotten when you leave the page.