Ecommerce Site DDOS Attack: A Playbook for the First 60 Minutes (and the Weeks Before)

An ecommerce site DDoS attack rarely announces itself the way retailers expect: no bandwidth graph pinned to the ceiling, no dramatic outage banner, just a checkout that takes eleven seconds to respond on the busiest Friday of the quarter, a scatter of 504s at the load balancer, and a support inbox filling with “payment failed”while the CDN dashboard reports a perfectly ordinary day. Bandwidth looks fine. That is usually the point.

Distributed denial-of-service (DDoS) attacks against online shops have shifted away from raw volume towards the handful of endpoints that cannot be cached and cannot be skipped: search, faceted filtering, cart, login, coupon validation and the payment callback. Those are the parts of the stack that hit the database on every request. This piece is a runbook for the hour an attack starts, and for the fortnight before it, when the decisions that determine how that hour goes are actually made.

What an ecommerce DDoS attack actually targets on your shop

Three surfaces belong to the retailer, and they fail in different ways.

The first is the network pipe: the transit into your hosting, saturated by volumetric floods (UDP reflection, amplified DNS or NTP responses, carpet-bombing across a /24). The second is the application layer, where HTTP requests are cheap for the attacker and expensive for you. The third is authoritative DNS, which is the layer most retailers leave sitting with a domain registrar on a free plan while paying four figures a month for web protection. Take DNS down and the shop is gone regardless of how well the HTTP layer is defended. Nobody reaches your beautifully scrubbed origin if the name never resolves.

Why a small Layer 7 flood hurts more than a big volumetric one

Consider a mid-sized Adobe Commerce (Magento) install behind a CDN. A few thousand requests per second aimed at /search?q= with randomised terms, each one stacking two or three facet filters, will bypass the page cache entirely because every URL is unique. Each request opens a database connection. Connection pool exhausts, PHP-FPM workers queue, the load balancer starts returning 502s and 504s, and the bandwidth graph stays flat enough that the first hour is spent looking at the wrong dashboard.

The same logic applies to add-to-cart, coupon code validation, account login and the postcode lookup on the delivery step. Anything that writes to session state, queries stock or calls a third-party API is a lever. Attackers who bother to browse the site first find these in about ten minutes.

Payment and fulfilment callbacks: the failure nobody plans for

Checkout is not a single request. It is a conversation between your site, a payment service provider (PSP), a 3-D Secure step at the card issuer, and a webhook coming back the other way to confirm the transaction. Under load, that conversation breaks in ugly ways: the shopper is charged but the order never lands in the ERP; the webhook retries against a timed-out endpoint and eventually gives up; the fulfilment feed to your 3PL falls behind. Reconciliation the next morning is often more expensive than the lost trading hours, and it is the part that finance remembers.

Who attacks shops, and why

Motive matters because it predicts timing. Ransom DDoS operators send a short demonstration burst of a few minutes, then an email demanding cryptocurrency with a deadline and a threat of something longer, and they time it for peak trading because that is when a retailer’s patience is thinnest. Competitor sabotage is harder to attribute and should be treated as an open question rather than an assumption, though the pattern of short attacks during flash sales is familiar to anyone who has run mitigation for consumer brands. Hacktivist targeting follows the news cycle and picks brands for what they represent. Retail has been in the firing line for years; the DDoS attack that took CafePress offline is an early example of the pattern that later became routine.

Attack, flash sale or bad crawler? Ten minutes to a working diagnosis

Genuine traffic converts. That single fact separates most incidents from most spikes.

If sessions triple while conversion rate collapses towards zero, and requests per session climb far above your normal browsing pattern, you are not looking at a successful email campaign. Check the source spread next: real UK retail traffic arrives from a wide mix of consumer ISPs and mobile carriers. Attack traffic tends to concentrate in a handful of autonomous system numbers (ASNs), often hosting providers or VPN ranges, and frequently in geographies you barely trade with.

Then read the machine evidence:

  • Origin CPU and database connections high while inbound bandwidth is unremarkable points to a Layer 7 flood, not a volumetric one.
  • Cache hit ratio falling off a cliff means requests are being crafted to miss cache, which is deliberate.
  • 502/504 patterns clustered on a small set of paths tell you which endpoints to protect first.

Misdiagnosis is common and costly. A scraper hammering product pages for price comparison looks like an attack until you notice it respects a single user agent and crawls in order. A runaway marketplace feed integration can generate the same load profile. So can an expired intermediate certificate, or a database lock from a bulk product import that someone kicked off at 09:00 without telling anyone. Rule those out before you escalate, because a provider who receives three false alarms will treat the fourth accordingly.

Whatever the verdict, capture evidence while it is still in the buffer: precise timestamps with time zone, sample log lines showing the offending requests, the target URLs, request rates per minute, and the spread of source IPs and ASNs. Weak attack reporting is how retailers end up unable to prove anything to a PSP, an insurer or a board committee six weeks later.

The first 60 minutes: a runbook for a shop that is down

Print this. Put it somewhere that does not depend on the website being up.

Minutes 0 to 10: confirm scope from outside your own network

  1. Test the site from a mobile connection off the office network, and from a second geography if you have a colleague or a VPS available.
  2. Test DNS resolution separately from HTTP. Query your authoritative nameservers directly. A shop that fails to resolve is a different incident from a shop that resolves and times out, and the two go to different teams.
  3. Open the ticket with severity wording your contract recognises. “Site slow”gets queued. “Production checkout unavailable, suspected volumetric or Layer 7 DDoS, revenue impacting, requesting mitigation engineer”does not.

Minutes 10 to 30: establish who is authorised to act

This is the moment retailers discover what they actually bought. A self-service plan gives you a dashboard, a rules engine and a support queue. If nobody on the provider’s side is empowered to change a mitigation profile at 03:00 without your written sign-off, you have bought monitoring, not management. Define this in the contract long before you need it: onboarding, tuning of Layer 7 rules against your specific checkout and search paths, named escalation numbers with out-of-hours cover, and explicitly who may apply mitigation on your behalf. Our guide to managed DDoS protection in the UK goes into the contractual detail; the short version is that “managed”is a marketing word until somebody writes down what it obliges them to do.

Minutes 30 to 60: tactical controls that buy time

In rough order of how much collateral damage they cause:

  • JavaScript or managed challenges on non-cacheable paths only (search, filters, login, cart), leaving product and category pages untouched.
  • Rate limits per IP and per session on the endpoints identified in your diagnosis. Set them against your real 95th percentile, not a guess.
  • A checkout queue, if your platform supports one. Slow is survivable. Broken is not.
  • Geo or ASN blocking as a blunt last resort, and only for ranges you genuinely do not sell to. Blocking a whole country during an incident is a trading decision, not a technical one.

In parallel, someone commercial needs to pause paid media (every pound spent driving traffic to a dead checkout is burned), update the status page and brief customer service with a line that does not invite speculation, and start logging downtime minute by minute for the loss calculation later.

Origin IP leakage: why the proxy quietly stops protecting your checkout

When a proxied site gets flattened, the cause is more often a leaked origin address than an attack too big to absorb. The attacker simply goes around the front door.

The usual leak paths on retail stacks are depressingly consistent: an old A record still pointing at the previous host; transactional email (order confirmations, dispatch notices) sent directly from the web server, exposing the origin in the mail headers; a staging or dev subdomain on the same box; cPanel, webmail and FTP hostnames; historic certificates recorded in public certificate transparency logs; and direct-to-origin API endpoints built for a mobile app, an EPOS integration or a marketplace channel because someone found the proxy inconvenient.

Closing it is unglamorous work:

  • Rotate the origin IP after going behind a proxy. If the old address is still live, the migration achieved nothing.
  • Allow-list only the provider’s published IP ranges at the host firewall, and drop everything else on ports 80 and 443.
  • Move outbound mail to a separate service or IP entirely.
  • Audit every subdomain, including the ones marketing created for a campaign in 2019.

Authoritative DNS deserves its own budget line

Treat DNS as a project, not a checkbox on the registrar’s control panel. Anycast delivery, redundancy across two independent providers, and a rehearsed time-to-live (TTL) plan so an emergency reroute propagates in minutes rather than a day. Drop TTLs to 300 seconds a week before peak trading and put them back afterwards. Rehearse the failover once, with the person who would actually be awake at 02:00 doing the typing.

Choosing protection that fits an online shop, and what it costs

Three deployment models are realistic for retailers. A reverse proxy or CDN in front of the shop is the default for anyone on Shopify Plus, WooCommerce or a hosted Magento, and it handles Layer 7 properly. BGP scrubbing suits retailers who own their address space and run their own infrastructure. Hosting-level filtering, bundled by the platform or by a DDoS protected hosting provider, is the cheapest option and usually the least tunable; it protects the shared estate first and your checkout second. The trade-offs are set out further in this comparison of how the main mitigation providers differ.

Always-on versus on-demand is a different sum for a shop than for a corporate website. An on-demand BGP diversion that takes several minutes to complete can span an entire checkout window at peak, and those are minutes of failed payments, not a slightly late intranet. Always-on proxying removes that delay, at the cost of making every payment redirect and PSP webhook dependent on that provider’s own availability. Neither answer is universally right. Pick deliberately, and know which one you chose.

Ask who owns the network behind the badge

A large share of UK ecommerce protection is resold. The terabits-per-second figure on the datasheet may belong to an upstream scrubbing network three companies away, and your escalation path may run through a reseller’s support desk before it reaches anyone who can change a mitigation profile. Ask directly: whose network, what capacity is contracted to you specifically, and how many hops sit between your phone call and the engineer.

Then ask for evidence rather than a deck. Request a redacted sample attack report and check whether it lists attack vectors, packet and request rates, target URLs and mitigation timestamps. A report you can hand to your PSP, your insurer or your board is part of what you are paying for. Testing vendor claims properly is a discipline of its own, covered in more depth in this piece on judging protection claims against real attacks.

Build the case on downtime cost, not gigabits

Finance directors do not fund gigabits. Take annual online revenue, divide by trading hours to get a baseline hourly figure, then apply a peak multiple for Black Friday week, when checkout volume runs at several times a normal day for most consumer brands. Add the paid media spend that would burn during the outage window and an honest estimate of the carts that never come back. That number, not the attack size, sets your budget.

UK managed deals typically price as a monthly commit tied to clean bandwidth or request volume, with overage charges above it, sometimes a per-attack or emergency onboarding fee, plus one-off setup and rule tuning. Annual contracts with a peak-season uplift clause are common. Check current pricing directly with providers; the shape is stable, the numbers are not.

A pre-peak checklist you can run in a week

Contract evidence. SLA definitions expressed in seconds to mitigate rather than “rapid response”; a redacted sample attack report; a named escalation path with out-of-hours cover and a phone number that reaches a human; a documented change freeze covering the trading peak.

Proof of value. Run a controlled load test through the proxy with the provider’s knowledge and written permission. Rehearse a DNS failover. Dry-run your rate limits on search and login against real traffic in log-only mode first, because a mistuned limit will block your own customers faster than any botnet.

