# What is a DDoS attack and how does it work? Types, signs and protection

> A DDoS attack floods a service from many machines at once. How botnets, floods and amplification work, how to spot one, and how DDoS protection stops it.

- URL: https://computese.com/understanding-ddos-attacks-how-they-work/
- Author: Duong Quan Nguyen, CEO, Computese
- Published: 2024-10-20
- Updated: 2026-09-25
- Topics: Security, Hosting

## In short
- A DDoS (distributed denial-of-service) attack makes a website or network unavailable by sending it more traffic or requests than it can handle, from many machines at once, usually a botnet of hijacked devices.
- Attacks come in three families: volumetric floods that fill your internet link, protocol attacks such as SYN floods that exhaust connection tables, and application-layer HTTP floods that look like real visitors.
- Reflection and amplification multiply an attacker's traffic with spoofed requests to public servers: CISA lists amplification factors of 556.9 for NTP and 10,000 to 51,000 for memcached.
- DDoS protection works by absorbing and filtering traffic before it reaches you: anycast networks and scrubbing for floods, SYN cookies for protocol attacks, and CDN, WAF and rate limits for HTTP floods.
- For a small business, the practical defence is a protected CDN or host in front of the site, an origin server that only accepts traffic from it, and a written plan that says who to call.

A DDoS (distributed denial-of-service) attack makes a website, app or network unavailable by sending it more traffic or requests than it can handle, from many machines at once. The machines are usually a botnet: thousands of hijacked computers, routers and cameras that one attacker commands to hit the same target together.

This guide explains how a DDoS attack works step by step, the three types of attack (volumetric, protocol and application layer), how reflection and amplification multiply an attacker's traffic, how to tell an attack from an ordinary traffic spike, and how DDoS protection actually stops it. It ends with a response runbook sized for a small business. For the other protections a site owner controls, see our [website security checklist](https://computese.com/essential-tips-to-secure-your-website/).

## What is a DDoS attack?

