What Is a DDoS Attack? How It Works and How to Protect Against It

A DDoS (Distributed Denial of Service) attack is an attempt to make a website, server, or network unavailable by overwhelming it with a flood of traffic from multiple sources. The goal is simple: send more traffic than the target can handle, causing it to slow down or crash entirely.

The "distributed" part means the attack comes from many different sources simultaneously — often thousands or millions of compromised devices (a botnet). This makes DDoS attacks much harder to mitigate than simple DoS attacks from a single source, because you can't just block one IP address.

DDoS attacks are one of the most common cyber threats. They're relatively easy to launch (DDoS-for-hire services exist for as little as $10/hour), but they can cause massive damage — taking websites offline, disrupting businesses, and costing millions in lost revenue and mitigation costs.

Volumetric attacks overwhelm the target's bandwidth by flooding it with massive amounts of data. Examples include UDP floods, ICMP floods, and DNS amplification attacks. These are measured in bits per second (bps) and can reach terabits per second at scale.

Protocol attacks exploit weaknesses in network protocols to consume server resources. The classic example is the SYN flood: the attacker sends millions of TCP SYN packets (connection requests) but never completes the handshake, filling up the server's connection table.

Application layer attacks (Layer 7) target specific web applications with requests that look legitimate but are designed to exhaust server resources. HTTP floods, Slowloris attacks, and DNS query floods fall into this category. These are harder to detect because each individual request looks normal.

DNS amplification is particularly devastating: the attacker sends small DNS queries to open DNS resolvers with the source IP spoofed to the victim's address. The resolvers respond with much larger DNS responses (amplified by 50–70x), flooding the victim with traffic they never requested.

GitHub (2018): Hit by 1.35 Tbps of traffic using Memcached amplification — at the time, the largest DDoS attack ever recorded. GitHub was intermittently unavailable for about 10 minutes before Akamai's DDoS mitigation service absorbed the attack.

AWS (2020): Amazon Web Services mitigated a 2.3 Tbps DDoS attack, the largest on record at the time.

Dyn DNS (2016): A massive DDoS attack on the DNS provider Dyn (using the Mirai IoT botnet) caused outages for major websites including Twitter, Netflix, Reddit, CNN, and Spotify. This demonstrated how attacks on infrastructure providers can cause cascading failures across the internet.

Cloudflare (2023): Mitigated a record-breaking 71 million requests per second HTTP DDoS attack, generated by a botnet of about 30,000 IP addresses.

These attacks are growing larger and more sophisticated each year as botnets expand and new amplification vectors are discovered.

Use a CDN/DDoS protection service: Services like Cloudflare, AWS Shield, Akamai, and Google Cloud Armor sit in front of your servers and absorb DDoS traffic. Cloudflare's free tier includes basic DDoS protection — there's no excuse not to use one.

Rate limiting: Configure your web server and application to limit the number of requests from a single IP address. This helps mitigate application-layer attacks.

Overprovision bandwidth: Having more bandwidth than you typically need gives you headroom to absorb small attacks without going offline.

Anycast routing: Distributes incoming traffic across multiple data centers, so no single location bears the full brunt of an attack.

Keep software patched: Unpatched servers can be recruited into botnets that launch DDoS attacks against others. Keep your OS, web server, and applications updated.

Have a response plan: Know your DDoS mitigation service's activation process before an attack happens. During an attack is not the time to be reading documentation.

Monitor your traffic: Use monitoring tools to establish baseline traffic patterns. Anomaly detection can alert you to an attack in its early stages, when mitigation is most effective.

The largest volumetric attacks do not come from attackers with large amounts of bandwidth. They come from reflection and amplification, which lets a modest connection generate an enormous flood.

The mechanism has two parts. Reflection means spoofing the victim's address as the source of a request sent to a third-party server, so the response goes to the victim rather than the attacker. Amplification means choosing a protocol where the response is far larger than the request.

The amplification factors are startling:

A memcached factor of 51,000 means one megabit per second of attacker bandwidth produces 51 gigabits at the victim. This is exactly how GitHub was hit with 1.35 Tbps in February 2018 from a comparatively small botnet.

Every one of these depends on two failures that are individually fixable.

Source address spoofing. Reflection is only possible because networks accept packets with forged source addresses. BCP 38 — ingress filtering — requires operators to drop outbound packets whose source address does not belong to their network. It has been the recommendation since 2000 and deployment is still incomplete, which is the root enabler of the entire attack class.

Exposed UDP services. Memcached, NTP with monlist enabled, open DNS resolvers and SSDP on internet-facing interfaces are all misconfigurations. If you run any of these, bind them to localhost or a private interface — check with the port checker. An exposed memcached instance is not just a risk to you; it is ammunition pointed at everyone else.