Application hardening. Cache product and category pages aggressively. Put challenges in front of login, coupon and account-creation endpoints. Offload search to a dedicated service so a flood cannot reach the primary database. Decide in advance what a degraded-but-trading site looks like: static product pages, no faceted filtering, checkout still live.

Legal and reporting. Unauthorised denial of service falls under the Computer Misuse Act 1990, as amended by the Police and Justice Act 2006. Report attacks and any extortion attempt to Action Fraud and, for significant incidents, to the National Cyber Security Centre. Tell your PSP and your insurer early. A pure DDoS does not usually touch personal data, but if the flood turns out to be cover for an intrusion, UK GDPR breach notification timelines to the Information Commissioner’s Office start running.

And on the ransom question, the guidance from UK law enforcement and the NCSC has not changed: do not pay. Payment funds the next campaign, marks you as compliant to other groups, and buys no enforceable guarantee. Preserve the email headers and the attack logs instead.

Frequently Asked Questions

How can I tell if my ecommerce site is under a DDoS attack or just having a traffic spike?

Look at conversion rate against session volume. Genuine spikes convert at roughly normal rates; attack traffic sends sessions up while conversions fall towards zero, with abnormally high requests per session. Concentration in a few ASNs or hosting ranges, a collapsing cache hit ratio and errors clustered on non-cacheable paths such as search and cart confirm the picture.

What should I do in the first hour of an ecommerce site DDoS attack?

Confirm the outage from outside your network, test DNS resolution separately from HTTP, then open a ticket using severity wording your contract recognises. Apply challenges and rate limits to the affected non-cacheable endpoints, pause paid media, and capture timestamps, sample logs and source data while they are still available. Escalate to a named contact rather than a generic support address.

Can a DDoS attack steal customer or payment card data?

A denial of service attack floods capacity; on its own it does not exfiltrate data. The risk is that a flood is used as cover while an intruder works elsewhere, or that emergency changes such as disabling a firewall rule create an opening. Review authentication logs and any configuration changes made during the incident before you close it out.

Does Shopify, Magento or WooCommerce hosting already include DDoS protection?

Most platforms and hosts include some baseline network filtering, and fully hosted platforms carry more of it than self-managed stacks. Baseline filtering is aimed at volumetric floods across shared infrastructure, not at application-layer attacks tuned to your search and checkout paths. Ask your host what it actually mitigates, how quickly, and whether anyone will tune rules for your site specifically.

Should we ever pay a ransom demand attached to a DDoS attack?

No. UK guidance from law enforcement and the NCSC is consistently against payment; it funds further attacks, identifies you as a paying target and secures no enforceable promise that the attack stops. Preserve the demand with full email headers, report it to Action Fraud, and put your effort into mitigation and evidence.

How much does managed DDoS protection cost for a UK online retailer?

Pricing is usually structured as a monthly commit tied to clean bandwidth or request volume, with overage above that level, plus one-off onboarding and rule tuning; per-attack or emergency onboarding fees appear in some contracts, and annual deals often carry a peak-season uplift clause. Quotes vary widely by traffic profile and by how much human response is included, so compare on defined response times and named escalation, not headline capacity. Justify the spend against revenue per trading hour at peak rather than against attack size, because that is the number that decides whether an ecommerce site DDoS attack costs you an hour or a quarter.



DDOS Time to Mitigate: What SLA Seconds Really Mean (And How to Verify Them)

A head of IT signs a mitigation contract with a 60 second time-to-mitigate figure on the front page, files it, and thinks the problem is handled. Eight months later the checkout page stalls for a quarter of an hour on a Friday evening, the provider’s portal eventually logs the event as mitigated, and the post-incident review finds no breach of contract anywhere. Both things are true. Understanding why is the whole point of reading a DDoS time to mitigate clause properly, because the figure vendors publish almost never covers the part of the attack that actually hurt you.

Time to mitigate, in plain terms, is the interval between a distributed denial-of-service (DDoS) attack affecting your service and countermeasures bringing traffic back to something usable. That definition sounds tight. In practice, every provider draws the start and end lines in a different place, and the wording in the service level agreement (SLA) is where the difference lives.

What time to mitigate actually measures, and where the clock starts

An attack does not go from launch to blocked in one step. The chain runs roughly: the attack begins; telemetry (flow records, proxy logs, appliance counters) crosses a threshold; a detection alert fires; someone or something decides to act; traffic is diverted or filtered; routes converge and the return path carries clean traffic; and finally countermeasures are tuned to the specific vector, whether that is a UDP reflection flood or an HTTP GET flood against a search endpoint.

Most published figures cover the last stretch only. They measure the automated countermeasure stage, applied to traffic that is already inside the scrubbing path. Detection thresholds, human authorisation and Border Gateway Protocol (BGP) convergence on an on-demand service sit outside the measured window. A 60 second SLA and a fifteen minute outage coexist comfortably.

Two acronyms get quoted interchangeably and should not be. Mean time to detect (MTTD) is how long the provider’s systems take to notice. Mean time to mitigate (MTTM) is how long countermeasures take once triggered. Vendors quote whichever flatters the product: an always-on proxy vendor happily quotes near-zero mitigation time because traffic is already in path, while an on-demand scrubbing vendor prefers to talk about detection speed and stays quiet about diversion.

Three questions belong in writing before signature, not in a kick-off call afterwards:

  • Does the clock start at attack onset, at detection by the provider’s monitoring, or at the moment your named contact raises a ticket? The third option is common and is by far the weakest for you.
  • What counts as the finish line: first countermeasure applied, or measured service restoration against a defined availability target?
  • Who supplies the timestamps used to judge compliance, and are those timestamps from the provider’s own systems only?

Define your own finish line separately for internal reporting. Mitigation started is a vendor milestone. Checkout completing inside two seconds again is your milestone. Track both, because the gap between them is the number your board will ask about.

Always-on versus on-demand: the real trade-off

Always-on reverse proxy

Traffic already traverses the scrubbing estate, so for in-scope traffic mitigation is effectively immediate. Nothing has to be switched on. The costs are real though: added latency on every request, Transport Layer Security (TLS) termination at the provider (which means handing over private keys or using a provider-managed certificate), and a hard dependency on your origin addressing staying hidden.

On-demand BGP scrubbing

Here the diversion itself is the delay. An illustrative but realistic sequence: detection threshold breached at T+2 minutes, human authorisation obtained at T+5, the more-specific prefix announced at T+6, then global BGP convergence taking a few more minutes as peers accept the change. Clean traffic starts flowing well after the “five minute mitigation”figure on the datasheet, and none of it is a breach.

The second cost nobody times in a demo is the return path. Generic Routing Encapsulation (GRE) tunnels or cross-connects have to be built, tested and kept warm. A return path that has not been exercised in twelve months is where the real delay appears, usually accompanied by a maximum transmission unit (MTU) problem that only shows up under load.

Hosting-level filtering

Included platform protection is fast against volumetric floods, because the hosting provider is defending shared infrastructure and has every incentive to act. The mechanism matters. Many platforms “mitigate”by null-routing the targeted IP address at the edge, which protects the platform and every other tenant on it. From your seat it is indistinguishable from being taken offline. The contract language to hunt for is whether blackholing counts as mitigation for SLA purposes. If it does, the response time figure tells you almost nothing about your own availability.

Hybrid patterns

A common UK arrangement puts always-on proxy protection in front of the web estate and keeps on-demand BGP diversion in reserve for the wider prefix. Sound design. The handoff is where minutes leak away, because someone has to recognise that the attack has moved off the proxied hostnames and onto the network itself, then authorise a routing change. Rehearse that decision. Write down who makes it.

Three surfaces, three different clocks

Network and transport floods

Volumetric and protocol attacks (SYN floods, DNS and NTP reflection, carpet-bombing across a prefix) are high-volume and high-signal. Detection is straightforward, signatures are well understood, and automated countermeasures do most of the work. This is the surface the published time-to-mitigate figure was written for, and the one place it usually holds up.

Application layer

Low-rate HTTP floods are the awkward case. Consider an ecommerce checkout during peak trading, hit by a few thousand well-formed requests per second spread across residential proxies, each one hitting a database-heavy search or basket endpoint. Bandwidth looks normal. Volumetric thresholds never trigger. Mitigation depends on someone identifying a request signature (a header order, a JA3 fingerprint, a URL pattern, a behavioural anomaly against baseline) and writing a rule against it. That is a human timescale, and it is why the headline SLA rarely applies as advertised at layer 7. Ask specifically what the response commitment is for application-layer events, and whether it differs from the network figure. It nearly always does.

Authoritative DNS

Authoritative Domain Name System (DNS) service is the surface most commonly left outside the managed contract in UK buys. Buyers assume proxy protection covers name resolution. It does not, unless the contract says so. If your authoritative DNS sits with a separate registrar, an on-premises BIND pair, or a hosting control panel with no dedicated DNS DDoS attack protection, there is no time to mitigate at all. There is just an outage, and it takes every service down at once: web, mail, VPN, SaaS single sign-on, monitoring.

Options exist for organisations that cannot simply move zones to a large anycast platform. Akamai’s Shield NS53, for example, is designed to sit in front of on-premises and hybrid authoritative name servers rather than only the web tier. Whatever the choice, map every surface to a named owner, a named product and a named response time before anything goes wrong. Three columns on one page. If a row is blank, that is your next purchase order, and the same discipline applies whether you are comparing platforms or reading a vendor claim against how real attacks behave.

Why fast mitigation still fails: origin leakage and scope gaps

Origin IP leakage defeats a fast SLA more often than attack size does. Historical DNS records cached in passive DNS databases, mail servers sitting on the same range as the web origin, certificate transparency logs listing every hostname you have ever requested a certificate for, staging and legacy subdomains left unproxied, direct-connect API endpoints for partner integrations: any one of them hands an attacker a path straight to the origin.

When traffic reaches the origin directly, the provider’s clock never starts. Their proxy saw nothing. A sub-minute mitigation commitment on the proxy is worth precisely nothing in that scenario, and the provider is not in breach.

Other assets routinely fall outside scope entirely: VPN concentrators, SIP trunks and voice gateways, SMTP inbound, third-party APIs your application calls synchronously, and CDN origin pull addresses. Practical hardening is unglamorous and effective: firewall the origin so it accepts traffic only from the provider’s published address ranges, rotate origin addressing after onboarding so the pre-contract history is stale, and re-test scope after every migration, DNS change or new subdomain. The scope of protection drifts quietly. Attacks find the drift.

How to verify a time-to-mitigate claim before you sign

Datasheets are not evidence. Post-attack reports are. Ask for two or three real incident reports, redacted as needed, and read the timestamps rather than the headline scrubbing capacity in terabits per second. What you want to see: attack start, first alert, authorisation, first countermeasure, vector breakdown, and the point at which traffic profile returned to baseline. A provider who cannot produce that from real events, in a format you can read, is telling you something.

Then trace the resale chain. Whose network, whose scrubbing centres, whose engineers are on the clock at 03:00? A reseller cannot be faster than its upstream. Plenty of competent UK managed service providers sit on top of Akamai Prolexic, Cloudflare, Imperva or a carrier scrubbing platform, and that is a perfectly reasonable model, but it changes what the SLA means and where escalation actually goes. Asking is procurement hygiene, not an accusation. This site has covered the industry consolidation behind that pattern since Akamai’s acquisition of Prolexic.

