DDoS Attack Protection and Mitigation: The Numbers That Decide If You Stay Up

Almost every DDoS conversation starts with a bandwidth number - a peak of 31.4 terabits per second, a flood of 14 billion packets per second, a quarter in which 18.2 million network-layer attacks were mitigated - and almost every DDoS outage is caused by something that number does not describe. The attack that takes a business offline is usually small, short and cheap: in the third quarter of 2026, 96 per cent of network-layer attacks ended within ten minutes and 98 per cent stayed under one gigabit per second. A single gigabit is enough to saturate the uplink of a mid-sized office, and ten minutes is longer than most organisations take to notice.

So this page is not a definition of denial of service. It is about the three numbers that decide whether you stay up - peak packet rate against the state limits of your origin, attack duration against your time to mitigate, and cost of downtime against the price of the control - and about the parts of the problem that a mitigation subscription does not solve, which are your exposed origin address, your authoritative DNS, your logging pipeline and your on-call rota. If you are buying protection, the sections on contract clauses, on the five post-incident numbers and on the first fifteen minutes are worth reading before the technical ones.

What DDoS mitigation actually is, in four deployment shapes

The industry uses one word for four different products, and the confusion is expensive because they fail in different ways. Ask a provider which of these you are buying and make them answer in writing.

• An always-on reverse proxy. Your DNS points at the provider, traffic terminates at their edge, and clean requests are forwarded to your origin. This is the shape most small and mid-sized businesses actually buy, usually as part of a CDN plan. It protects HTTP and HTTPS well, it can cache static content so that a large share of an attack never touches you at all, and it hides your origin - but only if your origin firewall accepts traffic from the provider and nothing else. The failure mode is architectural: it does nothing for non-HTTP services, and it does nothing for the origin address you have already published elsewhere.
• On-demand network diversion. When an attack is detected, the provider announces your address range from their network and traffic is pulled through a scrubbing centre, then returned over a tunnel. This shape protects everything, including mail, DNS, game servers and custom protocols. Its weakness is time. Diversion has to be triggered, either by an automatic detector or by a human, and in a population where the median attack is over before a conference call could start, an on-demand contract without an automatic trigger is a contract to be down for the full duration of most attacks.
• Always-on network-layer filtering at the transit or cloud provider. The cheapest and least visible version: infrastructure-level absorption included with your hosting or cloud account, with coarse signatures for the well-known floods. It is genuinely useful - it removes the noise floor of the internet - and it is not a plan for a targeted attack, because the signatures are generic and there is usually no one to call.
• Application-layer controls. Rate limits, bot management, request challenges, caching rules, WAF rules, and the ability to serve a cheap static page when the expensive one is under pressure. These are the only controls that help with a flood made of valid, well-formed HTTP requests from thousands of residential addresses, which is what most modern HTTP attacks look like. They are also the controls you can implement yourself this week, without a new vendor.

The common mismatch: an organisation buys a volumetric scrubbing contract, feels protected, and is then taken down by forty thousand requests per second against a search endpoint that queries a database on every hit. Nothing was volumetrically large. The link was at two per cent utilisation. The database was at a hundred.

Three numbers in every attack report, and the one nobody quotes

Attack reports quote bits per second because it is the largest number available. The two that predict an outage are packets per second and requests per second, and the ratio between bandwidth and packet rate tells you which of your components is about to fail.

The arithmetic matters because the same headline figure means wildly different things at different packet sizes. One gigabit per second carried in 64-byte packets is roughly 1.5 million packets per second. The same gigabit carried in full 1,500-byte packets is roughly 81,000 packets per second. That is an eighteen-fold difference in the work your network stack has to do to process what a dashboard reports as the identical attack.