Volumetric attacks make headlines because the numbers are large. Layer 7 attacks are more common, far cheaper to run, and considerably harder to filter.

The essential difference: a volumetric attack tries to saturate your bandwidth, and can be absorbed by anyone with more capacity than the attacker. A layer 7 attack sends requests that are individually indistinguishable from legitimate traffic, but which each cost you far more to answer than they cost the attacker to send.

HTTP floods target expensive endpoints — a search query with wildcards, a report generation page, an unauthenticated API call that hits the database. A few thousand requests per second against the right endpoint will exhaust a database connection pool while your bandwidth graph stays flat.

Slowloris opens many connections and sends partial HTTP headers very slowly, holding worker threads open indefinitely. It requires almost no bandwidth. Apache with the prefork MPM is highly vulnerable; nginx, which uses an event-driven model, largely is not. mod_reqtimeout mitigates it on Apache.

SSL/TLS renegotiation attacks exploit the asymmetry in handshake cost — a TLS handshake is roughly fifteen times more expensive for the server than the client.

Cache-busting appends random query strings so that every request misses the CDN cache and reaches the origin.

Defending these requires distinguishing intent rather than volume, which is fundamentally harder:

• Rate limiting per client, keyed on something better than IP alone, since IPv6 gives an attacker an entire /64 and CGNAT puts thousands of legitimate users behind one IPv4 address.
• Challenge suspicious clients with a JavaScript computation or a CAPTCHA rather than blocking, so false positives are recoverable.
• Cache aggressively and normalise query strings so cache-busting fails.
• Bound expensive operations — timeouts on every query, hard caps on result set size, no unbounded wildcard searches for anonymous users.
• Behavioural analysis, which is what commercial WAFs are actually selling.

The time to plan is not during an incident. A few decisions made in advance determine whether an attack is a nuisance or an outage.

Hide your origin server address. If you sit behind a CDN, an attacker who learns the origin IP can bypass the protection entirely and hit you directly. Origins leak through DNS history archives, through mail sent directly from the web server, through TLS certificate transparency logs listing hostnames like origin.example.com, and through error pages that print the server address. Configure the origin firewall to accept traffic only from your CDN's published address ranges — this is the single highest-value preparation step, and it makes the leak irrelevant.

Know your provider's DDoS position before you need it. Some absorb attacks as part of the service. Others null-route your address to protect their other customers, which achieves the attacker's goal for them. Ask specifically, in advance.

Write the runbook now. Who is called, what the escalation path to the provider is, which account numbers and support contacts are needed, and what the criteria are for enabling emergency mitigation. During an incident nobody has the composure to find this out.

Keep DNS TTLs low on records you might need to move. Repointing traffic to a scrubbing provider mid-attack is only fast if the TTL permits it. 300 seconds on your apex and www records costs nothing.

Have out-of-band monitoring. Monitoring hosted on the infrastructure under attack tells you nothing. An external check from a different provider tells you what users see.

Know your normal. Baseline traffic, request rates and error rates so that anomalies are visible. Without a baseline, distinguishing an attack from an unexpected marketing success is guesswork.

Rehearse the failover. A mitigation path nobody has tested is a hypothesis, not a plan.

Can I trace who is attacking me?

Rarely, and not reliably. Volumetric attacks use spoofed source addresses, so the addresses in your logs belong to reflectors and compromised machines rather than the attacker. Botnet traffic comes from thousands of unwitting victims. Attribution is possible with law enforcement involvement and provider cooperation, but it is not something you can do from your access logs.

Should I report a DDoS attack to the police?

In most jurisdictions it is a criminal offence and yes, worth reporting — particularly if extortion is involved, which is common. Preserve logs, note precise start and end times, and keep any communications from the attacker. Realistically, prosecution is uncommon unless the attack is part of a larger investigation.

Will a bigger server stop a DDoS?

For small attacks, sometimes. For anything volumetric, no — you cannot buy your way past a 1 Tbps flood, and the attacker's cost to double the attack is far lower than your cost to double capacity. Mitigation has to happen upstream of your bandwidth, which is what scrubbing providers and CDNs sell.

What is the difference between DoS and DDoS?

A DoS attack comes from one source, which makes it straightforward to block. A DDoS is distributed across many sources — often tens of thousands of compromised devices — so there is no single address to block and the traffic looks like it comes from everywhere.

How long do attacks usually last?

Most are short: the majority run under ten minutes, often as a test or a demonstration attached to an extortion demand. Sustained multi-day attacks happen but are much rarer, since they cost the attacker money too. Ransom demands typically follow a brief demonstration attack — paying is generally advised against, since it marks you as a paying target.