Test the escalation path before you need it. A named out-of-hours contact, a phone number that a human answers, and a call drill during the trial period. Decide in advance who on your side is authorised to trigger diversion at 03:00, and what happens when that person is on a flight. Pre-authorisation for automatic diversion, within agreed limits, removes the single largest human delay in the chain.

Read the credit mechanics last and without optimism. Look at exclusions, the measurement window, whose data counts as evidence, and the claim deadline. A credit worth one month of fees rarely covers an hour of lost trading, and it is not a substitute for the technical controls. The credit is a footnote in a board pack. The outage is the meeting.

Turning minutes into money

Build the business case from cost per minute of downtime, not from vendor pricing. Transaction volume at peak multiplied by average order value, staff idle cost across the affected teams, contractual penalties you owe your own customers, and recovery effort including incident overtime and customer communications. Once that number exists, the price gap between an on-demand tier and an always-on tier usually resolves itself in one direction, and the conversation with finance gets shorter. Our guidance on managed DDoS protection in the UK, including what the tiers actually cost, sets out where those price bands typically sit, and the faster tier mostly buys the removal of the human authorisation step and the diversion delay, not better filtering.

Stakes vary by sector, and so should the design. An ecommerce checkout flood on Black Friday is a revenue event measured in minutes. Healthcare and public sector disruption is a service and reputational event with regulatory attention attached. A DNS outage is the worst case, because everything stops simultaneously and your status page is often unreachable too. Aviation offers a useful case study in interlinked dependencies, which the analysis of a DDoS attack against airline systems works through in more detail.

One attacker behaviour makes response speed strategic rather than merely operational. Ransom DDoS follows a pattern: a short demonstration burst of a few minutes against a public-facing site, then an email demand and a threat of something longer. A slow, visible first response tells the sender the target is worth returning to. Both the NCSC’s denial of service guidance for UK organisations and CISA’s joint guidance for defenders advise against paying and in favour of prepared, rehearsed response. Preparation is what makes the first response quiet.

The honest position on DDoS time to mitigate is this: treat the datasheet number as the vendor’s best case for the easiest surface, then spend your procurement effort on the parts it excludes. Where the clock starts, what happens to layer 7, who protects your authoritative DNS, and whether your origin is genuinely unreachable. Those four answers determine your real recovery time. The number on the front page does not.

Frequently Asked Questions

What is a good DDoS time to mitigate?

For network and transport-layer floods on an always-on service, effectively immediate is achievable because traffic is already in the filtering path, and commitments in the tens of seconds are common. For on-demand BGP diversion, anything under about ten minutes end to end including convergence is respectable. Layer 7 events are slower and should carry their own separate commitment. Judge the figure by what it includes, not by how small it is.

Does time to mitigate start when the attack begins or when it is detected?

That depends entirely on contract wording, and it is the single most valuable clause to negotiate. Many SLAs start the clock at detection by the provider’s systems, some at the point you open a ticket, and very few at attack onset. Get the definition in writing along with confirmation of whose timestamps are used to measure compliance.

Why is application layer DDoS mitigation slower than network layer mitigation?

Low-rate HTTP floods look like legitimate users. Bandwidth stays normal, so volumetric thresholds never fire, and separating attack requests from real traffic usually requires identifying a signature or behavioural pattern and writing a rule against it. Automated bot management helps, but the difficult cases still involve an engineer, which is a human timescale rather than a machine one.

How much slower is on-demand BGP scrubbing than always-on protection?

The gap is the sum of detection threshold, authorisation and route convergence. Working through a typical sequence, detection at a couple of minutes, human sign-off a few minutes later, then announcement and global BGP convergence, you are realistically looking at several minutes to low double digits before clean traffic flows. Always-on removes all of it for in-scope traffic. An untested GRE return path can add considerably more.

What evidence should I ask a provider for to check their mitigation times?

Redacted post-attack reports from real incidents with full timestamps, a written definition of clock start and finish, confirmation of whose scrubbing centres and network operations centre sit behind the badge, and a live out-of-hours call drill during the trial. Comparing that evidence across shortlisted suppliers, as set out in this guide to choosing between mitigation providers and their trade-offs, tells you more than any capacity figure.



DDoS Protection Service Comparison: How To Judge 6 Vendor Claims Against Real Attacks

Most buyers start a DDoS protection service comparison by asking vendors for a feature matrix, then discover that every matrix looks the same. Everyone claims multi-terabit capacity, sub-minute mitigation and layer 7 defence. The differences that decide whether your checkout stays up on a Friday afternoon are rarely in the datasheet at all: they sit in the protection model you buy, the assets that model can physically cover, and the contract clauses that govern what happens in hour 40 of a sustained attack.

This piece compares protection models rather than brand names, tests each model against attack patterns that have actually played out in the wild, and gives you a scoring framework you can run over a shortlist inside a week.

What you are actually comparing: five protection models, not five brands

Vendor names change ownership. Models do not. There are five ways DDoS traffic gets stopped before it reaches your infrastructure, and each has hard limits on what it can protect.

Always-on CDN or reverse proxy

Cloudflare, Fastly and Akamai sit in front of your web estate permanently. DNS points at their edge, they terminate TLS, they filter, and they forward clean requests to your origin. Strong for HTTP/S, strong for layer 7 rules and bot management, and mitigation is effectively instant because traffic never routes to you in the first place. The constraint is protocol: anything that is not web traffic needs a different answer, and your origin IP must be genuinely hidden for the model to hold.

On-demand or always-on BGP scrubbing

You advertise your own prefixes, and when an attack starts, routes are diverted to a scrubbing centre via BGP, with clean traffic returned over GRE tunnels or a dedicated connection. This protects entire /24s and everything inside them: mail, VPN concentrators, SIP and RTP for voice, game servers, database replication, odd-port APIs. The trade-offs are diversion time (minutes, not milliseconds, unless you run it always-on) and the requirement that you own routable address space and can influence BGP announcements.

On-premise appliance

A hardware or virtual appliance at your network edge, inspecting traffic with full visibility of your applications. Excellent for low-and-slow layer 7 detection and for state-based attacks, useless against a volumetric flood that saturates your upstream transit before packets ever reach the box. Appliances belong in hybrid designs, paired with cloud capacity that can be signalled when the pipe fills.

Hosting or data-centre level protection

Included filtering from your hosting provider, colocation facility or ISP. It is usually shared, usually tuned to protect the provider’s network rather than your specific application, and often carries a null-route policy: if your IP attracts enough traffic to threaten neighbours, it gets black-holed. That is protection for the data centre, not for you. Providers have been rolling out this tier for well over a decade, including data centre operators adding anti-DDoS as a standard facility service, and it has real value as a baseline. Treat it as a floor, not a ceiling.

DNS-layer defence

Authoritative DNS hosted on an anycast platform built to absorb query floods, or a hybrid arrangement that shields on-premise name servers behind a cloud tier (Akamai’s Shield NS53 is the reference implementation of that pattern). Ignored in most comparisons, and the fastest route to a total outage when it fails.

Mature setups are hybrids: proxy for web, scrubbing for the rest of the address space, hardened or dual-provider DNS, and an appliance where deep application visibility is needed. Managed DDoS protection in the UK is often delivered through this stack by an MSSP rather than direct, which is a model that has existed since vendors first built managed security service partner programmes around mitigation appliances. The partnership layer matters, because the party you phone at 3am may not be the party operating the scrubbing centre.

One check before you read any older comparison

The mitigation market has consolidated across generations. Prolexic’s scrubbing network now operates inside Akamai. IntruGuard’s technology was absorbed into Fortinet’s DDoS appliance line. Webscreen and netZentry were once fixtures on procurement shortlists and no longer exist as independent vendors. If you are working from a comparison written a few years ago, verify what the current entity actually operates today before you weight it.

The metrics vendors advertise, and the ones that decide your outcome

Advertised network capacity in Tbps tells you what the platform can absorb globally, across every customer, during the worst simultaneous event of the year. What matters to you is capacity and points of presence near your users. A 100Tbps global network with thin capacity in London and Manchester is worse for a UK retailer than a smaller network with dense European presence.

Time to mitigate is the metric most often quoted and most loosely defined. Ask what the clock measures. Detection? Route diversion complete? Or clean traffic restored to the customer? Ask whether mitigation is fully automated or requires a human in a NOC to approve a signature change, and what the escalation looks like at 02:00 on a bank holiday. An automated seconds-level response on a known attack vector is a different product from a 15-minute human-in-the-loop diversion, even when both appear in the same SLA table.

False positive rate is the metric nobody publishes. Aggressive challenge pages, JavaScript checks and CAPTCHA friction will protect your infrastructure and damage your conversion rate at the same time. During evaluation, ask for the tuning process: how quickly can a rule be relaxed, who can do it, and can you see the block decisions in your own logs?

Then separate the two attack classes properly. Layer 3/4 volumetric floods, reflection and amplification are a bandwidth and packets-per-second problem. Layer 7 request floods, credential stuffing and scraping are a request-economics problem, and they frequently sit inside your normal traffic envelope. A vendor scored purely on scrubbing capacity can win your comparison and still fail the incident.

Comparing providers against real attack patterns, not datasheets

DNS as the single point of failure

The clearest test in any comparison is what happens when the attack is not aimed at you. The October 2016 attacks on Dyn’s managed DNS infrastructure, driven by Mirai botnet traffic, took large numbers of unrelated customer sites offline simultaneously. Those sites were not attacked. Their web protection worked perfectly. They were unreachable because name resolution failed. Botnet-scale capacity of that kind has been a policy concern for years, with coordinated industry plans to reduce botnet activity running alongside enforcement work.

Which models survive it? An always-on proxy does not help if the DNS answering for your proxy hostname is down. Scrubbing does not help either. The only defences are DNS resilience by design: two independent authoritative DNS providers serving the same zone, or a hybrid arrangement shielding your own name servers behind cloud capacity. Put DNS resilience in the scoring grid as a weighted row, not a footnote.

Ransom DDoS with a deadline

The pattern is consistent: a 15 to 30 minute demonstration attack against a payment or checkout endpoint, followed by a note naming a cryptocurrency figure and a deadline measured in hours. Extortion has followed DDoS capability for as long as the technique has existed, and prosecutions do happen, as the jailing of Russian cyber-blackmailers who extorted UK bookmakers showed.

Now walk each model through that window. An existing always-on proxy needs a rule change and possibly a plan upgrade. Existing scrubbing needs a diversion request. If you have neither, you are onboarding a new provider under duress: DNS changes propagating against whatever TTL you set months ago, or a BGP announcement and tunnel build with an emergency onboarding fee attached. That is the moment long minimum terms get signed. Pre-agreeing an emergency onboarding path, with pricing, contacts and a tested runbook, costs far less than negotiating mid-attack. CISA, the FBI and MS-ISAC set out the reporting and non-payment position in their joint guidance, Understanding and Responding to Distributed Denial-of-Service Attacks (2024).