• Bits per second fills the pipe. It matters if your uplink is 100 Mbps, 1 Gbps or 10 Gbps, and it is what the scrubbing provider's capacity is measured in.
• Packets per second exhausts the router, the firewall and the kernel. Small-packet floods kill devices that have plenty of bandwidth left. A firewall rated at 10 Gbps with a two-million-packets-per-second rating dies at 800 Mbps of 64-byte traffic, and its datasheet said 10 Gbps.
• Requests per second exhausts the application. This is the number that matters for HTTP floods, and the relevant capacity is not your bandwidth but your slowest dependency: the database connection pool, the search index, the third-party payment call, the session store.

Two more numbers belong next to those, and they are the ones a competent provider will volunteer. Peak concurrent connections determines whether you run out of ports, file descriptors or state table entries before you run out of anything else. And the attack's duration distribution - not its maximum - determines whether a human process can respond in time, which is the subject of a later section. A vendor that can only tell you about terabits has not measured the part of the problem you will experience.

What the 2026 numbers actually say

The most recent large-scale public telemetry is Cloudflare's third-quarter 2026 report, published on 29 October 2026. Cloudflare's network is a biased sample - it sees attacks against the organisations that buy from it, plus a very large amount of background noise - but it is the widest continuous sample available, and three of its findings change how a buyer should think.

• Volume is up sharply, size is not. 18.2 million network-layer attacks were mitigated in the quarter, 208 per cent more than the same quarter a year earlier, an average of 8,226 an hour, about 197,400 a day, one every 0.44 seconds. At the same time, attacks above one terabit per second fell to 251 from 805 in the previous quarter - plausibly a consequence of law enforcement action against four large IoT botnets in March 2026, and a reminder that the biggest attacks are a function of which botnets happen to exist that month.
• The typical attack is small and brief. 96 per cent of network-layer attacks ended in under ten minutes and 98 per cent stayed below one gigabit per second. The long tail is real - the quarter's longest sustained Mirai-classified attack ran 49.7 hours - but the centre of the distribution is what most defenders actually face.
• Vectors rotate fast, and the rotation is not a trend you can bank. CLDAP reflection, which had grown 580 per cent in the first half of the year, collapsed by 99.5 per cent in the third quarter to 0.05 per cent of attacks. DNS amplification rose 215 per cent to 3.43 per cent, UDP floods rose from 14.06 to 31.31 per cent, and plain DNS floods remained the single most common network-layer attack at 39.3 per cent. Mirai-classified traffic accounted for 46.5 per cent of all mitigated network-layer bytes in the quarter.

The corrective context: those numbers came from a network with more than 330 points of presence and 500 terabits per second of capacity, protecting a claimed fifth of the web. Your organisation does not need to survive the attacks in that report. It needs to survive the attack that is actually aimed at it, which is a different and much smaller event, and it needs to survive it on the first attempt rather than after an incident review.

The law enforcement picture is worth knowing because it is the only part of this problem that has improved. On 19 March 2026 the US Department of Justice, with authorities in Canada and Germany, disrupted command and control for four IoT botnets - Aisuru, KimWolf, JackSkid and Mossad - that had infected more than three million devices worldwide, most of them routers, cameras and digital video recorders. The operators had issued more than 200,000, 90,000, 25,000 and 1,000 attack commands respectively, and some attacks measured around 30 terabits per second. In April 2026 a coordinated action week across 21 countries under Operation PowerOFF took down 53 booter domains, made four arrests and sent more than 75,000 warning messages to people who had bought attacks. Botnets get rebuilt, but the operational cost of renting an attack went up.

Why the attacks that hit small businesses never make the news

The reporting bias is structural. A 31-terabit attack is a story; a 300-megabit attack that closes a logistics company's customer portal for four hours is a bad Tuesday. But the second event is far more common and, relative to the victim, far more damaging.

The arithmetic of an unprotected small business is unforgiving. A 200 Mbps flood is enough to saturate a 200 Mbps fibre circuit and everything behind it. Reaching 200 Mbps takes roughly 2,500 compromised devices each contributing 80 kilobits - a rounding error in a botnet with hundreds of thousands of members, and an amount of traffic that a booter sells for less than a monthly streaming subscription. A dedicated server with a one-gigabit port and no filtering is taken offline by a fraction of what one cable modem can carry.

