DDoS protection: how to defend a website, layer by layer

The structure follows the joint guide from CISA, the FBI and MS-ISAC, Understanding and Responding to DDoS Attacks: before an attack, during it, and after it.

• Network capacity and filtering. Volumetric floods fill the link to your site. Only capacity in front of that link helps: your provider's network, a scrubbing service, or an edge network with more bandwidth than the attack. See volumetric attacks.
• Connection handling. Protocol attacks fill the tables that track connections. SYN cookies, connection limits and devices built to hold many connections absorb them; see protocol attacks.
• Request filtering and rate limits. Application-layer attacks send valid requests that are expensive to answer. A web application firewall and rate limiting handle them; see application-layer attacks.

Each layer is blind to the others' problems, which is the point of attack layers: a filter that reads requests cannot help when the link is already full.

An attack cannot be prevented from being launched; what can be prevented is the outage. Preparation is most of it.

1. Know what matters. List the services that must stay up and what each depends on: DNS, the origin servers, third-party APIs.
2. Know who carries your traffic. Have the provider's emergency contact and know what they can filter on request.
3. Put capacity in front of the origin. An edge network or scrubbing service absorbs floods your own link cannot; hide the origin's address so traffic cannot bypass it; for a single machine, see servers and VPS.
4. Filter and limit at layer 7. Rate limits and request filtering, introduced in monitor mode first so they do not refuse customers.
5. Write the runbook. Who decides, who calls whom, which switches exist, and how to reverse each one.

1. Confirm it is an attack. Rule out a deployment, a campaign or a broken integration; check your provider's status.
2. Find which limit is exhausted. A full link, full connection tables, or overloaded servers point to different measures.
3. Call your provider. For floods that fill the link, they are the only ones who can filter upstream of you.
4. Tighten layer 7 deliberately. Rate limits on the targeted paths and stricter filtering, each change noted so it can be undone.
5. Record and review. Keep timelines and logs; after the attack, decide what to change before the next one.

The discipline for emergency changes you can unwind is on incidents.

Review the attack while it is fresh. Note which limit was reached first, how long it took to notice, which calls were made and how long the provider took to act. Those numbers show where the time went.

Then reverse the emergency changes one at a time, and keep the ones that proved useful as deliberate settings. Update the runbook with what was missing, and test the parts you rely on, such as switching filtering on or reaching your provider, before you need them again.

Ask any provider the same questions, without relying on comparison tables that age quickly. The classes of solution are compared on cloud vs on-premise, and the steps once an attack starts on DDoS mitigation.

• Which layers does it cover? Network floods, protocol attacks, application attacks, or only one of them.
• Where does filtering happen? Upstream of your link, at an edge network, or on your own servers.
• How is it switched on? Always on, or diverted when an attack is detected, and how long that takes.
• What do you see? Logs of what was refused, and whether you can watch decisions before they are enforced.