Hacktivist floods against public sector estates

In March 2024 the French Prime Minister’s office confirmed that multiple government websites had been hit by sustained DDoS attacks of what it described as unprecedented intensity, attributed publicly to hacktivist activity. Attention, not money, is the motive, which changes the profile: multiple targets across an estate, sustained over days, shifting vectors when one is blocked. Public sector buyers should test breadth of coverage across many small properties rather than depth on one flagship site, and should ask how billing behaves when 40 domains are simultaneously under load. Attackers pick symbolic targets, which is why even institutions with no commercial value get hit, as when a coordinated flood against the Vatican’s website failed to take it down.

Application-layer bot abuse on checkout and login

Credential stuffing against a login endpoint and inventory-hoarding bots on a checkout flow rarely register as bandwidth spikes. Requests are well-formed, come from residential proxy pools, and rotate user agents. Volumetric scrubbing will pass this traffic straight through. What stops it is bot management: device fingerprinting, behavioural scoring, rate limiting per credential rather than per IP, and the ability to serve a soft challenge to suspicious sessions without blocking genuine customers. Financial services have carried this load for years, from bank platforms knocked offline by flooding to the botnet operators behind the traffic being named and pursued.

Contract terms, pricing models and the clauses buyers regret

Pricing generally follows one of three shapes: pay-as-you-go clean bandwidth, flat-rate unmetered mitigation, or a committed tier with burst charges above it. Model the third one against a 72-hour attack before you sign. Ask explicitly whether overage is billed on clean traffic delivered to you or on total traffic absorbed, because the difference across three days of a large flood can be substantial.

Then read the definitions clause. What counts as an attack? Some agreements only trigger SLA obligations above a stated packets-per-second or bandwidth threshold, which conveniently excludes exactly the layer 7 events that hurt e-commerce. Check whether SLA remedies are service credits (a discount on a bill) or an actual time-to-mitigate commitment with a measurable start point.

Finally, run an asset coverage audit before you compare anything. List every internet-facing service: web, APIs on non-standard ports, SMTP and mail gateways, VPN and remote access, DNS, FTP or SFTP transfer endpoints, legacy IP ranges from acquisitions, staging and CI environments. Mark which model can protect each one. This is where most comparisons quietly fail, because the shortlist was built around web traffic and the estate is not.

A scoring framework you can run on a shortlist in a week

Weight the rows to your own risk, then score each shortlisted provider from 1 to 5. Suggested starting weights:

  • Asset inventory coverage (25%): percentage of your listed internet-facing services the provider can actually protect under the proposed design.
  • Layer 7 and bot handling (20%): rule granularity, bot scoring, rate limiting by credential or session, tuning turnaround.
  • Time to mitigate (15%): defined start point, automation level, out-of-hours escalation.
  • DNS resilience (10%): anycast authoritative DNS, secondary provider support, on-premise shielding options.
  • Reporting and forensics (10%): post-incident reports you can hand to a regulator or board, log export to your SIEM.
  • Escalation route (10%): named contacts, who can trigger mitigation at 3am, whether the MSSP or the platform owner answers.
  • Cost predictability under a 72-hour sustained attack (10%): modelled, in writing.

Demand proof rather than claims. Ask for an authorised load or attack simulation against a staging environment, with written permission from both parties. Ask for two reference calls in your own sector, not a logo wall. Ask for a redacted attack report from a real incident, which tells you more about reporting quality than any sample dashboard.

Sector weighting matters. Banks and payment operators should weight escalation and forensics higher, given operational resilience expectations. Healthcare and other essential service operators carry availability duties under the NIS Regulations, and availability sits inside the security obligations of UK GDPR. E-commerce should weight bot handling and cost predictability, with PCI DSS considerations for the checkout path. Legal firms usually weight confidentiality of traffic inspection and TLS key handling. For a broader view of the defensive options behind these scores, our overview of DDoS attacks and the possible solutions available covers the underlying techniques.

Migration and operational traps that neutralise good protection

The most common failure in this field is scope, not capacity. An organisation puts its web estate behind a proxy, leaves mail, VPN and an API on port 8443 outside it, and then finds the origin IP is still discoverable. Check DNS history archives, MX records that point straight at your network, certificate transparency logs (which publish every hostname you have ever requested a certificate for), and forgotten staging subdomains. Attackers query those sources first.

After cutover, lock the origin firewall to the provider’s published IP ranges. Skipping this step leaves a direct path around every control you just bought. Keep the outgoing provider live in parallel for a defined window, lower DNS TTLs well before the migration date so you can move quickly, and rehearse a failover during business hours rather than discovering the gaps during an incident.

Align the runbook with published guidance. The NCSC’s denial of service guidance collection covers preparation and response for UK organisations, and the CISA joint guide sets out reporting expectations. On the legal position, denial-of-service attacks are criminal offences in the UK under the Computer Misuse Act 1990, following the amendments made by the Police and Justice Act 2006 that put unauthorised acts impairing the operation of a computer beyond doubt. Report incidents; do not pay ransoms; and note that UK police forces have been building specialist e-crime capability for years, including dedicated regional e-crime units.

Run the comparison this way and it stops being a datasheet exercise. A useful DDoS protection service comparison ends with a scored grid tied to your own asset inventory, a modelled cost for a three-day attack, a tested emergency onboarding path, and DNS resilience treated as its own line item rather than an assumption.

Frequently Asked Questions

What should a DDoS protection service comparison actually measure?

Coverage of your real asset inventory first, then layer 7 and bot capability, defined time to mitigate, DNS resilience, reporting quality, escalation route and cost predictability during a long attack. Advertised network capacity in Tbps is a weak differentiator on its own, because it describes the platform’s global ceiling rather than what it will do for your specific traffic mix.

Is an always-on CDN proxy better than on-demand BGP scrubbing?

Neither is better in the abstract. A proxy gives near-instant mitigation and strong application-layer controls, but only for HTTP/S traffic, and only while your origin IP stays hidden. BGP scrubbing protects whole prefixes including mail, VPN, voice and non-standard ports, at the cost of diversion time unless you run it always-on. Most mature estates use both.

How much does managed DDoS protection cost in the UK?

Entry-level proxy plans are published openly by some vendors, while scrubbing and managed enterprise contracts are quoted case by case, so avoid budgeting from headline figures. The variables that move the price are protected bandwidth, number of protected prefixes or domains, always-on versus on-demand, bot management inclusion, and support tier. Ask every bidder to price the same 72-hour attack scenario so the quotes are comparable.

Does my hosting provider’s included DDoS protection count as enough?

It is a reasonable baseline against commodity floods, but it is usually shared, tuned to protect the provider’s network, and may include a null-route policy that black-holes your IP to protect other tenants. Check the terms for that clause specifically, and check whether it covers application-layer attacks at all.

How do I protect DNS as well as my website?

Use an anycast authoritative DNS platform built for query floods, and consider running two independent DNS providers for the same zone so a single provider outage does not remove you from the internet. If you must keep name servers on-premise, use a shielding tier in front of them, the pattern Akamai implements with Shield NS53.

What time-to-mitigate SLA is realistic to ask for?

For always-on proxy or always-on scrubbing, mitigation of known vectors should be effectively automatic and measured in seconds. For on-demand BGP diversion, a few minutes from detection to clean traffic restored is a reasonable ask, provided the contract defines which of those two events starts the clock and what the out-of-hours escalation looks like.

Can I test a provider’s mitigation before I sign?

Yes, with written authorisation from both parties and a booked window, usually against a staging environment or a dedicated test prefix. Unauthorised testing against infrastructure you do not control is an offence under the Computer Misuse Act 1990, so keep the scope, permissions and timings documented before anything is generated.



Best DDoS Mitigation Providers: How to Choose (With Trade-Offs)

Shortlists of the best DDoS mitigation providers tend to rank vendors by brand recognition and advertised scrubbing capacity. Incident archives rank them differently. What decides whether an organisation stays online is narrower and less glamorous: whether authoritative DNS was covered, whether the old origin IP was still reachable after the proxy migration, whether anyone answered the phone within the first ten minutes, and whether the layer 7 rules blocked the botnet without blocking the checkout.

This guide works backwards from the attack patterns that actually cause outages, then maps each one to what a provider has to demonstrate before it belongs on a shortlist. It also covers the vendor landscape as it really is: a set of acquisitions rather than a fresh market, which matters more during procurement than most buyers expect.

What actually separates DDoS mitigation providers

Advertised capacity versus usable capacity near your users

Headline figures for network capacity describe the sum of a vendor’s edge, not the capacity of the point of presence that will absorb an attack aimed at your users in London, Manchester or Dublin. A platform with enormous global capacity but thin UK and Western European peering can still deliver added latency on clean traffic and slower convergence during a diversion. Ask for the PoP and peering list for the geographies your traffic actually comes from, and for the second and third nearest sites, because that is where traffic lands when the nearest one is saturated or under maintenance.

Always-on proxy, BGP diversion or DNS redirection

Three deployment models dominate, and each has a different realistic time to mitigate.

  • Always-on reverse proxy. HTTP and HTTPS traffic passes through the provider permanently. Mitigation starts in seconds because there is nothing to switch. The trade-off is that every request depends on the proxy, and TLS termination sits with a third party.
  • BGP on-demand diversion. The provider announces your prefixes and pulls traffic into scrubbing centres, then returns clean traffic by GRE tunnel or private interconnect. Suitable for whole /24s and non-HTTP services. Realistic activation covers detection, decision, announcement and BGP convergence, so the honest number is minutes, not seconds, unless the announcement is permanent.
  • DNS redirection. Records are repointed to the provider. Speed is governed by your TTLs and by resolver behaviour, and some resolvers ignore short TTLs. Anyone relying on this model should already be running low TTLs as standing configuration.

Volumetric floods versus application-layer floods

Layer 3 and 4 volumetric attacks are the ones that generate the headline numbers. Layer 7 floods are the ones that quietly take e-commerce and portal estates offline. A distributed bot network sending well-formed requests to search, login or basket endpoints does not need much bandwidth to hurt. An origin sized for roughly 500 requests per second can be exhausted by a few thousand requests per second against expensive database-backed endpoints, at a traffic volume that never crosses a volumetric detection threshold. That arithmetic is why per-endpoint rate limiting and bot management matter more than terabit claims for most web estates.

Who runs the mitigation on the night

Three operating models exist: your team drives the console, the vendor’s security operations centre drives it under a managed service, or a partner MSP drives it on your behalf. Self-service is cheaper and worse at 03:00 on a bank holiday. Managed services cost more and need clear authority to act without waiting for a change approval. Decide which model you are buying before you compare prices, because the same platform sold three ways produces three very different incidents.

Map your attack surface before you shortlist

Everything with a public address, not just the website

The inventory that matters includes the public web estate, APIs and mobile back ends, authoritative DNS, VPN concentrators, mail gateways, and anything else with a routable address. Origin exposure is where most proxy-based deployments quietly fail. Teams move DNS behind an anycast provider and leave the previous origin IP reachable, still visible in historic DNS records, mail headers, certificate transparency logs or a forgotten staging hostname. Attackers look there first.