The belief that invisibility protects you is also wrong, and it fails in both directions. Some victims are picked because they are visible: a retailer during a sale, a media site during an event, a company in the news. Others are picked because nobody will fight back: a dental practice, a regional manufacturer, a school. And a growing share are picked by accident - collateral from a carpet-bombing attack that spreads small amounts of traffic across an entire address range, or from a botnet operator testing new infrastructure on whatever responds. You do not have to be interesting to be a target. You have to be reachable.

There is one more asymmetry worth naming: the attacker pays by the minute, the defender pays by the hour. A cheap attack that costs you an afternoon of engineering, a customer apology email and a missed service credit is a profitable trade even when the attack itself fails to keep you down.

The attack types, and the control that actually catches each

Attack names matter less than the layer they hit, because the layer determines which control can see them at all. A volumetric filter cannot see a hundred requests per second; a WAF cannot see a SYN flood. The list below is ordered by how often each appears in the small and mid-market incidents we are asked about, not by how often it appears in press releases.

• DNS flood. The most common network-layer attack of the quarter at 39.3 per cent. Valid-looking queries for random subdomains of your zone, so that every cache misses and every query reaches the authority. The name of the game is cache hit ratio: responses with long TTLs served from edge caches absorb this; a zone with 60-second TTLs and no caching does not. If your DNS provider is also your registrar and also your mitigation vendor, find out what happens when their anycast is the target.
• UDP flood. 31.31 per cent of the quarter's attacks and the simplest to build. Random destination ports, random payloads. Defence is mostly upstream - access control lists that permit only the ports you actually serve, and provider-side filtering. On a Windows host, nothing you install locally survives a full pipe.
• DNS and NTP amplification. You send a small spoofed query, the resolver sends a large answer to the victim. DNS amplification ratios are typically in the tens - a 60-byte query producing a response several times larger - and the historically catastrophic cases were far worse: NTP monitoring responses reached ratios in the hundreds, and the 2018 memcached attacks that hit GitHub at 1.35 Tbps exploited a protocol with a theoretical amplification in the tens of thousands. The lesson is not about the victim; it is that any open recursive resolver, exposed CLDAP service, NTP server with monitoring enabled or memcached instance on the internet is a weapon. Close yours, and check your own address ranges for other people's.
• TCP SYN flood and state exhaustion. Half-open connections fill the backlog and the connection tracking table. A Linux host with the default 1,024-entry SYN backlog and default timeouts is exhausted by a few thousand packets per second. Defence is SYN cookies, shorter SYN retry timeouts, per-source connection limits and upstream SYN proxies. The tell-tale is a service that is up but unreachable while CPU and bandwidth look normal.
• Carpet bombing. Instead of concentrating on one address, the attack spreads across the whole range, so no single destination trips a threshold. Cloudflare documented a 29.7 Tbps UDP carpet-bomb attack in late 2025 that averaged roughly 15,000 different destination ports per second, which defeats per-IP and per-port alerting. The only defence is range-level detection, which means your provider has to be watching your prefixes as a set.
• HTTP request floods. Valid requests, often from residential proxies or headless browsers, against the most expensive endpoint you have: search, login, checkout, a report generator, an API that fans out to five services. Rate limiting by IP fails against distributed sources; the controls that work are per-session and per-account limits, caching, query cost limits, challenge pages for suspicious clients, and an expensive-endpoint inventory so you know which URLs need protecting.
• HTTP/2 Rapid Reset and protocol-level abuse. CVE-2023-44487 exploited stream cancellation to make a server do work and then throw it away. In 2023 Google reported a peak of 398 million requests per second and Cloudflare 201 million, carried by a botnet of roughly 20,000 machines. It was patched quickly across major servers, but the pattern recurs: any protocol feature that lets a client request work cheaply and abandon it expensively will be turned into an attack. Keep your edge and origin software current, and cap concurrent streams.
• Slow attacks. Slowloris-style connections that open and never finish, slow POST bodies, slow-read against large responses. They consume connection slots rather than bandwidth, and they are almost invisible to volumetric monitoring. Timeouts, minimum data rates, and connection limits per source are the controls.
• TLS and CPU exhaustion. Handshake floods, renegotiation, expensive cipher preferences, oversized keys. The origin's CPU dies while bandwidth stays flat. Session resumption, OCSP stapling, terminating TLS at the edge and rate limiting new handshakes per source all help.

