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

What is a DDoS attack?

NIST's glossary, 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, "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 and eavesdropping 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: 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. Skill is not required either: CISA notes that botnets are rented out to attack-for-hire services (often called booters or stressers) that let unskilled users launch attacks. In Europe, ENISA's Threat Landscape 2026, 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 draws the line this way:

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 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.

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 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 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:

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. 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 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 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.

# 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, 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 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.

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:

The NTP case shows how a debugging feature becomes a weapon: monlist returns the last 600 addresses 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 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 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 (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.

The traffic-type row follows from the mechanisms above: CISA's DNS alert 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):

# 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 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) 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.

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, 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. 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:

• 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 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:

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.

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 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 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, 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 in Canada, and to the police.
4. Update the plan with what was missing: a contact, a switch, a gap in monitoring.

If you want this handled, our hosting and maintenance service 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 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.