Treat origin lock as a hard requirement rather than optional hardening. Ask exactly how the provider enforces it: IP allow-lists at the edge firewall permitting only the provider’s ranges, authenticated pull between edge and origin, or private interconnect. Then verify it from outside your network, not from the change ticket.

Sector patterns

Attack motivation shapes the pattern. Financial services see credential-stuffing and layer 7 floods aimed at login and payment paths, sometimes as cover for fraud, as in incidents like the DDoS disruption at National Australia Bank. Airlines and travel platforms carry expensive search endpoints that make cheap layer 7 attacks effective, which is why carriers have invested heavily in automated defences at the edge. Public sector estates fail collectively: the March 2024 disruption of French government services, which officials described as an attack of unusual intensity, showed how dozens of domains sharing DNS and hosting go dark together, and how hacktivist campaigns arrive in waves around political events. Healthcare and law firms tend to be hit for extortion or reputational leverage rather than volume records.

Hosting and data centre protection, and the blackholing clause

For many organisations the real first line is the hosting provider’s upstream filtering, and plenty of providers do invest properly in it, as with the anti-DDoS platforms rolled out by regional data centre operators. The problem sits in the acceptable use policy. Under attack, many providers will null-route the targeted IP to protect other tenants. That counts as mitigation for the provider and as a total outage for the customer. Read the clause, get the threshold in writing, and know whether an escalation path exists to filtering rather than blackholing.

Price the downtime first

Budget follows the cost of an hour offline, and so does the acceptable failure mode. An estate where an hour costs six figures should buy always-on protection with a managed SOC and separate DNS coverage. A brochure site can accept DNS redirection and a slower clock. Working out that number before vendor calls stops the conversation being driven by whichever feature the account manager is targeted on.

The main DDoS mitigation providers and where each one fits

One point worth carrying into every vendor call: this is a market built from acquisitions. Prolexic, founded in 2003, has sat inside Akamai since 2014. Earlier appliance and scrubbing names from the previous generation, including netZentry, Webscreen and IntruGuard (whose DDoS technology went to Fortinet), were absorbed into larger vendor and carrier portfolios years ago. A “proven since 2003″claim may describe technology that has changed hands and architecture more than once. Ask which platform your traffic will traverse today, in which data centres, and under whose engineering roadmap.

Global anycast CDN and reverse proxy platforms

Cloudflare, Akamai and Fastly all operate large anycast networks that terminate HTTP and HTTPS at the edge, with WAF, rate limiting and caching alongside DDoS filtering. For web and API-heavy estates this is the strongest default: mitigation is always on, layer 7 controls sit where the traffic arrives, and caching absorbs a large share of junk requests. The limits are equally clear. Proxy platforms protect what resolves through them, so non-HTTP services, mail and VPN need separate cover, and origin lock has to be enforced rather than assumed.

Routed network-level protection for whole prefixes

Akamai Prolexic and equivalent scrubbing services from carriers and specialists protect entire /24 announcements, including non-HTTP protocols, on-prem data centres and colocation footprints. This is the right choice where the estate is not simply a website: SIP trunks, game servers, financial market connectivity, industrial protocols. Two questions decide quality here. First, is the announcement always on or on demand, and what is the measured convergence time. Second, how is clean traffic returned, and what happens to that return path when it is itself attacked.

DNS protection as its own line item

DNS remains the most under-bought layer in the stack. An attack on authoritative nameservers takes out every service behind them at once, however well the web tier is defended. Organisations that hand DNS to a managed anycast provider inherit that provider’s capacity. Those keeping their own authoritative nameservers, often for internal integration or compliance reasons, need dedicated cover in front of them. Akamai Shield NS53 exists for exactly that case, sitting in front of on-prem and hybrid authoritative DNS, and competing providers offer similar hybrid arrangements. If DNS does not appear as a separate item on the quote, it is probably not protected.

Bot management, bundled or licensed separately

Automated layer 7 abuse sits at the boundary between DDoS, scraping and credential stuffing, and vendors increasingly sell it separately. Fastly Bot Management and its peers apply behavioural scoring, fingerprinting and challenge logic that generic WAF rules miss. For retail, ticketing and any estate with a login wall, this is usually the difference between staying up and staying up profitably. Establish early whether it is included in the platform price or licensed on request volume, because the second model changes the total cost under attack. Botnet supply itself has been a policy target for years, from industry takedown initiatives to named prosecutions, but attackers rebuild capacity faster than it is removed.

ISP, transit, protected hosting and managed DDoS protection in the UK

Buying through a transit provider, a DDoS-protected host or a UK managed security partner suits organisations without a 24/7 network team. Filtering happens upstream before congestion reaches the access circuit, and the partner holds the runbook. The channel model behind this is long established: DDoS vendors have offered managed security service partner programmes for well over a decade, including the early appliance-based MSSP schemes that shaped today’s managed offerings. Weaknesses to test: whether the partner can act without your sign-off, whether their SOC covers UK out-of-hours properly, and whether they simply resell a platform they cannot tune. A broader view of the defensive options, including on-premises and hybrid designs, is set out in this rundown of DDoS attacks and the available solutions.

Comparing providers on the things that break during a real attack

Time-to-mitigate SLAs. Most are measured from vendor detection, not from the moment your users stop being able to load the site. Get the measurement start point in writing, along with the out-of-hours escalation clock and who is authorised to declare an incident. Then check the credit: it is often a fraction of one month’s fee, which is not a remedy, it is an apology. Ask for the distribution of mitigation times across recent incidents rather than a headline average, because the tail is what hurts.

False positives. The first journeys to break under aggressive rules are checkout, login and password reset, precisely the ones that generate revenue and support tickets. Ask how the provider tunes for logged-in traffic, how quickly a rule can be relaxed mid-incident, and who has authority to do it at 2am.

Challenges and accessibility. JavaScript challenges and CAPTCHA reduce automated load but also block screen readers, older clients, legitimate API consumers and price-comparison partners. Public sector buyers with accessibility obligations should test challenge pages against assistive technology before go-live, not after a complaint.

The first 30 minutes. Named contacts, a phone number that is answered, a shared channel that does not depend on your own mail domain, and an agreed authority to act. Vendors that only offer a ticket queue at silver tier are fine for a brochure site and unacceptable for a payment platform.

Contract shape. Watch burst pricing, clean-traffic overage, attack-time surcharges, per-request bot management fees and 12 to 36 month lock-ins. Insist on knowing what an unusually large attack costs, because a bill arriving after an incident is a poor way to discover the pricing model.

Procurement questions and a proof-of-value test plan

Twelve questions that separate capability from marketing:

  1. Which PoPs will serve our UK and EU users, and who do you peer with there?
  2. Is protection always on, BGP on demand or DNS-based, and what is the measured activation time for each?
  3. What exactly is in scope for DNS: managed authoritative, hybrid, or nothing?
  4. How is origin lock enforced and verified after go-live?
  5. Is bot management included or licensed separately, and on what metric?
  6. From what event does the time-to-mitigate clock start, and what is the credit?
  7. Show the distribution of mitigation times over the last 12 months, not the average.
  8. Who runs mitigation out of hours, from which location, and under what delegated authority?
  9. What is the policy on null-routing our addresses, and at what threshold?
  10. Which platform will our traffic traverse, and what is its acquisition history?
  11. What are burst, overage and attack-time charges in cash terms?
  12. Can you provide two references in our sector at a similar traffic profile?

Ask for anonymised incident reports rather than case-study prose. A report showing detection time, mitigation time, rule changes and residual impact tells you more than any capacity figure. Then run a controlled proof of value: staged failover into the mitigation path during a low-traffic window, a runbook rehearsal with the people who will actually be on call, synthetic load against a non-production endpoint if the provider permits it, and a documented, tested rollback. If a vendor will not support a rehearsal, that answer is itself the result.

Getting value from the provider you choose

The runbook is the deliverable that matters. Switchover steps agreed in advance, standing low TTLs on the records you may need to move, credentials held outside the affected estate, and an out-of-band communications channel so nobody is trying to edit DNS through a saturated VPN. CISA, the FBI and MS-ISAC set out the same fundamentals in their joint guidance on understanding and responding to distributed denial-of-service attacks (October 2024): baseline normal traffic so anomalies are visible, layer defences, and rehearse the response. Baselining is the step most often skipped, and without it nobody can tell whether 3,000 requests per second is an attack or a marketing email.

Ransom DDoS: the response order

The pattern is consistent. A short demonstration attack, often aimed at a checkout or login path so the impact is unmistakable. Then an extortion email with a payment deadline in cryptocurrency. Then a larger follow-up if the deadline passes. Payment rarely ends it, because a paying target is a proven target and the same group, or another using its name, tends to return.

The order that works: preserve logs, packet captures and the full email headers of the demand; notify the mitigation provider’s SOC and confirm rules are tightened on the endpoints hit in the demonstration; brief the executive and communications teams with a holding statement; report to Action Fraud and, for organisations in scope, to the NCSC; do not pay. Extortion campaigns are prosecuted, and have been for two decades, including custodial sentences for cyber-blackmail gangs that attacked online businesses. In the UK, denial-of-service attacks fall within the Computer Misuse Act 1990 as amended by the Police and Justice Act 2006, which put attacks that impair the operation of a computer clearly inside the criminal law.

Quarterly reviews

Attack logs, false positive reports, rule tuning and a re-test after every significant change to the estate: new domain, new API, new payment provider, new data centre. Most protection gaps found during incidents were created months earlier by a routine change that nobody put through the mitigation review. A short quarterly session with the provider’s engineers, not just the account manager, catches them.

Choosing among the best DDoS mitigation providers comes down to matching deployment model, layer 7 capability, DNS scope and support behaviour to the way your own estate fails, then proving it with a rehearsal rather than a data sheet. Further background on attack techniques and defensive options is collected across DDoSInfo’s archive of DDoS incidents and vendor coverage.

Frequently Asked Questions

Who are the best DDoS mitigation providers for UK businesses?

For web and API estates, the global anycast platforms (Cloudflare, Akamai and Fastly) are the usual shortlist because mitigation is always on at the edge. For whole prefixes, non-HTTP services and on-prem data centres, routed scrubbing such as Akamai Prolexic or a carrier equivalent fits better. Organisations without a 24/7 network team often get more from managed DDoS protection bought through a UK partner or protected host than from buying a platform direct.

What is the difference between always-on and on-demand DDoS mitigation?

Always-on means all traffic passes through the provider permanently, so filtering begins immediately and there is nothing to activate. On-demand means traffic is diverted only when an attack is detected, usually via BGP or DNS changes, which is cheaper but adds detection, decision and convergence time. On-demand can be entirely adequate if the acceptable outage window is measured in minutes, not seconds.

How much does DDoS mitigation cost, and what drives the price up?

Pricing varies too widely across estate size and deployment model for a single figure to be useful, so treat published list prices as a starting point only. The main cost drivers are clean traffic volume, number of protected prefixes or hostnames, whether bot management is licensed separately, managed SOC coverage, and burst or attack-time terms. Always ask what an unusually large attack costs under the contract before signing.