Where the failure actually happens: the origin, the DNS, and the leak

Three failure modes account for most losses on organisations that had already bought protection, and none of them is a capacity problem.

The origin is reachable around the proxy

An always-on proxy protects you only if it is the only way in. Attackers find origin addresses through the ordinary traces every company leaves: mail exchangers on the same range, SPF and DKIM records that name hosting providers, staging and VPN hostnames, old DNS history in passive-DNS databases, certificate transparency logs listing every name on a shared certificate, subdomains that were never moved behind the proxy, and the IPv6 address that was assigned but never added to the proxy configuration. Once the address is known, the attack goes there and the dashboard at the edge stays green while the site is down.

• Restrict the origin firewall to the provider's published address ranges, and keep the list current - providers add ranges.
• Move mail and management interfaces off the web origin's range, or terminate them elsewhere.
• Inventory every name in certificate transparency for your domain, not just the ones in your DNS zone file.
• Retire old addresses rather than reusing them; a freed address in an attacker's list is a future incident.

The state tables fill before the link does

The kernel's connection tracking table, the SYN backlog, the load balancer's session table, the database connection pool and the worker pool are all finite and all much smaller than the pipe. A 200,000-connection SYN flood against a default Linux host with a 65,536-entry conntrack table is a complete outage at a bandwidth cost the monitoring graph barely registers. Tuning raises the ceiling; the ceiling is still finite; only filtering upstream removes the load.

The logs become the attack surface

One million packets per second with a 200-byte log line is 200 megabytes per second of writes, and that is before indexing. Disk fills, the log shipper blocks, the application blocks behind it, and the incident is now also an evidence problem because the retention window rolled over. Sampling, tiered retention, per-destination rate limits and keeping a small always-on capture for forensics are part of the design, not an afterthought.

DNS is the real single point of failure

If the resolver chain cannot answer, nothing else you own matters - the mitigation provider's edge will not be reached, the status page will not resolve, and your customers will conclude the company is gone. Two independent authoritative providers on separate networks, long TTLs for records that do not change, a plan for lowering TTLs before a known event, and a status page hosted outside your own infrastructure are cheap and they are the difference between four hours and forty minutes.

Time is the metric, not capacity

98 per cent of attacks stay under one gigabit per second and 96 per cent end within ten minutes. Both figures point at the same conclusion: your ability to be protected is a function of how fast mitigation starts, not how many terabits the provider owns. A 31.4 Tbps attack that lasted 35 seconds, as one did in November 2025, cannot be answered by a human being on a call. It is answered automatically or not at all.

The arithmetic of a manual process is brutal. Detection by a customer complaint takes five to fifteen minutes. Confirming it is not a code deploy, paging the right person, opening a ticket with the provider and waiting for a diversion takes another fifteen to thirty. At 96 per cent of attacks ending inside ten minutes, the response arrives after most attacks have already stopped - and the attacker, who pays per minute, simply repeats the attack tomorrow with the same result.

• Prefer always-on mitigation over trigger-based mitigation for anything customer-facing, even if the always-on product is more expensive per month.
• Set detection thresholds on packets per second, new-connection rate and per-ASN concentration, not only on bandwidth.
• Keep TTLs short enough to move traffic quickly and long enough to survive an authoritative outage - and know which of your records you would change under pressure.
• Automate the first action: a script or a provider feature that enables the stricter rule set, rather than a runbook line that says call the vendor.
• Rehearse it. A protection plan that has never been triggered in a test is a hypothesis, and the test is where you discover that the origin firewall rule blocks the provider's new range.

