What Is a DDoS Attack, and How Do You Protect a Website?

A DDoS attack is not a break-in. Nothing is stolen; the site is simply buried under requests until nobody can reach it. The defence is to have something bigger in front of it.

What Is a DDoS Attack, and How Do You Protect a Website? — Troiana insight cover

In short

A distributed denial-of-service attack overwhelms a website or its network with requests from thousands of compromised machines so that the server, the connection or the application runs out of capacity and legitimate visitors cannot get through. Attacks range from raw bandwidth floods to application-layer floods of expensive requests. Small sites are hit by extortion attempts, competitors, disgruntled individuals and collateral damage. The practical defence is a CDN or edge provider with DDoS mitigation in front of the site, rate limiting on expensive endpoints, and an origin that only accepts traffic from the CDN.

What it is

A denial-of-service attack makes a site unavailable by exhausting something it needs: bandwidth, connections, CPU, database capacity. The distributed version does it from many sources at once, typically a botnet of compromised computers, routers and cameras, so the traffic cannot be blocked by address and its total volume exceeds what any single server can absorb.

No data is accessed. The harm is unavailability: lost sales, missed bookings, a support inbox full of complaints, and, if the site is a business's only channel, a business that is offline for as long as the attack continues.

The types

Volumetric attacks saturate the network link with sheer bandwidth: floods of UDP packets, amplified through misconfigured servers so a small request produces a large response aimed at the target. Measured in gigabits or terabits per second, these overwhelm anything not behind a network built to absorb them.

Protocol attacks exhaust the server's or firewall's connection-handling capacity with half-open connections and malformed packets. SYN floods are the classic example.

Application-layer attacks send requests that look legitimate but are expensive to serve: search queries, cart operations, login attempts, large page renders, at a rate the application cannot sustain. These are lower in volume and harder to distinguish from real traffic, and they are the kind that takes down a small site on ordinary hosting.

Attacks often combine types, and they are cheap to launch: booter services rent attacks for a few dollars.

TypeWhat it exhaustsWhat helps
VolumetricThe network linkAn edge network with capacity to absorb it
ProtocolConnection-handling capacityEdge protection and firewalls
Application layerExpensive pages and queriesRate limiting and caching
Attacks often combine these, and no data is accessed: the harm is unavailability.

Why small sites get hit

Extortion, where an attack is launched and a ransom demanded to stop it. Competitors, in some markets. A former employee, an angry customer, a person with a grievance and a search engine. Hacktivism against a sector. Collateral damage from an attack on a neighbouring site on shared hosting. And sometimes no discernible reason: a botnet being tested on random targets. The assumption that nobody would bother is contradicted by the logs of any hosting provider.

What mitigation looks like

A CDN or edge network with DDoS protection. Cloudflare, Akamai, Fastly, AWS Shield and similar providers sit in front of the site with network capacity many orders of magnitude larger than any server, absorb volumetric and protocol attacks at their edge, and filter application-layer floods with rate limiting, bot detection and challenge pages. For most sites this is the entire answer, and the basic tier is often free. It is the single most effective step and it is the same step that provides a WAF.

An origin that only talks to the CDN. If attackers can find the server's real address, they bypass the protection. Restrict the origin's firewall to the CDN's address ranges, and do not leak the origin IP through DNS records, email headers or subdomains.

Rate limiting. Caps on requests per address to login, search, forms and any endpoint that is expensive to serve, so that a flood of application requests is refused before it consumes the database.

Caching. A site whose pages are served from the CDN's cache barely notices a flood of page requests, because the origin is not involved. Static sites are close to immune to application-layer attacks for this reason.

Capacity and autoscaling help against modest attacks and are expensive against large ones; scaling to absorb an attack is paying the attacker's bill.

Hosting that includes protection. Many managed platforms and hosts provide baseline mitigation; check what the plan covers before assuming.

During an attack

  1. Confirm it is an attack and not a traffic spike, a broken client or a runaway script: the access logs and the CDN analytics show the pattern.
  2. Enable the highest protection mode at the CDN, which typically challenges every visitor briefly; a few seconds of friction beats being down.
  3. Block the obvious: countries you do not serve, address ranges, user agents, and the specific paths under attack, at the edge.
  4. Rate-limit the targeted endpoints aggressively.
  5. Do not pay an extortion demand; it funds the next attack and rarely ends this one.
  6. Contact the host or CDN if the attack exceeds what your configuration handles; they see attacks daily.
  7. Record everything for any report to authorities or insurers.
  8. Afterwards, review what was hit and harden it, and check the origin was not exposed.

A site that is behind a CDN with protection, with the origin locked down, weathers most attacks without the owner noticing beyond a dashboard alert. A site on shared hosting with its address public goes down at the first attempt.

The relationship to other security

DDoS is availability; most other security concerns are confidentiality and integrity. The controls overlap at the edge, which is why the CDN that mitigates attacks also runs the WAF and the bot filtering, and why monitoring that alerts on traffic anomalies is the early warning for all of them. Putting a site behind an edge provider is the one change that improves every one of these at once. If your site is not behind one, or is behind one with the origin still reachable directly, book a call; the setup is an afternoon.

Common questions

What does DDoS stand for?

Distributed denial of service: an attack that makes a website or service unavailable by flooding it with requests from many machines at once, typically a botnet of compromised devices, so that the server, network or application runs out of capacity and real visitors cannot get through. No data is stolen; the harm is downtime.

How do I know if my website is under a DDoS attack?

A sudden, sustained surge of requests far above normal, from many addresses, often to the same few paths, with the site slowing or returning errors while nothing has changed on your side. Access logs and CDN analytics show the pattern. Rule out a legitimate spike, a broken client repeatedly retrying, or a runaway script before concluding it is an attack.

How do I protect my website from DDoS attacks?

Put it behind a CDN or edge provider with DDoS mitigation, such as Cloudflare, whose network absorbs floods and filters attack traffic before it reaches your server; restrict your origin server's firewall to the CDN's addresses so it cannot be attacked directly; cache pages at the edge; and rate-limit login, search and form endpoints. Static sites are nearly immune to application-layer floods.

Can a small website be targeted by a DDoS attack?

Yes, routinely. Attacks are cheap to rent, and small sites are hit by extortion attempts, competitors, individuals with grievances, collateral damage on shared hosting, and botnets being tested at random. A site on basic hosting with its server address public typically goes down at the first attempt; one behind a CDN with protection usually does not notice.

What is the difference between a DoS and a DDoS attack?

A denial-of-service attack comes from a single source and can often be blocked by address. A distributed denial-of-service attack comes from many sources at once, usually a botnet, so it cannot be blocked by address and its combined volume far exceeds what one server can handle. Nearly all significant attacks today are distributed.

Have something worth building right?