Do I still need DDoS protection if my hosting provider says it is included?

Read the acceptable use policy first. Many hosts protect the platform rather than the individual tenant, and will null-route an attacked IP address to keep other customers online, which is a complete outage for you. Included protection is genuinely useful for volumetric floods, but rarely covers application-layer attacks or your authoritative DNS.

How is DNS DDoS protection different from protecting a website?

Web protection filters HTTP and HTTPS requests at a proxy; DNS protection defends the authoritative nameservers that tell the world where your services live. If DNS goes down, everything behind it becomes unreachable regardless of how well the web tier is defended. Anyone running their own authoritative nameservers should price DNS mitigation separately, for example a hybrid service such as Akamai Shield NS53 sitting in front of on-prem DNS.

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

Preserve the demand with full email headers, along with logs and captures from any demonstration attack, then alert your mitigation provider’s SOC and tighten controls on the endpoints that were targeted. Report it to Action Fraud, and to the NCSC if your organisation is in scope. Do not pay: it marks you as a paying target and rarely ends the campaign.

Is a CDN with WAF enough, or do I need separate bot management?

A CDN with a tuned WAF handles volumetric floods and known exploit patterns well. It is weaker against distributed bot traffic that sends well-formed, individually plausible requests to expensive endpoints, which is how many application-layer outages happen. Estates with logins, search, basket or ticketing flows generally need dedicated bot management alongside the WAF, plus per-endpoint rate limits.


DDoS Attack on an Airline: How Aviation Systems Fail and What Actually Protects Them

A distributed denial-of-service (DDoS) attack on an airline almost never looks like the film version. There is no cockpit, no radar screen, no dramatic countdown: there is a booking domain that stops resolving at 06:00 on a Friday in half-term, a mobile app stuck on the boarding pass screen, and a bag drop queue growing faster than the ground handler can clear it. The statement that follows will say flight operations and air traffic control were unaffected. That is usually true. It is also close to useless to the passenger in the queue and to the duty manager paying for the welfare costs.

This piece takes the airline apart into the internet-facing surfaces that actually fail during an attack, explains what mitigation genuinely covers each one, and sets out how to test a provider’s claims before peak season rather than during it.

What actually goes down when an airline is hit

The marketing site is not the system that matters

A mid-sized carrier’s internet-facing estate is a longer list than most board packs assume: the marketing site; the booking engine and fare search; check-in and boarding-pass APIs; the mobile app back end; self-service kiosk endpoints in the terminal; ground-handler and crew portals; the loyalty programme; payment gateway callbacks; and authoritative DNS for the primary booking domain. Each has a different traffic profile, a different owner and, usually, a different level of protection.

Attackers do not need to touch reservation host connectivity or departure control to cause a bad morning. Flooding the check-in API is enough. The kiosks in the terminal are, in most estates, HTTPS clients talking to the same endpoints as the app, so when those endpoints saturate, the kiosks fail alongside the phones.

Why “no impact on flight operations”can be true and unhelpful

The dividing line is simple. Safety-critical avionics, air traffic management and the systems the regulator cares about most sit on separate networks with their own connectivity and their own assurance regime. The passenger-facing estate is ordinary internet infrastructure with ordinary internet weaknesses: public IP ranges, DNS, TLS, cloud load balancers, third-party JavaScript. A carrier can say with complete honesty that no aircraft was affected while every passenger channel is unusable.

Communications teams that lean too hard on the first half of that sentence tend to get punished for it later, because the queue is visible on social media within minutes.

The operational bill after the traffic stops

Manual check-in at the desk is slower than the kiosk by a wide margin, and staffing is set months in advance. A morning of degraded check-in produces missed slots, misconnects, rebooking backlogs, contact-centre queues that persist for days, and welfare costs for passengers stranded at the airport. Under retained UK air passenger rights rules (Regulation (EC) No 261/2004 as retained in UK law), duties of care and rebooking apply where flights are delayed or cancelled regardless of what caused the disruption; whether cash compensation is also payable turns on the contested question of whether a cyber attack counts as an extraordinary circumstance. That is a legal argument you would rather not be having.

Attackers pick the calendar, not just the target

Short, repeated bursts timed to a bank holiday getaway, a half-term Friday, a strike day or a political flashpoint do more damage per gigabit than a sustained flood on a quiet Tuesday. European carriers including Lufthansa and Scandinavian Airlines have had public-facing services disrupted by campaigns claimed by hacktivist groups on Telegram, typically announced alongside a political grievance and typically in bursts rather than one long wave. The pattern matters for defence: on-demand mitigation that takes several minutes to engage will keep missing an attack that only lasts fifteen.

Why airlines attract DDoS attacks in the first place

Hacktivist DDoS attack motives: the carrier as a stand-in for the state

Flag-of-convenience targeting is the dominant pattern. A group with a grievance against a government cannot reach the government’s hardened estate, so it hits the most recognisable commercial entity carrying the flag. National carriers, airports and rail operators are chosen because the outage is visible, photographable and reported within the hour. Attribution claims made on Telegram should be treated as claims, not facts; groups routinely take credit for outages they did not cause, and for outages that were never attacks at all. Airlines have been dealing with attention from this direction for years, and some carriers have publicly invested in defences specifically to blunt it.

Extortion, and why paying rarely ends the pressure

Ransom DDoS notes are usually timed to a peak booking window: a fare sale, the January holiday rush, the run-up to a bank holiday. The note arrives with a short demonstration attack and a deadline. If you are asking what to do when a ransom DDoS demand lands, the practical answer is a sequence, not a decision: do not reply; preserve the message headers and any demonstration attack telemetry; escalate to your mitigation provider immediately so posture can be raised before the deadline; inform your legal and communications leads; and report it. Payment funds the next campaign, marks you as a payer, and buys no enforceable commitment from an anonymous counterparty. Extortion crews are occasionally caught and prosecuted, as earlier cases against Russian DDoS blackmailers showed, but not on a timescale that helps you this week.

In the UK, section 3 of the Computer Misuse Act 1990 covers unauthorised acts intended to impair the operation of a computer, carrying a maximum sentence of ten years on indictment. Reporting routes run through Action Fraud (or Police Scotland in Scotland) and the National Cyber Security Centre. Air transport operators should also check their notification duties under the Network and Information Systems Regulations 2018, where the Civil Aviation Authority is the competent authority for the sector; confirm current thresholds and timescales with the CAA rather than relying on institutional memory.

Cheap capacity and cover noise

Booter and stresser services have made short bursts a commodity purchase, and reflected amplification plus large compromised device populations mean a low-budget attacker can still generate serious volume; the days when botnets of that scale were remarkable are behind us. The second use case is quieter: a loud layer 3 flood occupies the security operations centre and the network team while credential stuffing runs against the loyalty programme or a supplier account is abused elsewhere. Treat a volumetric event as a possible distraction and keep someone watching authentication logs.

The three surfaces an airline protects unevenly

Network and transport

Volumetric floods against the autonomous system, the data centre edge and any self-hosted range are the best-understood problem and generally the best-covered. Upstream scrubbing, BGP diversion and blackholing all exist for it. The gap is usually scope: subsidiaries, regional franchise partners and legacy ranges left in an old colocation facility often sit outside the contract.

Application layer

Layer 7 is where airlines are structurally exposed, because fare search is expensive. A single availability query can fan out to a pricing engine, cache lookups and, in some architectures, a live call to a global distribution system. A few thousand requests per second against fare search costs an attacker almost nothing and costs the origin a great deal. Seat maps, loyalty login and the booking basket behave the same way. Static content, by contrast, is nearly free to serve.

Airline traffic is also genuinely spiky. A fare sale, a snow day or a strike announcement produces surges that look exactly like a request flood. Thresholds tuned to average load will either throttle paying customers during a promotion or miss a slow, low-rate flood on fare search. Per-endpoint tuning is the answer: aggressive limits and bot challenges on the expensive endpoints, generous handling of static assets, and rules that account for the app’s normal burst behaviour after a disruption push notification.

Authoritative DNS

This is the layer most commonly left outside the managed scope, and the one that takes down every channel at once. If authoritative DNS for the booking domain stops answering, the website, the mobile app, the kiosks, the ground-handler portal and any partner integration resolving that hostname fail together, and no amount of edge bandwidth in front of the web tier helps. Serious DNS DDoS attack protection means anycast authoritative service across two independent providers on separate infrastructure, zone data kept in sync, TTLs agreed in advance (short enough to fail over usefully, long enough that resolvers keep serving during an outage), and a rehearsed procedure for changing delegation under pressure. For most carriers that buys more resilience than another tier of scrubbing capacity.

The third parties in the chain

Your booking flow depends on things you do not own: GDS connectivity, payment service providers, ancillary retail platforms, identity providers, and the airport operator’s own systems for kiosks and bag drop. Ask each of them the same questions you ask your own team, and record which of them can take your check-in flow down without anyone attacking you at all.

Why the proxy did not save the booking engine

Origin IP leakage, not attack volume

When a proxied booking engine falls over, the cause is more often exposure than size. The usual suspects: an old A record for a staging booking engine still pointing at production infrastructure; an SMTP or webmail host in the same /24 as the origin; a certificate transparency log entry publishing an internal hostname that resolves straight through; a historical DNS record archived by passive DNS services years ago. Fix the leak and enforce an origin firewall allowlist that accepts traffic only from your mitigation provider’s published ranges. Then test the allowlist from an arbitrary external host, because plenty of them are configured and never enforced.

APIs routed around the edge for latency

Mobile and API traffic is frequently taken off the proxy deliberately, to shave latency off check-in calls or because the SDK does not tolerate the edge’s TLS behaviour. That decision is often made by an app team, documented nowhere, and discovered during an attack when api.example.com is flooded directly while www.example.com stays comfortably up. Inventory every hostname the app resolves, including the ones used only for feature flags, crash reporting and payments.

Deployment models and mitigation timing across an airline estate

Three models cover most estates: reverse proxy for web and API surfaces, where layer 7 inspection and per-endpoint policy live; BGP-based scrubbing for whole prefixes, which protects everything in the range including non-HTTP services; and hosting-level filtering, which is often the realistic option for a smaller regional carrier or a subsidiary running one booking site.

Always-on versus on-demand

On-demand diversion is cheaper and keeps normal traffic off the scrubbing path, but the first minutes are exactly the ones that matter during a 06:00 check-in peak, and detection thresholds plus BGP convergence mean an on-demand posture will surrender the opening of every burst. The defensible split for an airline is always-on protection for the booking, check-in and DNS path, with on-demand diversion held in reserve for less critical prefixes. Get the SLA to state whether time-to-mitigate is measured from detection or from your phone call, because the two numbers can differ by half an hour.

Whose network have you actually bought?

Many buyers cannot name the network their traffic is scrubbed on, because the contract is with a reseller or an integrator. Ask for the underlying provider, the scrubbing locations that will serve your UK and European traffic specifically, and how advertised capacity is measured. The market has consolidated steadily since deals such as Akamai’s acquisition of Prolexic, and a cloud DDoS scrubbing service sold under three different brands may all terminate in the same handful of facilities. That is not automatically a problem. Not knowing is.