Always-on, on-demand, or both: the cost shape of the decision

DDoS pricing is not a single market; it is three markets with different physics. At the bottom, protection is a feature of a CDN or hosting plan and its capacity is shared, unmetered in name and unspecified in practice. In the middle, cloud providers sell committed protection - AWS Shield Advanced, for example, is priced at 3,000 US dollars a month per organisation on a one-year commitment, on top of the data-transfer-out charges that attack traffic can inflate, with cost-protection provisions that refund the attack-driven spike. Shield Standard is included at no extra cost and is the coarse layer described earlier. At the top, dedicated scrubbing contracts are priced on committed capacity, so a 10 Gbps commitment costs a multiple of a 1 Gbps commitment and is usually sold annually with a burst allowance.

The mistake in all three cases is buying capacity against the wrong number. For a business whose realistic threat is a 300 Mbps, four-minute flood, a 100 Gbps commitment buys nothing that a 10 Gbps commitment does not, and the money would be better spent on the application-layer controls, the second DNS provider and an hour of rehearsal. For a business whose threat includes extortion from a botnet with a documented 30 Tbps capability, the correct answer is not to buy 30 Tbps - nobody can - but to buy always-on absorption at a provider whose edge is in the path, and to accept that the origin never sees the traffic.

A workable rule for small and mid-sized organisations: one always-on layer in front of everything public, sized to survive ten times your own bandwidth rather than the internet's worst day; application-layer controls you own and can tune; a second DNS provider; and a written escalation path with the provider that includes a named contact and an account PIN. That combination costs a few hundred dollars a month at the low end and covers the attacks that actually happen. Above that, the spend that changes outcomes is not more capacity - it is readiness.

The first fifteen minutes: a runbook that works at 3 a.m.

Incident response for availability is mostly decision-making under incomplete information, and the runbook exists so that the person woken at 3 a.m. does not have to be clever. Ours has seven steps, and the ordering matters.

1. Confirm it is an attack and not your own change. Check the last deploy, the last configuration change and the last certificate renewal first - a meaningful share of "DDoS incidents" are self-inflicted. Then look at the shape: traffic concentrated in a few source ASNs, a flat request rate independent of human rhythm, a narrow set of URIs, user agents that repeat, TLS fingerprints that cluster, geography that does not match your market.
2. Identify what is actually saturated. Link, packet rate, firewall session table, load balancer, application workers, database connections, disk. The answer determines which control you reach for, and choosing the wrong one wastes the only minutes you have.
3. Turn on the strict profile. Whatever the provider calls it - under attack mode, high security, a stricter WAF rule set - enable it by default at the start, not after two rounds of escalation. Accept the legitimate-traffic loss; you can relax it later, and a challenge page is better than a 502.
4. Reduce what the origin must do. Serve cached or static responses for the expensive paths, disable non-essential features, queue background jobs, disable the search endpoint if that is what is being hit. Degrading is not losing.
5. Preserve evidence before you clean up. Packet captures from the provider, edge logs with the retention window extended, the ransom note if there is one, and timestamps in UTC. Attribution and insurance claims both depend on what you saved in the first hour.
6. Communicate on a channel that does not depend on the thing that is down. Status page on separate infrastructure, a pre-written holding statement, one person authorised to speak. Silence is read as collapse and it costs more goodwill than the outage itself.
7. Write down the revert plan. The second outage in these incidents is almost always caused by the mitigation: a firewall rule applied too broadly, a challenge that blocks the payment provider's callback, a rate limit that locks out the mobile app. Know how to undo each step, and test the undo before you need it.

Ransom DDoS: the note, the demo attack and the deadline

Extortion follows the same script almost every time. An email arrives claiming an attack is coming, sometimes with a small demonstration attack already running, sometimes with a demand in cryptocurrency and a deadline measured in hours. The demand is usually modest by enterprise standards - enough to be payable without a board meeting - and the deadline is short because the business model depends on panic rather than on capability.