[NIST's glossary](https://csrc.nist.gov/glossary/term/denial_of_service), following CNSSI 4009, defines denial of service as preventing authorized access to resources, or delaying time-critical operations. A distributed denial of service is, [in NIST's words](https://csrc.nist.gov/glossary/term/distributed_denial_of_service), "a denial of service technique that uses numerous hosts to perform the attack."

Security teams describe attacks by the property they break. Snooping and eavesdropping break confidentiality: someone reads what they should not (our explainers on [snooping](https://computese.com/understanding-snooping-attacks-how-they-work/) and [eavesdropping](https://computese.com/understanding-eavesdropping-attacks-how-they-work/) cover those). A DDoS attack breaks availability. Nothing has to be stolen or changed for the damage to happen: customers cannot load the shop, staff cannot reach email, and the phone system drops calls.

Every online service has a bottleneck, and the attack is aimed at it:

- **The internet connection.** [MITRE ATT&CK gives the simplest example](https://attack.mitre.org/techniques/T1498/): 10 Gbps of traffic sent to a server whose network has a 1 Gbps link. The link is full before the server sees a single packet.
- **Connection state.** Servers, firewalls and load balancers keep a table of open connections, and tables have limits.
- **Processing.** Each web request costs CPU, memory, worker threads and often a database query. Enough of them, and the application stops answering.

The motives are rarely technical. MITRE lists political purposes, hacktivism, extortion and distraction; the Canadian Centre for Cyber Security [adds business competition and revenge](https://www.cyber.gc.ca/en/guidance/defending-against-distributed-denial-service-ddos-attacks-itsm80110). Skill is not required either: CISA notes that [botnets are rented out to attack-for-hire services](https://www.cisa.gov/news-events/news/understanding-denial-service-attacks) (often called booters or stressers) that let unskilled users launch attacks. In Europe, [ENISA's Threat Landscape 2026](https://www.enisa.europa.eu/sites/default/files/2026-09/ENISA%20Threat%20Landscape%202026_Final.pdf), published in September 2026, found DDoS to be the most common incident type in its 2025 dataset, at 51.3% of recorded incidents, mostly low-impact and tied to geopolitics. Of 4,709 hacktivist claims against EU member states, more than 89% involved DDoS, and the pro-Russia group NoName057(16) was the most active.

### DoS vs DDoS

A DoS attack and a DDoS attack have the same goal. The difference is the number of sources, and that changes how you defend. [The joint CISA, FBI and MS-ISAC guide](https://www.cisa.gov/sites/default/files/2024-03/understanding-and-responding-to-distributed-denial-of-service-attacks_508c.pdf) draws the line this way:

|                      | DoS attack                               | DDoS attack                                                       |
| -------------------- | ---------------------------------------- | ----------------------------------------------------------------- |
| Sources              | One computer or a small number           | Many, usually a botnet of compromised devices                     |
| Traffic volume       | Limited by the attacker's own connection | The sum of every source, far larger                               |
| Blocking             | Block the offending address              | No single address to block; sources are victims or public servers |
| Tracing the attacker | Easier                                   | Harder, especially when source addresses are spoofed              |

A DoS attack can still be effective when it exploits a software flaw rather than volume, which is why patching matters even for availability.

## How does a DDoS attack work?

Most DDoS attacks follow the same five steps:

1. **Recruit or rent the machines.** Malware spreads to devices with default passwords or unpatched flaws and quietly joins them to a botnet. The attacker can also rent capacity from someone else's botnet.
2. **Pick the target and the bottleneck.** The target can be a website, an API, a DNS server, a firewall or a whole IP range. The method is chosen to match the weakest resource in front of it.
3. **Send the command.** Command and control (C2) software tells every bot what to attack, with which method and for how long.
4. **Flood.** Each bot sends a modest amount of traffic, but together they exceed what the target can handle. Spoofed source addresses hide the senders or, as shown below, turn innocent servers into weapons.
5. **Crowd out real users.** Legitimate requests queue behind attack traffic, pages time out or return 503 Service Unavailable, and other services that share the same connection slow down too.

Because the traffic comes from thousands of real devices, the CISA guide notes that DDoS attacks are difficult to trace, and difficult to stop by blocking the attacking IP addresses.

### How the Mirai botnet was built from cameras and routers

Mirai is a well-documented example of step 1. A [USENIX Security 2017 study](https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/antonakakis) by researchers from universities, Google, Cloudflare and Akamai reconstructed how it worked. Mirai scanned the internet for devices answering on Telnet ports 23 and 2323, then tried to log in with username and password pairs picked from a list of 62 factory defaults. Each device it entered (mostly DVRs, IP cameras and routers) became a bot. The botnet peaked at about 600,000 infections at the end of November 2016.

![An orange command server sends dashed signals to hijacked home routers, security cameras and a video recorder, and every device fires arrows at one web server on the right.](https://computese.com/images/blog/understanding-ddos-attacks-how-they-work/botnet.acbbc3be9e-1536.webp)

*A botnet's traffic comes from thousands of real, hijacked devices, so there is no single address to block.*

Starting in September 2016, Mirai attacks temporarily crippled the Krebs on Security website with more than 600 Gbps of traffic, then hit the French host OVH and, on October 21, 2016, the DNS provider Dyn. Its source code was published at the end of September 2016, and variants multiplied. [CISA's advice from that period](https://www.cisa.gov/news-events/alerts/2016/10/14/heightened-ddos-threat-posed-mirai-and-other-botnets) still applies to any device you own: Mirai lived only in memory, so a reboot removed it, but a device that kept its default password could be reinfected quickly once it came back online.

The pattern has scaled up, not gone away. [Cloudflare's report for the fourth quarter of 2025](https://blog.cloudflare.com/ddos-threat-report-2025-q4/) describes the Aisuru-Kimwolf botnet, made mainly of infected Android TVs, with an estimated 1 to 4 million hosts. The same report records a 31.4 Tbps attack that lasted 35 seconds, which Cloudflare called the largest ever disclosed publicly by any company at the time.

## The three types of DDoS attacks

The CISA, FBI and MS-ISAC guide and the Canadian Centre for Cyber Security both sort DDoS attacks into three types, by the part of the network they exhaust:

| Type              | What it exhausts                                                               | Common examples                                               | Usually measured in          |
| ----------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------- | ---------------------------- |
| Volumetric        | The bandwidth of your connection, or your provider's                           | UDP floods, ICMP floods, DNS, NTP and memcached amplification | Bits per second (Gbps, Tbps) |
| Protocol          | Connection state in servers, firewalls and load balancers (OSI layers 3 and 4) | SYN floods                                                    | Packets per second           |
| Application layer | CPU, memory and database behind a website or API (OSI layer 7)                 | HTTP floods, Slowloris, HTTP/2 Rapid Reset                    | Requests per second          |

The types are not exclusive. CISA notes that attackers combine them, and the Canadian guidance gives the example of a DNS amplification attack launched together with an HTTP flood, so that defenders have to fight on two layers at once.

### Volumetric attacks fill the pipe

A volumetric attack simply sends more data than the link can carry. The Canadian Centre for Cyber Security [calls it the most common type](https://www.cyber.gc.ca/en/guidance/defending-against-distributed-denial-service-ddos-attacks-itsm80110). In a UDP flood, packets arrive for ports where no application is listening, and the server spends effort answering each one with a "destination unreachable" message while the flood fills the connection. Once the link is saturated, nothing on your side of it can help: your firewall, server and application never receive the packets they would need to filter. Volumetric attacks have to be stopped upstream, in a network with more capacity than the attack.

### Protocol attacks: how a SYN flood works

Every TCP connection starts with a three-way handshake: the client sends SYN, the server answers SYN-ACK and keeps a small record of the half-open connection, and the client completes it with ACK. [RFC 4987](https://www.rfc-editor.org/rfc/rfc4987.html) explains the attack: send a barrage of SYN packets from spoofed addresses that will never reply, so the server's backlog of half-open connections stays full and legitimate connection requests are refused. The attack was first publicized in 1996, and it still works against any device that keeps connection state, including firewalls and load balancers.

The standard defence is the **SYN cookie**. Instead of storing anything for a half-open connection, the server encodes the state it needs into the sequence number of its SYN-ACK, and rebuilds it only if a real ACK comes back. Spoofed SYNs then cost almost nothing. On Linux, `net.ipv4.tcp_syncookies` defaults to 1, which sends cookies only when a socket's SYN backlog overflows. [The kernel documentation](https://docs.kernel.org/networking/ip-sysctl.html) treats cookies as a fallback, because they do not support some TCP extensions. In front of the servers, RFC 4987 describes the other answer: firewalls and proxies that complete each handshake themselves and pass only finished connections to the servers behind them, which moves the problem to a device built to absorb it.

```bash
# 1 = send SYN cookies only when a listening socket's SYN queue overflows (the default)
sysctl net.ipv4.tcp_syncookies

# Count half-open connections during a suspected SYN flood
ss -Htan state syn-recv | wc -l
```

### Application-layer attacks: HTTP floods

An HTTP flood sends valid web requests: the Canadian guidance compares it to thousands of computers refreshing a page at the same time. Each request is small, but it can trigger a database search, a login check or a page that cannot be cached, so a modest number per second can exhaust a server. Slowloris is the opposite trick: it opens many requests and sends their headers very slowly, so the server holds connections open until it can accept no new ones.

These attacks are hard to spot because every request looks legitimate at the network level. Protocol features can be abused too. In August 2023 Google mitigated an attack that [peaked above 398 million requests per second](https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps), using a new technique called HTTP/2 Rapid Reset that abused the protocol's stream multiplexing. The weakness is tracked as CVE-2023-44487, and Google's advice was to apply vendor patches on every server and proxy that speaks HTTP/2.

## Reflection and amplification: how attackers multiply their traffic

Some internet protocols answer a small question with a large reply, and UDP, being connectionless, does not check who asked. [CISA's alert on UDP-based amplification](https://www.cisa.gov/news-events/alerts/2014/01/17/udp-based-amplification-attacks) describes the result. The attacker sends requests to public servers with the source address forged to be the victim's. The servers (the reflectors) send their replies to the victim, and because each reply is larger than the request, the attacker's bandwidth is multiplied.

![A laptop sends thin arrows with small packets to three public servers, which send thick arrows full of large packets to one orange server that never asked for them.](https://computese.com/images/blog/understanding-ddos-attacks-how-they-work/amplify.1d209d6738-1536.webp)

*The reflectors do the heavy lifting: a small spoofed request becomes a much larger reply aimed at the victim.*

CISA measures the multiplier as the bandwidth amplification factor (BAF): the UDP payload bytes a reflector sends back for each byte of request. Some of the factors in its list:

| Protocol  | Bandwidth amplification factor | What is abused                                                                                                                              |
| --------- | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------- |
| DNS       | 28 to 54                       | [Open recursive resolvers](https://www.cisa.gov/news-events/alerts/2013/03/29/dns-amplification-attacks), typically answering `ANY` queries |
| SSDP      | 30.8                           | SEARCH requests to devices with Universal Plug and Play                                                                                     |
| CLDAP     | 56 to 70                       | Directory servers answering on UDP                                                                                                          |
| NTP       | 556.9                          | The `monlist` command (CVE-2013-5211)                                                                                                       |
| Memcached | 10,000 to 51,000               | Caches exposed to the internet on port 11211                                                                                                |

The NTP case shows how a debugging feature becomes a weapon: `monlist` returns [the last 600 addresses](https://www.cisa.gov/news-events/alerts/2014/01/13/ntp-amplification-attacks-using-cve-2013-5211) that talked to the server, so a tiny spoofed request produces a large reply. CISA's fix was to upgrade to ntpd 4.2.7 or add `noquery` to the `restrict default` lines. Reflection itself is not new: CISA's older guidance describes the Smurf attack, which sends ICMP broadcast packets carrying the victim's address so that every host on a network replies to the victim.

Two consequences matter for defenders. First, the joint CISA guide warns that reflection attacks typically originate from legitimate public servers, so the sources look respectable. Second, they remain common: [Cloudflare's report for the first half of 2026](https://blog.cloudflare.com/ddos-threat-report-2026-h1/) found that DNS-based attacks made up 34.3% of network-layer DDoS attacks, and that CLDAP floods rose to the third most common vector in the second quarter.

You can also make sure your own servers are not the reflectors. Restrict DNS recursion to your own clients, and use response rate limiting (RRL) on authoritative name servers, as CISA recommends. Disable or restrict `monlist` on NTP servers, and never expose memcached, SNMP or other UDP services to the internet unless they need to be public.

## How to tell a DDoS attack from a traffic spike

From the outside, a DDoS attack and a genuine rush of visitors look the same: slow pages, timeouts, 503 errors. [CISA lists unusually slow performance](https://www.cisa.gov/news-events/news/understanding-denial-service-attacks) and an unavailable website as the typical symptoms, and notes they can resemble ordinary technical problems or maintenance. The UK's National Cyber Security Centre (NCSC) [advises gathering data before acting](https://www.ncsc.gov.uk/collection/denial-service-dos-guidance-collection/a-minimal-denial-of-service-response-plan) (traffic volumes, bandwidth and CPU use, database transactions) and also checking help-desk tickets and social media, which may explain a surge. Its guidance lists innocent causes for each symptom: an item on your site attracting attention, a network misconfiguration, or an internal tool with a bug that floods the database.

| Signal                   | Real traffic spike                                | Likely DDoS attack                                                              |
| ------------------------ | ------------------------------------------------- | ------------------------------------------------------------------------------- |
| Cause you can point to   | A campaign, a newsletter, press or a social post  | Nothing on your side explains it                                                |
| What clients request     | A normal mix of pages, images, scripts and styles | The same URL again and again, or only expensive ones such as search             |
| Where requests come from | Your usual countries, networks and browsers       | A surge from one location or address range, or identical user agents            |
| Traffic type             | Web traffic on ports 80 and 443                   | UDP to random ports, or replies from ports 53, 123 or 11211 you never asked for |
| Shape over time          | Rises with the event and fades gradually          | Starts at full rate, stops abruptly, returns in waves                           |

The traffic-type row follows from the mechanisms above: [CISA's DNS alert](https://www.cisa.gov/news-events/alerts/2013/03/29/dns-amplification-attacks) names the main indicator of a DNS amplification attack, responses arriving without a matching request. The Canadian guidance lists a sudden surge from a specific location or IP address, and staff complaining of slow connectivity when the office shares a link with the website. The NCSC adds that attackers may come back in waves.

The comparison only works if you know what normal looks like. CISA and the Canadian Centre for Cyber Security both recommend a traffic baseline, and the Canadian guidance adds that it should cover high-traffic days as well as average ones. On a web server, two commands give a first answer during an incident (in nginx's or Apache's combined log format; behind a CDN, log the real client address first):

```bash
# Which client addresses sent the most requests
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Which paths are being hit hardest
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
```

## How does DDoS protection work?

[The NCSC's starting point](https://www.ncsc.gov.uk/collection/denial-service-dos-guidance-collection/preparing-denial-service-dos-attacks1/upstream-defences) is that a determined attacker can almost always generate more traffic than an organization can absorb on its own. DDoS protection therefore works by stopping attack traffic somewhere with more capacity than the attack, before it reaches your bottleneck. Every approach below is a version of detect, divert, filter and pass on the clean traffic.

### Anycast and scrubbing absorb volumetric floods

Large protection networks announce the same IP addresses from many locations at once, which is called anycast. [RFC 4786 (BCP 126)](https://www.rfc-editor.org/rfc/rfc4786.html) describes why this helps: each site acts as a sink for attack traffic from its own region, and the work of sorting attack traffic from legitimate traffic is spread across every site. A botnet spread across the world ends up split across the whole network rather than landing on one link.

![Attack traffic from many directions reaches three separate edge sites that each drop most of it, and one orange line carries only clean traffic on to a single server.](https://computese.com/images/blog/understanding-ddos-attacks-how-they-work/scrub.acbfc06bf3-1536.webp)

*Anycast splits the flood across many sites, and each site filters its share, so only clean traffic travels on to your server.*

Each site then scrubs its share: the Canadian guidance describes scrubbing as filtering incoming traffic to discard malicious data and let only legitimate traffic reach the target. For a website, traffic reaches the scrubbing network because your DNS points visitors at it. For a whole network, the provider announces your IP prefixes with BGP and returns the clean traffic over tunnels or private links. [Cloudflare's Magic Transit](https://developers.cloudflare.com/magic-transit/about/), for example, announces the customer's address space and delivers filtered traffic over GRE tunnels or a direct interconnect.

Speed decides whether protection helps. In the first half of 2026, 90.60% of the network-layer attacks Cloudflare mitigated [ended in under 10 minutes](https://blog.cloudflare.com/ddos-threat-report-2026-h1/). A service that someone has to switch on after an alert usually arrives after the attack is over, so for a public website, choose protection that is always on.

### CDN, WAF and rate limiting filter HTTP floods

Application-layer floods cannot be filtered by volume alone, because every request is valid. The tools here sit in front of the web server as a [reverse proxy](https://computese.com/reverse-proxy/):

- **A content delivery network (CDN)** answers cacheable requests from its own edge, so requests for cached pages never reach your server. The NCSC notes that [CDNs are very difficult to take down](https://www.ncsc.gov.uk/collection/denial-service-dos-guidance-collection/preparing-denial-service-dos-attacks1/upstream-defences) and often let you rate limit particular URLs, such as search.
- **A web application firewall (WAF)** allows or blocks requests by their attributes: path, method, headers, country, reputation or bot signals.
- **Rate limiting** caps how many requests one client may make in a period, and **challenges** such as a CAPTCHA separate people from scripts during an attack, as the CISA guide and the NCSC both suggest.

The same idea works on your own server. This nginx configuration allows each client address 10 search requests per second with a small burst, and answers the rest with 429 Too Many Requests instead of [nginx's default 503](https://nginx.org/en/docs/http/ngx_http_limit_req_module.html):

```nginx
http {
    # 10 MB zone: about 80,000 client addresses on a 64-bit server (8,000 per MB)
    limit_req_zone $binary_remote_addr zone=search:10m rate=10r/s;

    server {
        location /search/ {
            limit_req zone=search burst=20 nodelay;
            limit_req_status 429;
        }
    }
}
```

A server-side rate limit protects the application from overload; it does nothing for a flood that fills the link, which is why it sits behind the CDN, not instead of it.

> [!WARNING]
> Protection at the edge is only as good as your origin's hiding place. If attackers can find your server's own IP address, they can send traffic straight to it and skip the CDN. The NCSC advises cloaking the origin and allowing only the CDN's addresses to connect to it.

### Your upstream provider: filtering, blackholing and Flowspec

Your internet or hosting provider sits upstream of your bottleneck, which makes it the first place a volumetric attack can be filtered. The CISA guide suggests giving your ISP the attacking addresses and asking for port and packet-size filtering. [NIST SP 800-189](https://csrc.nist.gov/pubs/sp/800/189/final) describes the heavier tools providers use:

- **Remotely triggered blackholing (RTBH)** tells the provider's edge routers to drop all traffic to the attacked address. It protects everything else on the link, but the Canadian Centre for Cyber Security calls it a last resort: it completes the attacker's goal for that address.
- **BGP Flowspec** pushes finer filtering rules upstream, such as dropping UDP from a given source port to a given destination, so legitimate traffic to the same address keeps flowing.

Many platforms include basic network protection. AWS, for example, applies [Shield Standard to all customers](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-standard-summary.html) at no additional charge against common network and transport layer attacks; HTTP floods are outside that scope and need rules of your own. The Canadian guidance advises reading your provider's service agreement for the limits of what it covers.

### BCP 38: stopping spoofed traffic at the source

Reflection attacks and spoofed SYN floods depend on forged source addresses. BCP 38 ([RFC 2827](https://www.rfc-editor.org/rfc/rfc2827.html), published in May 2000) asks providers to drop packets arriving from a customer network whose source address does not belong to that network. NIST SP 800-189 recommends the same through source address validation with access lists and unicast reverse path forwarding (uRPF). Ingress filtering does not protect the network that applies it; it protects everyone else. That reflection attacks are still common in 2026 shows that spoofed packets still leave enough networks to matter.

## A DDoS response runbook for a small business

Most small businesses will never face a record-breaking attack. The realistic threats are smaller: a short flood, a ransom demand, or someone with a grudge and a rented botnet. The runbook below, drawn from the CISA, Canadian and NCSC guidance, fits on one page.

### Before an attack

1. **Put a protected edge in front of every public service.** Use a CDN or a host with DDoS protection for the website, and a DNS provider that can absorb floods. Read what the plan includes and what it excludes.
2. **Hide and lock the origin.** Allow connections to the web server only from your CDN's published address ranges, and check that no DNS record, old subdomain or outgoing email reveals the server's own IP address.
3. **Write down the contacts.** Keep your hosting provider's, ISP's and CDN's emergency contacts, account numbers and how to open an urgent ticket where you can reach them when your own systems are down.
4. **Know your normal.** Record a baseline of traffic, and set up monitoring that checks the site from outside your network.
5. **Decide the emergency switches in advance.** Know which expensive features you can turn off (the NCSC's example is a site's search), how to enable challenge mode or stricter rate limits, and where to post a status update.
6. **Rehearse once.** Walk through the plan with the people named in it, so nobody reads it for the first time during an outage.

### During an attack

1. **Confirm it is an attack.** Check the signals in the table above, and rule out a campaign, a deployment or a bug.
2. **Call your provider.** Share timestamps, the attacked addresses and the attacking sources, and ask what mitigation it can switch on.
3. **Tighten the edge.** Enable challenges, lower rate limits, and, if your customers are local, restrict traffic by geography for the duration.
4. **Shed load.** Turn off the expensive features you listed, and serve a cached or static version of key pages.
5. **Collect evidence.** Keep logs, alerts, timestamps, source addresses and packet captures, as the CISA guide advises.
6. **Communicate.** Tell staff and customers what is happening and where updates will appear; the NCSC notes this also reduces the load on your support channels.
7. **Watch the rest of your systems.** CISA and the NCSC both warn that a DDoS attack can be a diversion for a second attack, so keep reviewing other security alerts.

### After an attack

1. **Review what happened:** which assets were targeted, which method was used and how long it lasted.
2. **Check your provider's response** against its service level agreement.
3. **Report it,** especially if it came with a ransom demand: to CISA or an FBI field office in the United States, to [the Canadian Centre for Cyber Security](https://www.cyber.gc.ca/en/incident-management) in Canada, and to the police.
4. **Update the plan** with what was missing: a contact, a switch, a gap in monitoring.

> [!TIP]
> Set the protection up before you need it. Most attacks end within minutes, and signing up for a service in the middle of one rarely helps.

If you want this handled, our [hosting and maintenance service](https://computese.com/services/hosting-maintenance/) runs sites behind an edge network with CDN, WAF and DDoS absorption, configures WAF rules and rate limiting, and watches them with checks from outside the platform, so an alert reaches an engineer who works the incident. Our [security scanning](https://computese.com/services/security-testing/) maps what you expose from the outside, including open ports, exposed services and forgotten subdomains: the places where an origin address leaks or a misconfigured service could be borrowed as a reflector.

## Key terms
- **DDoS attack**: Distributed denial of service: an attempt to make a service unavailable to its legitimate users by overwhelming it from many sources at once.
- **Botnet**: A group of internet-connected devices infected with malware and controlled remotely by an attacker, through command and control (C2) servers, to act together.
- **IP spoofing**: Forging the source address of a packet. It hides where attack traffic comes from and makes reflection attacks possible.
- **SYN flood**: A protocol attack that sends TCP connection requests and never completes the handshake, filling the server's backlog of half-open connections (RFC 4987).
- **HTTP flood**: An application-layer attack that sends large numbers of valid-looking web requests, often to expensive pages such as search or login, to exhaust the server behind them.
- **Reflection and amplification**: Sending small requests with the victim's spoofed address to public servers, which send much larger replies to the victim.
- **Bandwidth amplification factor (BAF)**: How many bytes of UDP payload a reflector sends back for each byte of request payload it receives. CISA lists BAFs by protocol.
- **Anycast**: Announcing the same IP address from many locations, so each packet is routed to the nearest one. It spreads a flood across a provider's whole network (RFC 4786).
- **Scrubbing**: Filtering traffic through a provider's network to discard attack packets and pass only legitimate traffic on to the protected service.
- **BCP 38**: The IETF best current practice (RFC 2827) for network ingress filtering: providers drop packets whose source addresses could not belong to the customer network they came from.

## Common questions

### What does DDoS stand for?

DDoS stands for distributed denial of service. Denial of service is the effect: legitimate users cannot reach a website, app or network. Distributed means the attack traffic comes from many sources at once, usually a botnet, which is what separates it from a DoS attack run from one machine.

### How long does a DDoS attack last?

Most are short. In the first half of 2026, 90.60% of the network-layer attacks Cloudflare mitigated ended in under 10 minutes, and its record 31.4 Tbps attack lasted 35 seconds. The Canadian Centre for Cyber Security notes that attacks can also persist for days or weeks.

### Can a DDoS attack steal data or hack my website?

Not by itself: a DDoS attack targets availability, not your data. CISA and the UK's NCSC both warn that attackers sometimes use a DDoS attack as a diversion for a second, quieter intrusion, so keep watching your other security alerts while you deal with the flood.

### Can a firewall stop a DDoS attack?

Only part of one. A firewall on your premises cannot help once a volumetric flood has filled the internet link in front of it, and stateful firewalls and load balancers can themselves be exhausted by protocol attacks. Large attacks have to be filtered upstream, by your provider, a CDN or a scrubbing service.

### Can you trace who is behind a DDoS attack?

Rarely from your own logs. The addresses you see belong to hijacked devices, spoofed sources or legitimate servers used as reflectors. Keep timestamps, source addresses, logs and packet captures, and report the attack: CISA or an FBI field office in the United States, the Canadian Centre for Cyber Security in Canada, or your national cyber security centre and police elsewhere.

### Is my small business a likely DDoS target?

Anyone with a public service can be one. Botnets are rented out through attack-for-hire services, and motives range from extortion and hacktivism to business rivalry and revenge. Most attacks are small (96.62% of the network-layer attacks Cloudflare mitigated in the first half of 2026 were under 500 Mbps), but an attack only needs to exceed the weakest link in front of your service.

## Sources
1. [Glossary: distributed denial of service](https://csrc.nist.gov/glossary/term/distributed_denial_of_service), NIST Computer Security Resource Center
2. [Glossary: denial of service](https://csrc.nist.gov/glossary/term/denial_of_service), NIST Computer Security Resource Center
3. [Understanding and Responding to Distributed Denial-of-Service Attacks (March 2024)](https://www.cisa.gov/sites/default/files/2024-03/understanding-and-responding-to-distributed-denial-of-service-attacks_508c.pdf), CISA, FBI and MS-ISAC
4. [Understanding Denial-of-Service Attacks](https://www.cisa.gov/news-events/news/understanding-denial-service-attacks), CISA
5. [Network Denial of Service, Technique T1498](https://attack.mitre.org/techniques/T1498/), MITRE ATT&CK
6. [Defending against distributed denial of service (DDoS) attacks (ITSM.80.110)](https://www.cyber.gc.ca/en/guidance/defending-against-distributed-denial-service-ddos-attacks-itsm80110), Canadian Centre for Cyber Security
7. [ENISA Threat Landscape 2026](https://www.enisa.europa.eu/sites/default/files/2026-09/ENISA%20Threat%20Landscape%202026_Final.pdf), ENISA
8. [Understanding the Mirai Botnet (USENIX Security 2017)](https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/antonakakis), USENIX
9. [Heightened DDoS Threat Posed by Mirai and Other Botnets (TA16-288A)](https://www.cisa.gov/news-events/alerts/2016/10/14/heightened-ddos-threat-posed-mirai-and-other-botnets), CISA
10. [2025 Q4 DDoS threat report](https://blog.cloudflare.com/ddos-threat-report-2025-q4/), Cloudflare
11. [RFC 4987: TCP SYN Flooding Attacks and Common Mitigations](https://www.rfc-editor.org/rfc/rfc4987.html), IETF
12. [IP Sysctl: tcp_syncookies](https://docs.kernel.org/networking/ip-sysctl.html), The Linux Kernel documentation
13. [Google Cloud mitigated largest DDoS attack, peaking above 398 million rps](https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps), Google Cloud
14. [UDP-Based Amplification Attacks (TA14-017A)](https://www.cisa.gov/news-events/alerts/2014/01/17/udp-based-amplification-attacks), CISA
15. [DNS Amplification Attacks (TA13-088A)](https://www.cisa.gov/news-events/alerts/2013/03/29/dns-amplification-attacks), CISA
16. [NTP Amplification Attacks Using CVE-2013-5211 (TA14-013A)](https://www.cisa.gov/news-events/alerts/2014/01/13/ntp-amplification-attacks-using-cve-2013-5211), CISA
17. [Cloudflare DDoS Threat Report H1 2026](https://blog.cloudflare.com/ddos-threat-report-2026-h1/), Cloudflare
18. [Denial of Service (DoS) guidance: Responding to a DoS attack](https://www.ncsc.gov.uk/collection/denial-service-dos-guidance-collection/a-minimal-denial-of-service-response-plan), UK National Cyber Security Centre
19. [Denial of Service (DoS) guidance: Upstream defences](https://www.ncsc.gov.uk/collection/denial-service-dos-guidance-collection/preparing-denial-service-dos-attacks1/upstream-defences), UK National Cyber Security Centre
20. [RFC 4786 (BCP 126): Operation of Anycast Services](https://www.rfc-editor.org/rfc/rfc4786.html), IETF
21. [About Magic Transit](https://developers.cloudflare.com/magic-transit/about/), Cloudflare Docs
22. [Module ngx_http_limit_req_module](https://nginx.org/en/docs/http/ngx_http_limit_req_module.html), nginx
23. [AWS Shield Standard overview](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-standard-summary.html), Amazon Web Services
24. [SP 800-189: Resilient Interdomain Traffic Exchange: BGP Security and DDoS Mitigation](https://csrc.nist.gov/pubs/sp/800/189/final), NIST
25. [RFC 2827 (BCP 38): Network Ingress Filtering](https://www.rfc-editor.org/rfc/rfc2827.html), IETF
26. [Report a cyber incident](https://www.cyber.gc.ca/en/incident-management), Canadian Centre for Cyber Security