The 05:30 Friday runbook

Write the runbook for the worst realistic hour, not for office hours. Name the person authorised to trigger diversion or change DNS without waiting for a change advisory board. Record the provider’s out-of-hours escalation number and the account credentials needed to raise it. Decide in advance how ground operations is told, what the desk agents are instructed to say, and which fallback the airports switch to. Rehearse the DNS provider failure separately, because it is the scenario where your usual comms channels (the website, the app status page) may also be gone.

Buying and proving protection before peak season

What “managed”should buy

Managed should mean onboarding and per-endpoint rule tuning, always-on baselining of your traffic including its seasonal shape, named escalation contacts on both sides, and an engineer empowered to change policy at 03:00 without your sign-off. If every mitigation change waits on a ticket you have to raise, you have bought monitoring, not management. Our own guide to choosing a managed DDoS protection provider in the UK covers the contract mechanics and cost ranges in more detail; the aviation-specific addition is that your tuning must survive a fare sale.

Evidence over sales decks

Ask for a redacted post-attack report from a comparable customer and read it for vector breakdown, timestamps, mitigation actions taken and residual leakage, not for the headline peak figure. Ask how capacity is measured and where. Then, after your first real event, check the report against the SLA definitions you signed. Providers that write good reports tend to run good operations.

The business case, priced properly

Model downtime cost per hour against each surface rather than against “the website”: lost online bookings and ancillary revenue; contact-centre surge and overtime; desk staffing for manual check-in; welfare, rebooking and potential compensation exposure under the retained UK261 rules; and the cost of the recovery days that follow. Present the DNS single point of failure separately, because it is the cheapest of the risks to fix and the most expensive to ignore.

A pre-peak test checklist

  1. Search historical and passive DNS records, certificate transparency logs and mail records for anything that exposes an origin IP address; retire what you find.
  2. Confirm the origin firewall accepts traffic only from your mitigation provider’s ranges, and prove it by connecting from outside them.
  3. Verify that both authoritative DNS providers answer for the zone, that records match, and that TTLs are set where your failover plan assumes they are.
  4. Enumerate every hostname the mobile app and the kiosks resolve, and confirm which are behind the edge.
  5. Run a tabletop where the attack lands at 05:30 on a Friday in half-term, with the DNS provider unreachable and the on-call network lead unavailable.

A DDoS attack on an airline is not an unforeseeable lightning bolt from the blue. It is a predictable consequence of running a highly visible, latency-sensitive, seasonally spiky passenger estate on the public internet, and the carriers that come through one well are the ones that mapped every surface, closed the origin leaks and tested the DNS failover in March rather than in August.

Frequently Asked Questions

Can a DDoS attack on an airline affect flight safety or air traffic control?

Safety-critical avionics and air traffic management run on separate, dedicated networks that are not exposed to public internet traffic in the way a booking site is, so a flood aimed at passenger channels does not reach them. What it does reach is check-in, bag drop, kiosks and rebooking, which can ground a schedule through operational congestion rather than through any safety system failure. Both statements can be true at the same time.

Why do hacktivist groups target airlines with DDoS attacks?

Visibility. A national carrier is a recognisable stand-in for the government whose flag it carries, and an outage during a getaway weekend produces photographs of queues within the hour. Campaigns claimed by hacktivist groups on Telegram against European carriers, including Lufthansa and Scandinavian Airlines, have followed political events. Claims of responsibility should be treated as unverified until the telemetry supports them.

How long does an airline website usually stay down during a DDoS attack?

There is no reliable average, and any vendor quoting one should be asked for the dataset. The pattern seen in hacktivist campaigns tends towards repeated short bursts over hours or a day rather than one continuous outage, which is why time-to-mitigate matters more than total capacity. Recovery of the passenger experience takes longer than recovery of the website, because the rebooking and contact-centre backlog persists after traffic normalises.

What should an airline do if it receives a ransom DDoS demand before a bank holiday?

Do not respond to the sender, preserve the note and any telemetry from the demonstration attack, and tell your mitigation provider immediately so posture can be raised before the stated deadline. Brief legal, communications and ground operations, and report through Action Fraud (or Police Scotland) and the NCSC, checking any sector notification duties with the CAA. Paying identifies you as a payer and secures nothing enforceable.

Does a reverse proxy protect an airline’s mobile app and booking APIs as well as its website?

Only if those hostnames actually route through it, and frequently they do not, because API traffic gets taken off the edge for latency or SDK compatibility reasons. Check every hostname the app and kiosks resolve, including payments, crash reporting and feature flags, and confirm the origin firewall rejects anything not arriving from the provider’s ranges. A proxy in front of www while api answers directly is a gap, not a defence.



Managed DDoS Protection UK: How to Choose a Provider (With Costs)

Managed DDoS Protection UK: How to Choose a Provider (With Costs)

Buying managed DDoS protection in the UK is less about picking the biggest scrubbing network and more about proving three things to whoever signs the contract: that the service covers every surface an attacker can reach, that it can actually be deployed on your IP addressing, and that the SLA and the billing schedule agree with each other. Those are the points that decide whether an incident becomes a footnote in a board pack or a week of recovery.

This guide takes the buyer’s side of that conversation: what “managed”should mean in scope, where UK estates are routinely left uneven, how pricing is built, and what to do in the first hour if an attack has already started.

What the word “managed”actually buys you

The dividing line is simple. A self-service plan gives you a dashboard, a rate-limiting engine and a set of rules you write, tune and troubleshoot yourself. A managed service means a 24/7 security operations centre watches your traffic, declares an incident, applies mitigation on your behalf and tells you afterwards what it did. If a human on the provider’s side is not empowered to change policy at 03:00 without your sign-off, you have bought monitoring, not management.

A defensible scope of work includes onboarding and initial rule tuning, always-on traffic baselining, alerting to named contacts, mitigation without waiting on your approval, attack reporting with vector breakdowns, in-event change requests (whitelisting a payment partner, loosening a rate limit for a genuine campaign spike), and a written post-incident review. Ask for the escalation matrix in the contract: named engineers, an out-of-hours bridge number, and a maximum time to human contact rather than a maximum time to automated email.

Follow the resale chain before you sign

Many offers badged as managed DDoS protection are partner-programme wrappers around somebody else’s scrubbing capacity. That pattern is old and persistent: hosting providers layered their brand over specialist mitigation appliances and networks in the mid-2000s (Layered Technologies with netZentry, and the wave of Prolexic-era hosting partnerships that followed), and vendors have long run formal channel schemes such as IntruGuard’s managed security services partnership programme to let service providers resell mitigation under their own name.

Reselling is not a fault. Opacity is. Three questions settle it: who staffs the SOC you reach at 3am, whose network physically filters the packets, and who holds authority to change policy mid-attack. If the answer to the second question is a third party, ask what the reseller’s own SLA is against theirs, because you can only be covered to the depth of the weakest link in that chain.

The three surfaces UK buyers protect unevenly: network, application and DNS

Volumetric layer 3/4 floods (UDP reflection, SYN floods, carpet bombing across a whole prefix) are the surface everyone buys for. They are also the easiest for a scrubbing centre to absorb. The harder problem is application-layer traffic and automated bots that arrive at human-plausible request rates against expensive endpoints: search, basket, login, API pagination. That behaviour sits under the volumetric alarm thresholds entirely, which is why bot-management capability (Fastly Bot Management, Cloudflare Bot Management, Akamai Bot Manager and comparable tooling) belongs in the requirements list alongside raw capacity.

Authoritative DNS: the surface most often left unmanaged

An attack on your authoritative DNS produces a total blackout even when every web server is healthy, because nothing resolves. The EveryDNS episode of December 2010 made the point plainly: a DDoS aimed at a single hosted domain led the provider to drop that domain to protect the rest of its customer base, and the site went dark despite its web tier being untouched. Hybrid designs that shield on-premise and cloud DNS together, the design intent behind Akamai Shield NS53, exist precisely because organisations keep their own resolvers for internal reasons and then expose them to the internet.

Practical requirement: either two independent authoritative DNS providers with matched zones, or a shielded/anycast authoritative service with its own DDoS posture. Do not accept “our CDN covers DNS”without confirming which nameservers actually answer for the zone.

Origin IP leakage defeats proxies more often than volume does

Proxy-based protection fails most commonly because the attacker never touches the proxy. The origin address leaks through mail records on the same host, stale A records for old subdomains (dev, staging, cpanel, legacy VPN), historical DNS archives, and certificate transparency logs that publish every hostname you ever requested a certificate for. Onboarding is incomplete until the origin firewall only accepts traffic from the provider’s published ranges, mail is moved off the web address, and the leftover records are cleaned out.

Before shopping, map the exposure: every public IP range you announce or are assigned, API endpoints, VPN and remote access gateways, payment and login paths, mail, and any third-party service that hard-codes your origin. The count of protected domains and IPs is what you will be quoted against, and coordinated hacktivist campaigns hit estates rather than single hostnames. The March 2024 attacks that disrupted multiple French government services, confirmed by the Prime Minister’s office and claimed by a hacktivist group, targeted a spread of state platforms at once.

Deployment models compared: reverse proxy, BGP scrubbing and hosting-level filtering

Reverse proxy / DNS-based mitigation. You point your DNS at the provider, which terminates and filters HTTP(S) at the edge. Fast to deploy (hours, not weeks), strong for web and API traffic, weak for non-web protocols, and only as good as your origin hygiene.

BGP diversion to a cloud DDoS scrubbing service. The provider announces your prefix during an attack (or permanently) and returns clean traffic over GRE tunnels or direct connectivity. This protects every protocol, not just web. The constraint that sales decks skate over: you must be able to announce your own /24 or larger, with your own ASN and an RIR allocation. Most UK SMEs sit on provider-assigned addresses inside somebody else’s aggregate and cannot divert at all. Establish which model your IP situation permits before you start comparing SLAs, because otherwise you are comparing capabilities you cannot buy.

Hosting and data centre included protection. Upstream filtering and blackholing bundled with colocation or cloud hosting is genuinely useful, and some UK managed service providers wrap it into a wider network contract, as with Claranet’s DDoS protection offering. The question to ask in writing is what happens at threshold: does the provider filter your traffic, or null-route your IP to protect its other tenants? A null route is a successful outage from the provider’s perspective and a total outage from yours.

Always-on or on-demand

On-demand diversion is cheaper and adds no steady-state latency, but you pay for it in detection-to-diversion time, typically measured in minutes once BGP convergence is included. Short repeat bursts, the hit-and-run pattern favoured by extortion crews, punish that model: each burst lands, mitigation engages, traffic reverts, and the next burst lands again. Always-on removes that gap, at the cost of routing all traffic through the provider. For UK-facing services, check for a London point of presence and ask where clean traffic re-enters your network, since a mitigation path via Amsterdam or Frankfurt shows up in page timings.

How to compare UK DDoS mitigation providers without relying on the sales deck