The consensus guidance from law enforcement and national cyber agencies is consistent and worth repeating plainly: do not pay. Payment does not buy immunity, it marks the victim as a payer, and in most documented cases the attacker has neither the capability nor the intention to sustain a campaign. But "do not pay" is not a response plan, and the useful part is what you do in the meantime.

• Treat the demonstration attack as evidence, not as proof of capability. Capture it, measure its peak, and check whether it is volumetric noise or something targeted at your weakest endpoint.
• Preserve the note with full headers, do not reply, do not negotiate, and do not click anything in it. Forward it to your insurer, your lawyer and the relevant authority - in the United States, the FBI's Internet Crime Complaint Center; elsewhere, the national CERT.
• Calculate the deadline in your own timezone, decide the position in advance, and give one person authority to hold it. The decision is easier before the attack than during it.
• Raise your posture for the window rather than permanently: strict profile on, expensive features off, on-call doubled, status page ready.
• Tell your provider. Many will add standing mitigation for a threatened customer at no cost, and they see the same botnet traffic from other tenants and can tell you whether the threat is credible.

The most common failure is not paying. It is spending two days of senior engineering time on a bluff, then discovering that the real incident that week was a credential-stuffing run against the same login page. Extortion is a distraction attack as often as it is a denial-of-service attack.

The contract clauses that decide what you get

Mitigation contracts are written to protect the provider, and the clauses that matter are the ones nobody reads before signing. Ask these six questions and get the answers in the contract, not in a sales deck.

• How is an attack defined? If the definition requires traffic above a threshold, then everything below it - which is 98 per cent of attacks - is out of scope. Ask for the threshold in packets per second as well as bits per second, and ask what happens below it.
• What is the service credit, and what is it a percentage of? Credits are typically a fraction of the monthly fee, so a 25 per cent credit on a 500-dollar plan is 125 dollars against an outage that may have cost tens of thousands. The credit is not compensation; it is a gesture. Buy insurance for the rest.
• What counts as successful mitigation? "Traffic was scrubbed" and "your service stayed available" are different promises. Only the second is worth paying for, and only the second can be measured at your origin.
• What is excluded? Application-layer floods, attacks on non-HTTP protocols, attacks originating inside your own cloud account, and "attacks that exploit an application vulnerability" are commonly excluded. Map your own exposure against the exclusion list before signing.
• What is the escalation path? A named contact, a phone number that is answered, an account PIN, and a stated response time. Test it during onboarding, not during an incident.
• Who owns the logs and for how long? You need enough retention to investigate and to support an insurance claim, and you need the right to export before the window closes.

One clause deserves separate emphasis because it is the most overlooked: cost protection. Attack traffic that reaches your cloud account can generate a bandwidth bill larger than the outage. Most providers offer a mechanism to waive attack-driven charges, and it is usually available only if you have opted in before the attack.

The five numbers to demand afterwards

Post-incident reviews for availability events tend to produce a timeline and a list of action items, and to skip the measurements that would tell you whether the money is working. Five numbers per event, tracked over a year, turn DDoS spending from a belief into a decision.

1. Time to mitigate, from first attack packet to traffic being filtered, in seconds rather than in narrative.
2. Share of the attack absorbed before the origin - the provider's drop rate, which they can report, and your own packet counters, which they cannot fake.
3. Legitimate traffic lost during the strict profile: error rate, challenge pass rate, conversion rate on the affected paths.
4. False positives, meaning customers or partners who were blocked and complained, and how long they were blocked.
5. Revenue and contractual impact, including service credits owed to your own customers.

Then run the replay. Take the attack's signature - source ASNs, URI mix, packet size, request rate - and reproduce it in a test environment under written authorisation. A protection configuration that has never seen a realistic attack is untested, and untested protection fails at the moment it is most expensive to fail.

Testing your resilience without breaking the law