Read the SLA clock and the billing clause together. A 60-second time-to-mitigate is close to worthless if the clock starts when you raise a ticket rather than when the provider’s detection fires, and a clean mitigation is a hollow win if attack traffic or the post-event burst lands on your bandwidth invoice. Get answers on:

  • Clock start and remedy. Time to notify, time to mitigate, whether measurement is from detection or from your ticket, and whether the remedy is a service credit worth a few days’ fees or something proportionate.
  • Capacity and architecture. Aggregate and per-PoP scrubbing capacity, PoP locations, behaviour under simultaneous multi-vector attack (layer 3 flood plus layer 7 request flood plus DNS query flood), and whether mitigation is automated or analyst-triggered.
  • Data residency and logging. Where request logs and TLS termination sit, retention periods, and how that reconciles with your UK GDPR position and any sector rules.
  • Billing. Whether attack traffic is unmetered, how clean-traffic overage is charged, per-protected-IP and per-domain counts, and whether burst charges can be triggered by an incident you did not cause.
  • Evidence. Sample attack reports, a redacted post-incident review, references in your sector, and a pre-agreed onboarding and failover test rather than a promise to test “at some point”.

Run the failover test before go-live and again annually. It is the only way to know whether the runbook, the contact list and the tunnels still work, and it is the artefact that satisfies auditors and boards.

What managed DDoS protection costs in the UK, and how pricing is structured

Pricing splits into four recognisable shapes:

  1. CDN entry tiers, per domain. Published list pricing at the time of writing includes Cloudflare’s Pro plan at $20 per month and Business at $200 per month per domain. Self-service, not managed, and priced per zone, so a 30-domain estate multiplies quickly.
  2. Fixed monthly platform subscriptions. AWS Shield Advanced is published at $3,000 per month per organisation on a 12-month commitment, plus data transfer charges; Microsoft’s Azure DDoS Network Protection is published on a similar fixed monthly basis covering a set number of public IP resources. Check current vendor pricing pages, as these change.
  3. Clean-bandwidth commits. Scrubbing providers and carriers commonly price on committed clean Mbps/Gbps plus a per-prefix or per-protected-IP charge, with attack traffic excluded from metering (confirm that in writing).
  4. Enterprise annual contracts with a managed service fee. A platform licence plus a separate SOC/managed line item, usually on 12 to 36 month terms.

Licence cost is rarely the whole spend. Budget separately for onboarding engineering, ASN and GRE tunnel work if you are diverting via BGP, DNS migration, WAF and bot rule tuning (the phase where false positives get found, and the one most often under-scoped), and any retained incident response hours.

Emergency onboarding while an attack is running is the most expensive way to buy. Providers price it as incident work, contract lengths get longer, and the tuning that normally takes two weeks happens under load. The rapid-response arrangements publicised in the market, including Cloudflare’s partnership with Booz Allen Hamilton to assist organisations already under attack, exist for exactly that scenario, and they illustrate the premium and the constraints attached to it.

Building the business case

Boards respond to downtime cost per hour, not attack sizes in gigabits. The arithmetic is straightforward: divide annual online revenue (or the cost of the service being unavailable) by realistic trading hours. An operation taking £12m a year online across roughly 4,000 effective trading hours carries about £3,000 an hour in gross order value at risk, before support cost, chargebacks and reputational effects. Set that against annual protection spend and the case usually writes itself. Financial services teams have a shorter path still, given the availability expectations that follow incidents like the DDoS attack that disrupted National Australia Bank’s online services.

Under attack now: the first hour, ransom demands and the UK legal position

Confirm it is a DDoS before you escalate. A capacity limit, an expired certificate, a bad deployment or a DNS misconfiguration all look like an outage. Check upstream interface counters, request rates versus error rates, and whether the traffic profile is plausible. Then work the sequence: notify your ISP and upstream hosting provider, since filtering closest to the source is the most effective option available, apply rate limiting where you can, and trigger the provider escalation path with a named contact rather than a web form. CISA’s guidance on understanding and responding to denial-of-service attacks sets out the same priorities, including engaging your service provider early and pre-planning the response.

If a ransom note arrives, do not pay. Preserve the demand with full email headers, keep flow data and logs, and report it: Action Fraud for the crime report (Police Scotland in Scotland) and the NCSC’s reporting route for significant incidents. Extortion crews test for payers, and the pattern of hit, demand and repeat has been prosecuted for two decades, as the Russian cyber-blackmail gang jailed for attacks on bookmakers demonstrated. Attack capacity itself remains a botnet supply problem, which is why coordinated botnet reduction initiatives keep reappearing on national agendas. The FBI and CISA have also issued joint public warnings about denial-of-service activity degrading access to public-facing critical infrastructure services, including their September 2020 advisory on DDoS against election infrastructure.

The legal and regulatory frame

Launching a DDoS attack is a criminal offence in the UK under the Computer Misuse Act 1990, section 3, as amended by section 36 of the Police and Justice Act 2006 to cover unauthorised acts intended to impair the operation of a computer. Custodial sentences are on record: Daniel Kaye was sentenced to two years and eight months at Blackfriars Crown Court in January 2019 over attacks that disrupted a Liberian telecoms operator.

Three regulatory duties shape requirements more than most procurement teams expect. Operators of essential services and relevant digital service providers carry security and incident-reporting obligations under the NIS Regulations 2018. FCA-regulated firms have to identify important business services and impact tolerances under the operational resilience regime (PS21/3), with firms required to be operating within those tolerances from 31 March 2025. And availability is a security requirement under UK GDPR, not just a commercial one, so a prolonged outage affecting personal data systems can carry regulatory questions alongside the revenue loss.

The decision, in the end, rests on fit rather than brochure capacity. Confirm which deployment model your addressing allows, cover network, application and authoritative DNS to the same standard, lock the origin, and make sure the SLA clock and the billing clause tell the same story. Managed DDoS protection bought on those terms in the UK is defensible in front of a board; a plan bought on peak-gigabit figures alone usually is not.

Frequently Asked Questions

What is managed DDoS protection, and how is it different from a self-service plan?

Managed protection means a provider’s SOC monitors your traffic, declares incidents, applies and tunes mitigation on your behalf, and reports afterwards. A self-service plan gives you the same filtering platform but leaves detection thresholds, rule writing and in-event decisions to your team. The practical test is whether the provider can change policy during an attack without waiting for your approval.

How much does managed DDoS protection in the UK typically cost?

Pricing follows four models: per-domain CDN tiers (Cloudflare publishes $20 and $200 per month for Pro and Business), fixed monthly platform subscriptions (AWS Shield Advanced is published at $3,000 per month per organisation on an annual commitment), committed clean-bandwidth pricing, and enterprise annual contracts with a separate managed service fee. Add onboarding engineering, DNS migration, tunnel setup and rule tuning to the licence cost, and treat any figure as a placeholder until you hold a written quote.

Does the DDoS protection included with my hosting or data centre cover me?

Partly. Bundled upstream filtering handles routine volumetric noise well, but ask what happens when the attack exceeds the platform threshold: many providers null-route the targeted IP to protect other tenants, which ends the attack and your availability at the same time. Get the threshold, the response action and the notification commitment in writing.

Do I need separate DNS DDoS protection if I already use a CDN?

Only if the CDN is genuinely authoritative for your zone and its DNS service carries its own mitigation and SLA. Plenty of organisations proxy their web traffic while leaving authoritative DNS on a small provider or an on-premise resolver, which leaves a single point of total failure. Either use two independent authoritative providers with matched zones, or a shielded anycast DNS service.

Can I get managed DDoS protection set up while an attack is in progress?

Yes. DNS or proxy-based onboarding can be completed quickly, and specialist rapid-response arrangements exist for organisations already under attack. Expect premium pricing, longer contract terms and imperfect tuning, and expect to fix origin exposure under load, which is why pre-contracting is materially cheaper.

Are DDoS attacks illegal in the UK, and can I take legal action after one?

They are criminal offences under section 3 of the Computer Misuse Act 1990 as amended by section 36 of the Police and Justice Act 2006, and UK courts have imposed custodial sentences. Report through Action Fraud (Police Scotland in Scotland) and the NCSC, preserve logs, flow data and any ransom correspondence with headers intact, and take separate legal advice on civil claims, which are usually difficult where attackers are overseas or unidentified.

Should we ever pay a ransom DDoS demand?

No. Payment marks you as a paying target, offers no guarantee the attack stops, and funds further activity, and there may be sanctions exposure depending on who is behind the demand. Report it, keep the evidence, and put the money into mitigation capacity and a tested runbook instead.



Akamai Shield NS53 protects on-prem and hybrid DNS infrastructure

Akamai launched Akamai Shield NS53, a product that protects on-premises (on-prem) Domain Name System (DNS) infrastructure from resource exhaustion attacks. These attacks overwhelm servers to the point that they can no longer respond to valid DNS queries. The new offering complements Akamai Edge DNS, which is a comprehensive cloud-based DNS solution, and Akamai Prolexic, a distributed denial-of-service (DDoS) protection platform for Layer 3 and Layer 4 attacks. Over the past three years, there has been … More ? The post Akamai Shield NS53 protects on-prem and hybrid DNS infrastructure appeared first on Help Net Security .

More:
Akamai Shield NS53 protects on-prem and hybrid DNS infrastructure

Cloudflare partners with Booz Allen Hamilton to guide organizations under attack

Cloudflare announced a collaboration with Booz Allen Hamilton to support enterprises under attack by providing expedited Under Attack as a Service (UAaaS) with 30-Day Rapid Response DDoS Mitigation, including continuous monitoring and protection. Under this new agreement, Booz Allen’s Global Commercial clients facing a cyber-attack will be connected to Cloudflare for immediate Incident Response. Now, Booz Allen clients that may fall victim to cyber-attacks have a fast track to support when they need it most. … More ? The post Cloudflare partners with Booz Allen Hamilton to guide organizations under attack appeared first on Help Net Security .

Excerpt from:
Cloudflare partners with Booz Allen Hamilton to guide organizations under attack

Fastly Bot Management protects websites, apps, and valuable data from malicious automated traffic

Fastly introduced Fastly Bot Management to help organizations combat automated “bot” attacks at the edge and significantly reduce the risk of fraud, DDoS attacks, account takeovers, and other online abuse. Fastly Bot Management represents an important cybersecurity milestone for the company, building on its proven bot mitigation expertise and capabilities currently available in its Next-Gen WAF. “Organizations increasingly are delivering more enhanced digital experiences to their users at the edge. Not surprisingly, cyber adversaries have … More ? The post Fastly Bot Management protects websites, apps, and valuable data from malicious automated traffic appeared first on Help Net Security .

Follow this link:
Fastly Bot Management protects websites, apps, and valuable data from malicious automated traffic

Nearly 3M people hit in Harvard Pilgrim healthcare data theft

Also, TheMoon botnet back for EoL SOHO routers, Sellafield to be prosecuted for ‘infosec failures’, plus critical vulns Infosec in brief   Nearly a year on from the discovery of a massive data theft at healthcare biz Harvard Pilgrim, and the number of victims has now risen to nearly 2.9 million people in all US states.…

More:
Nearly 3M people hit in Harvard Pilgrim healthcare data theft