This is where the DDoS industry is least honest. Stress-testing and "attack simulation" services are widely advertised, and most of the marketing implies that because the vendor has a licence and an acceptable-use policy, its customers can point an attack anywhere. That is not the law in any jurisdiction we work in. Using a service to send traffic at a system you do not own is unauthorised access, and the fact that you bought it from a company with a website does not change that: 18 U.S.C. 1030 in the United States, section 3 of the Computer Misuse Act 1990 in the United Kingdom, and the equivalent offences transposed from Directive 2013/40/EU across the European Union all reach it. The 2026 enforcement wave is a good reminder that the buyers are in scope, not just the operators: Operation PowerOFF's April action week covered 21 countries, took down 53 domains, led to four arrests, and sent more than 75,000 warnings to users.

A legitimate resilience test has five properties, and any of them missing turns it into an offence.

• Written authorisation from the asset owner, signed by someone entitled to grant it, naming the exact targets - IP addresses, hostnames, protocols, ports - and the time window. It is not enough to be the customer of the CDN: the permission must come from the party that owns the systems and the network path.
• Permission from the network providers in the path. Most CDNs and cloud providers prohibit load or stress testing without prior approval, and an approved test that trips their abuse automation is still an outage.
• Disclosed source and volume, with the test generator identified to you in advance so that your own defences and your provider's can be configured not to over-react.
• A stop authority - one named person who can end the test within a minute, with a working channel to do it, agreed before the first packet.
• Scope discipline. No third-party domains, no shared infrastructure you do not control, no testing of a supplier's service to see whether they cope. Collateral damage to a shared host is still unauthorised access on the other tenants.

What we do in this space is deliberate and narrower than what is advertised elsewhere: we assess exposure and configuration, we build and rehearse the response plan, we harden the application against request-level floods, and where a resilience test is genuinely needed we run it with the authorisations above in place. We do not sell attack capacity, we do not run "stress tests" against systems whose owner has not signed, and no legitimate provider should.

The free 80 per cent: hardening before you buy anything

Most of what makes an organisation survivable costs configuration time rather than licence fees, and it should be done before the contract is signed because it changes what you need to buy.

• Cache what does not change. Every byte served from an edge cache is an attack packet that never reaches your origin. Static assets with long cache lifetimes and versioned filenames are the cheapest capacity you will ever buy.
• Rate limit the endpoints that cost real money. Login, registration, password reset, one-time-code verification, search, checkout and any endpoint that calls an external API. Limits per IP, per session and per account, with a challenge rather than a hard block for the first offence.
• Remove your reflection surfaces. No open recursive resolvers, no CLDAP services, no NTP monitoring, no exposed memcached, no SSDP on the perimeter. These are other people's weapons and your liability.
• Harden the kernel defaults you inherited. SYN cookies on, sensible SYN retry counts, connection tracking sized to the load you expect, file descriptor limits raised, keepalive tuned so idle connections cannot accumulate.
• Cap the expensive work. Pagination limits, query timeouts, GraphQL depth and cost limits, bounded image resizing, and exports generated asynchronously rather than inside the request.
• Keep a static fallback page on separate infrastructure. When the origin is unreachable, the marketing site and a "we are aware" notice should still resolve and render.
• Alert on the right signals. Packets per second, new connections per second, requests per second per URI, source-ASN concentration, and a sudden change in the ratio of bandwidth to requests. Bandwidth alone misses every attack that matters at your size.
• Sample logs at the edge and keep full logs only for the short window you would actually investigate. Otherwise the attack takes out your logging, then your monitoring, then your disk.

Two of these overlap with work we do routinely: the exposure review that finds the origin addresses and the reflection surfaces, and the application hardening that makes request floods expensive for the attacker rather than for you. If you are starting from nothing, our small business security audit checklist is the sequence we use, and the security hardening service describes the configuration work in more detail.

What it costs, honestly

Any figure here is a range, and the ranges in public surveys are estimates from self-reported data, not audited measurements. With that caveat: ITIC's annual survey has for several years found that more than 90 per cent of mid-size and large enterprises put the cost of an hour of downtime above 300,000 dollars, and Uptime Institute's 2026 research found 57 per cent of respondents placing their most recent significant outage above 100,000 dollars, with roughly one in five above a million. Splunk and Cisco's 2026 estimate of about 15,000 dollars per minute across the Global 2000 is an average that hides an enormous spread. Small businesses sit far below those numbers - a few thousand dollars an hour is a realistic working figure for many - but the shape of the decision is the same.

That shape is: one hour of outage multiplied by your hourly cost should exceed the annual price of the always-on layer, or the layer is not the right layer. For a business where an hour costs 5,000 dollars, three hours of downtime a year is 15,000 dollars, and a plan that costs 3,600 dollars a year and eliminates most of it is straightforwardly worth it. For a business where an hour costs 200,000 dollars, the same plan is not the answer and the conversation moves to dedicated capacity, contractual commitments and insurance.

How we work on this

Denial-of-service work sits inside a wider security practice, and it rarely stands alone: the same inventory that tells you which endpoints are expensive also tells you what is exposed, and the same incident process that handles a flood handles a ransomware event. Our engagement model for this problem is four parts.

• Exposure and dependency mapping - origin addresses, DNS chain, providers, third parties, and the endpoints that would fail first.
• Architecture review and hardening - caching, rate limits, edge configuration, kernel and load balancer tuning, logging design. See security hardening and vulnerability assessment.
• Response readiness - a written runbook, a tested escalation path, a communication plan and a rehearsal, in the shape described in our incident response plan guide.
• Authorised resilience testing - only with the authorisations described above, and only against systems you own or operate.

Everything here assumes lawful, authorised work on systems you control. If what you need is an attack, we are the wrong supplier and the right answer is that no legitimate one exists. If what you need is to not be taken down by one, start a conversation and bring your current provider contract, your DNS configuration and your last three months of traffic graphs.

Frequently asked questions

What is DDoS mitigation?

It is the set of controls that keep a service available while someone is deliberately sending more traffic than it can handle. In practice that means filtering or absorbing traffic before it reaches your infrastructure, reducing the work each request costs, and having a rehearsed process for the minutes when the attack is live. Capacity is one input; architecture, caching, rate limiting and speed of response are the others.

Can a small business be protected against a one-terabit attack?

Yes, but not by owning a terabit of capacity. You are protected by having a provider with a large edge in front of you, so that the attack terminates on their network rather than on yours. What a small business cannot do is survive that attack on its own uplink, which is why the architectural choice matters more than the size of the pipe.

Is DDoS protection worth it for a company of ten people?

Usually yes, but not the enterprise version. A CDN with an always-on proxy, a second DNS provider, rate limits on login and search, and an hour of rehearsal cover the attacks that realistically hit a ten-person company, and they cost far less than a day of lost trading. The mistake is buying a scrubbing contract sized for a bank and leaving the login endpoint unprotected.

What should I do if I receive a DDoS ransom email?

Do not pay and do not reply. Preserve the message with its headers, capture any demonstration attack, tell your provider and your insurer, report it to law enforcement - the FBI's IC3 in the United States, your national CERT elsewhere - and raise your defences for the stated deadline rather than permanently. Most such threats are bluffs, and the response should cost you an afternoon rather than a week.

Do you offer DDoS-for-hire or stress testing against third parties?

No. We do not sell attack capacity and we do not test systems without written authorisation from their owner and the permission of the networks in the path. Sending attack traffic at a system you do not own is a criminal offence in the jurisdictions we operate in, regardless of what a vendor's acceptable-use policy says.

How quickly can mitigation start?

With always-on protection, immediately - the traffic is filtered as it arrives, with no trigger. With on-demand diversion, the clock starts when the attack is detected, and detection plus a human decision typically takes longer than the 96 per cent of attacks that end inside ten minutes. That difference, not the capacity figure, is what usually decides the outcome.