Data Centre DDOS Protection: A Colocation Checklist

A colocation contract that lists data centre DDoS protection somewhere between the power resilience figures, the cross-connect pricing and the four-nines network uptime SLA tends to get read once, at signature, and never again. Then a 40 Gbps UDP reflection flood arrives at 02:40 on a Sunday aimed at one IP address in your rack, and the question stops being technical. It becomes contractual: who is allowed to do what to your traffic, and how fast?

Shared infrastructure changes the answer. A facility operator owes a duty of care to every tenant on that transit, not just to you, and the fastest way to protect every other customer behind the same upstream ports is to stop announcing your prefix. Your kit stays powered. Your service disappears.

What “DDoS protection included”usually means at the data centre edge

Most included protection in UK colocation and dedicated hosting is one thing: flow-based detection on edge and transit routers, feeding a mitigation platform or an upstream blackhole request. Useful, but narrow.

Sampled flow data decides when mitigation starts

Edge routers do not inspect every packet for your benefit. They export NetFlow or sFlow records from a sample, commonly configured around one packet in a thousand, because full flow export at line rate on a loaded border router is expensive in CPU and in collector licensing. Sampling at that ratio is fine for capacity planning and for spotting a sustained 20 Gbps flood. Short, sharp pulse attacks are a different matter: a 30-second burst repeated every ten minutes can start, saturate your port and finish before a detection threshold trips and an operator opens a ticket. Compare that with an always-on inline appliance or a reverse proxy path, where every packet or every HTTP request is seen as it arrives.

Facility transit versus your single IP

Operators generally protect the facility first. That is honest engineering, not malice. An attack that threatens the aggregate, say 200 Gbps into a site with 300 Gbps of upstream capacity, gets handled because it threatens everyone. A 2 Gbps application-layer flood against your one web VIP threatens nobody but you, sits comfortably inside the facility’s headroom and may never register as an incident at all. Ask explicitly whether mitigation is scoped to the facility’s transit or to your individual prefix and addresses.

Network and transport only, and no human tuning

Included cover is almost always layer 3 and layer 4. No TLS termination, no HTTP request inspection, no authoritative DNS, no baselining of your normal traffic profile, no named engineer who knows that your API bursts to 8,000 requests per second every night at 23:00 when the batch job runs. That last point matters more than buyers expect, because untuned thresholds either fire late or block legitimate customers. If nobody on the provider side is empowered to change policy at 03:00 without your sign-off, you have bought monitoring, not management.

Four questions expose the real scope quickly: what are the detection thresholds and are they yours or the facility’s defaults; who is paged, by name and number, at 03:00; what is the documented action when attack volume exceeds facility transit; and is any of it written into the SLA with a remedy, or does it live in a sales deck?

The blackhole clause: when your provider null-routes you

Remote-triggered black hole filtering is standardised, old and extremely effective. The mechanics are described in RFC 5635, published by the IETF in August 2009: the victim’s network tags a route with the upstream’s blackhole BGP community, and the transit provider drops traffic to that destination at its own edge, before it ever reaches the facility’s ports. Cost to the data centre: near zero. Time to effect: seconds. It is the single fastest tool a colocation operator has, which is exactly why it is in the acceptable use policy.

Look for it in the AUP or the SLA annexe rather than the brochure. The wording is usually some variant of a right to suspend or filter traffic that threatens network stability or other customers, at the operator’s sole discretion. Read as a buyer, that clause says your /32 can be withdrawn from the internet to keep the floor running, and it will be.

The practical result is that the facility stays up, the incident report says the attack was mitigated, and your service was unreachable for the duration of the hold timer, typically measured in tens of minutes with automatic re-announcement and re-trigger if the flood persists. Both statements are true at once. That is the part people only discover mid-attack.

Negotiate four things before signature: notification to a named contact before or at the moment of blackhole rather than afterwards; a maximum hold time with a review interval; a pre-agreed diversion path to a scrubbing centre as the first response rather than the second; and a spare announceable prefix you can move critical services onto while the attacked range stays dark.

The three surfaces inside your colocation footprint

Map your estate by surface, not by server. Three of them decide whether you stay online.

Network and transport

Check the transit mix and upstream count, whether scrubbing happens on-net inside the facility or by diversion to an off-net centre, and the prerequisite that quietly disqualifies most colocation customers: do you hold your own announceable prefix? BGP-based mitigation needs a /24 as a practical minimum, your own authority to announce it, and route objects (RPKI ROAs and an IRR entry) that let a scrubbing provider announce it on your behalf without being filtered. Customers sitting on provider-assigned addresses inside a larger aggregate cannot be diverted independently. No amount of budget changes that; it pushes you towards proxy or facility-level filtering, so find out at design time, not during an incident.

Application layer

Work out where TLS terminates and what absorbs the pain when requests, not packets, are the weapon. Slow-POST, HTTP/2 request floods and expensive-endpoint hammering land on your load balancers or straight on origin servers. Would your logs even show it? A 100 Mbps flood of valid-looking POSTs to a search endpoint produces a graph that looks like a successful marketing campaign and an application that looks like a database problem. The specific gaps are worth reading up on separately; this site covers them in detail in the seven real gaps in application-layer defence.

Authoritative DNS

Here is the surface almost nobody assigns an owner to. Clean transit, a proxy in front of the web tier, two nameservers sitting on the same prefix in the same rack or parked with the registrar on a single platform. Flood the nameservers and the service is gone regardless of how good the scrubbing is in front of everything else. Resolution failure looks identical to a dead website to your customers.

Do the boring mapping exercise. List every public IP, every hostname, every nameserver and every non-HTTP port (SMTP, SSH, game servers, SIP trunks, database replication), then write the contractually responsible party next to each line. The blanks are your exposure.

Who actually owns the capacity behind a DDoS protected hosting provider

The brand on your invoice is frequently not the network doing the scrubbing. A realistic chain has four distinct layers in it: the facility operator who owns the floor and the cross-connects, two or three transit providers, a mitigation vendor whose platform does the filtering, and the managed service provider or host whose logo appears on the portal. The UK market mixes all of these. Specialist scrubbing networks such as Akamai’s Prolexic service, managed providers like Claranet reselling and wrapping mitigation, and hosting-level filtering built into facilities as GigeNet and others do, sit at different points in that chain. Comparing logos tells you nothing. Asking who operates the scrubbing centre your traffic would reach tells you whose SLA you can actually enforce.

Advertised aggregate capacity is the weakest evidence in the pack. A headline figure sums every point of presence worldwide; your traffic reaches one, probably in London, possibly in Amsterdam or Frankfurt with the latency that implies. Ask for scrubbing centre locations and the capacity at the ones that would serve you, peering and transit detail at those sites, sample attack reports from real events with vector breakdowns and timestamps, and a time-to-mitigate commitment with its measurement method stated. From first attack packet, or from the moment a human acknowledges a ticket? The difference is often 20 minutes. Our guide on judging Tbps claims goes further into how those numbers are constructed.

For “managed”to be worth the premium it must include onboarding and initial rule tuning, always-on baselining of your traffic, an escalation matrix with named contacts, explicit authority for the provider’s NOC to divert without waking you first, and a post-attack report you can put in front of a board.

Deployment models for data centre workloads

Three models, each with a failure mode worth knowing before you choose.

Reverse proxy in front of web estates. Fast to deploy, strong on application-layer attacks, and completely bypassable if the attacker holds your origin addresses. Which they often do, because origin leakage is the dominant cause of proxy bypass in data centre environments, not attack volume. Historic A records in passive DNS, mail sent direct from the application server with the origin IP in the headers, certificate transparency entries for staging and development hostnames on the same prefix, and external monitoring agents polling the origin by IP address. Auditing those leaks costs nothing and changes outcomes more than another 100 Gbps of capacity. Then firewall the origin to accept traffic only from your proxy provider’s published ranges.

BGP diversion with GRE or cross-connect return. Protects everything in the rack, including SMTP, game and VoIP traffic, which is the main reason to choose it. Prerequisites are real: a /24, route authority, valid route objects, and MTU planning. A GRE tunnel back from the scrubbing centre knocks the usable MTU down to roughly 1476 bytes once the GRE and outer IP headers are accounted for. A diversion that has never been tested end to end breaks large file uploads, chunky API payloads and some TLS handshakes the first time it is activated in anger, and the team then spends 40 minutes blaming the scrubbing vendor for a path MTU problem.

Hosting-level or appliance filtering in the facility. Lowest added latency, which matters for gaming and real-time voice, and attractive where facilities have invested in it directly, as in this data centre’s own anti-DDoS build-out. The ceiling is the facility’s transit headroom. An intrusion-prevention appliance behind a saturated 100 Gbps border does nothing except fill its own logs.

Costs, billing traps and the business case

Attack traffic collides with commercial bandwidth billing in ways procurement rarely checks. If inbound volume counts towards your 95th percentile measurement or triggers burst charges, a single sustained flood produces an invoice shock on top of the outage. Get the exclusion for mitigated attack traffic written into the contract. Verbal reassurance from an account manager is not an exclusion.

Beyond that, expect clean-pipe pricing banded by committed clean throughput, a count of protected IPs or protected /24s, per-event mitigation fees on on-demand plans, and sometimes a charge per diversion activation. The structures and realistic UK figures are broken down in our piece on what DDoS protection actually costs in the UK.

Price your downtime before you price the protection. A retailer taking a substantial volume of orders through checkout every hour can justify always-on mitigation plus a second DNS provider on arithmetic alone; a brochure site with a contact form cannot, and a tested on-demand runbook is the proportionate answer there. Always-on removes the detect-and-divert delay but you pay for steady-state diversion and carry the extra latency all year. On-demand is cheaper and slower. Hybrid setups, always-on for the payment and DNS surfaces and on-demand for everything else, are common for good reason.

The pre-signature checklist and the first hour

Ten questions to put in writing before anyone signs:

Under what conditions will you blackhole our prefix, and on whose authority?
Who is notified, by which channel, before and during a blackhole?
What is the maximum hold time and the review interval?
What is your committed time to mitigate, and is it measured from the first attack packet or from ticket acknowledgement?
May your NOC divert traffic to scrubbing without our sign-off at 03:00?
Exactly which IPs, hostnames, nameservers and non-HTTP ports are covered?
Who operates the scrubbing centres, and which UK sites would our traffic reach?
What does a post-attack report contain, and within how many hours?
Is mitigated inbound attack traffic excluded from 95th percentile and burst billing?
What capacity evidence and sample attack reports can you provide from real events, and who are the named escalation contacts?

Technical readiness is the other half: an announceable prefix with current route objects; a diversion tested during a change window with the return path and MTU verified end to end; pre-staged proxy configuration ready to publish; out-of-band access that does not traverse the attacked prefix; and authoritative DNS split across two independent providers.

In the first hour, confirm it is an attack and not a routing fault or a failed deployment, which takes about ten minutes if you know how to distinguish a DDoS from an outage. Identify the targeted surface: transit, application or DNS. Then call the escalation number you have already tested, quoting the contract clause that grants diversion authority. The NCSC’s denial of service guidance collection is a sound reference for building that runbook and for the rehearsal most teams skip.

Rehearse it once a year. Sound data centre DDoS protection is not a product you buy at the edge; it is a short list of named people with the authority to act, a diversion path somebody has actually tested, and a contract that says what happens to your prefix when the other tenants need saving.

Frequently Asked Questions

Does my data centre’s included DDoS protection cover my servers or just its own network?

In most colocation and dedicated hosting contracts, included protection is scoped to the facility’s transit and aggregate stability, not to your individual prefix or application. It typically covers volumetric layer 3 and 4 attacks via flow detection and upstream mitigation, with no application inspection or DNS cover. Ask for the scope in writing, naming your IPs and hostnames.

Can a colocation provider null-route my IP address during an attack?

Yes, and most acceptable use policies reserve the right to do exactly that. Remote-triggered black hole filtering, as described in RFC 5635, drops traffic to your address at the upstream transit edge, protecting the facility and other tenants while removing your service from the internet. Negotiate notification, a maximum hold time and a pre-agreed diversion alternative before you need them.

What does data centre DDoS protection typically cost on top of rack space and transit?

Pricing is usually built from committed clean bandwidth, the number of protected IPs or prefixes, and whether mitigation is always-on or on-demand, with per-event fees common on the latter. UK figures vary widely by provider and commitment, so get quotes against your own traffic profile and check the billing treatment of attack volume. Our UK cost guide sets out the structures in more detail.

Do I need a separate scrubbing service if my hosting provider advertises DDoS protection?

Sometimes not, if the host genuinely runs managed mitigation with named escalation, tuning and reporting. Often yes, if the advertised protection is edge detection plus a blackhole policy, or if your exposure includes application-layer and DNS surfaces the host does not touch. Establish who operates the scrubbing capacity behind the logo, then decide.

Why does my site still go down when the data centre says the attack was mitigated?

Both statements can be true. The facility may have mitigated the threat to its own network by blackholing your prefix, or the attack may have shifted to a surface outside the covered scope, most often authoritative DNS or the application layer. Origin address leakage that lets an attacker bypass a reverse proxy is another frequent cause.

ISP DDOS Protection UK: What It Covers (And Doesn’t)

A head of infrastructure signs a 1Gbps dedicated internet access (DIA) circuit for a distribution business in the Midlands, sees the line “DDoS protection included”in the order form, and files the question as answered. Nine months later the website goes dark for three hours during a promotion. The provider’s incident note says the attack was “mitigated at the network edge”. Both statements are true. The site was still offline the whole time.

ISP DDoS protection in the UK is genuinely useful, and for one specific failure mode it is the only thing that works. But what most UK connectivity contracts actually bundle is detection plus a null route, and the gap between that and what buyers assume they bought is where the outage lives. This piece decodes the language, names the three surfaces a circuit can never defend, and sets out the questions to ask before the contract is signed rather than during the incident.

What ISP DDoS protection in the UK actually includes

Strip away the datasheet and the standard anatomy is consistent across most UK providers: routers at the provider edge export sampled flow data (NetFlow, sFlow or IPFIX), a detection platform compares that against a baseline or a fixed threshold, an alert fires, and then something happens to your traffic. The first three steps are commodity engineering and broadly reliable. The fourth step is the whole product.

That fourth step is usually one of three things. Inline on-net scrubbing appliances sitting in the provider’s own network, filtering traffic and passing clean packets through. Diversion, where a BGP announcement pulls your traffic to a scrubbing centre (the provider’s or a partner’s) and returns the clean portion over a tunnel or direct connection. Or a null route.

Pricing follows the same split. The no-cost tier bundled with the circuit is nearly always detection plus blackhole, sometimes with a monthly allowance of mitigation events. Always-on scrubbing with clean-traffic return is a chargeable add-on, typically priced by protected bandwidth, number of protected IPs or prefixes, and whether mitigation is on-demand or permanent. The uplift usually triggers on one of those three variables, so ask which one before someone quotes you a figure.

None of that scepticism changes the one thing only a connectivity or transit provider can do. Take a 1Gbps DIA circuit hit by a 40Gbps reflection flood. The firewall, the load balancer, the application gateway: none of them matter, because the tail circuit is already saturated upstream of every box you own. Nothing on your premises can empty a full pipe. Mitigation has to happen at the ISP, at its transit provider, or at a cloud scrubbing centre further out. That is the real strength of circuit-level protection, and it is worth paying for.

Blackholing is not mitigation: the clause that decides your outage

Remote-triggered black hole (RTBH) filtering is a legitimate, well-documented operational technique. It is described in RFC 5635, and the well-known BGP community used to signal it is defined in RFC 7999 as 65535:666. The mechanism works by announcing the victim address with a community that tells upstream routers to discard all traffic for it, as close to the network edge as possible.

Read that again. All traffic. Not attack traffic.

RTBH protects the ISP’s core, its peering links and every other customer sharing that infrastructure. It is a good decision for the network operator and a terrible outcome for the single customer being attacked, who is now comprehensively offline until the hold-down timer expires. The attacker has achieved exactly their objective, faster and more completely than the flood alone would have managed.

Two questions decide how bad it gets. First, granularity: is the discard route applied to a single /32 (or /128), or to the whole prefix? If your ISP nulls a /24 that also carries your mail server, your VPN concentrator and the API your customers integrate against, one attack on a marketing page takes down services that were never targeted. Second, duration: is there a stated hold-down period, who can lift it, and does lifting it require a ticket during working hours?

Contract language rarely makes this obvious. “Mitigate”, “discard”, “filter”, “suppress”and “protect the network”can all describe the same null route. Get it defined in writing. The sentence you want somewhere in the service description reads roughly: attack traffic is filtered at a scrubbing platform and legitimate traffic is returned to the circuit, with a stated time-to-mitigate and blackholing used only as a last resort with notification. If the provider will not write that down, assume the default is a null route and price your risk accordingly.

Three surfaces your circuit cannot defend

Circuit-level detection is tuned for bits per second and packets per second, because those are the metrics that threaten the provider’s network. Attackers know this.

The application layer. A few hundred Mbps of valid-looking, TLS-terminated HTTPS requests on a 1Gbps circuit will exhaust connection pools, PHP workers and database sessions while sitting comfortably below every volumetric threshold. Sampled flow data sees normal-ish traffic volumes to port 443. The detector stays quiet. The application falls over. That is the argument for treating a proxy or app-layer service as a companion to ISP protection rather than a competitor to it, and the specific gaps are worth reading up on in more detail in our breakdown of where application layer DDoS protection falls short.

Authoritative DNS. This is the surface most often left entirely unmanaged, and it almost never sits behind the circuit being protected. Delegation usually lives with a registrar, a hosting control panel or an inherited nameserver pair from a previous web agency. A random-subdomain (water torture) or NXDOMAIN flood against those nameservers is somebody else’s problem, and your ISP’s scrubbing platform never sees a single query. DNS providers do get attacked, as the flooding of Point DNS demonstrated, and when the nameservers go the whole estate goes with them regardless of how healthy the circuit is. The fix is splitting delegation across two independent anycast operators, and it has to be proved with a real delegation change and a tested failover, not assumed from a feature list.

Anything not behind that circuit. Cloud workloads, SaaS integrations, branch VPN concentrators on different lines, third-party payment and booking layers, the customer portal someone put on a separate hosting account. ISP protection is scoped to traffic crossing that connection. Draw the estate on a whiteboard and mark what actually transits the protected circuit. The map is usually smaller than expected.

Then there is origin IP leakage, which breaks more proxy deployments than raw attack volume does. Mail servers in the same range, stale A records for old. and dev. subdomains, staging hosts, certificate transparency logs and outbound connections from the origin all republish the circuit IP to anyone who looks. Once an attacker has it, they bypass the proxy entirely and hit the line. At that moment the ISP layer is your real perimeter, which is precisely when a blackhole-only contract turns into a multi-hour outage.

Whose network and whose scrubbing capacity are you buying?

Ask the resale question early and plainly: whose appliances, whose transit, whose scrubbing centres? There are three honest answers and they lead to different numbers.

Where the ISP runs its own on-net mitigation, capacity is bounded by that ISP’s transit and peering, not by any global figure in a brochure. A provider with 200Gbps of aggregate upstream cannot absorb a 300Gbps flood, whatever the appliance vendor’s specification sheet claims. Where mitigation is white-labelled from a cloud platform, you get far larger headline capacity, a diversion step, a GRE or direct-connect return path and added latency, plus a support chain where your incident ticket passes through two companies. Where the ISP relies on its upstream transit provider’s platform, mitigation policy is being set by an organisation you have no contract with.

Useful follow-ups: which scrubbing centre locations serve UK traffic, whether they peer at LINX or LONAP, how clean traffic returns and what that adds to round-trip time, and what happens when the attack exceeds the local centre’s capacity. Capacity claims deserve the same scepticism as any vendor number, and the approach to testing them is set out in our guide to judging Tbps scrubbing claims.

What “managed”has to mean before you sign

“Managed”is the most elastic word in the sector. Pressure-test it with operational questions rather than features.

Who detects, who decides and who acts at 02:00 on a Sunday? Name the team and the escalation matrix, not a portal login. If nobody on the provider side can change policy without your written sign-off, you have bought monitoring, not management.
Does time-to-mitigate start at detection or when you telephone the NOC? The difference is routinely the difference between four minutes and forty.
Who tunes thresholds before a product launch, a ticket release or results day at a college? False positives during planned traffic spikes do more commercial damage at some organisations than small attacks do.
What is the remedy when the SLA is missed, and is it a service credit against the mitigation line item or against the whole circuit?
Can they supply a redacted post-attack report showing vectors, packet rates and mitigation timeline? You will want that document for your insurer, and for Action Fraud if you report the incident.

Request a tested change window too. Rolling a mitigation policy change for the first time during a live attack is not a plan.

ISP protection, reverse proxy or BGP scrubbing: which combination fits

These are not three competing purchases. They defend different things.

Circuit-level ISP protection handles volumetric saturation of the tail, the one problem you cannot solve yourself. A reverse proxy or CDN handles HTTP(S) floods, bot filtering, caching and TLS termination, and hides the origin if (and only if) the origin stays hidden. BGP diversion to a scrubbing provider protects whole prefixes and non-web services: game servers, SIP trunks, mail, VPN, anything a web proxy cannot front. Hosting and SaaS businesses shopping for a DDoS protected hosting provider should check which of these three the provider actually operates, because “DDoS protected”on a hosting page frequently means its upstream will blackhole the IP.

At the ISP layer, decide between always-on and on-demand. On-demand costs less and adds no steady-state latency, but diversion takes time to converge and asymmetric routing during the switch causes its own problems. Always-on removes the convergence delay and makes every packet pay the detour.

Address space is the quiet decider. A /24 allocated or transferred to you by the RIPE NCC plus your own autonomous system number means you can re-announce to a scrubbing provider in minutes and walk at renewal. Provider-assigned space ties you to whatever your current ISP is willing to do, and migration becomes a renumbering project touching firewall rules, allowlists and third-party integrations.

Build the spend case from downtime, not from the monthly line. Work out your own hourly revenue from your own figures, and do it twice: once averaged across the week, and once for a peak trading evening, which will be several times higher. On that arithmetic a four-hour null route during a promotion can cost more than a year of always-on scrubbing, before SLA credits owed to your own customers and staff time. Our breakdown of what DDoS protection actually costs in the UK covers how those quotes are structured. Procurement patterns reinforce the point: UK public bodies commonly buy mitigation as a separate service through the Digital Marketplace, and education and research sites receive it in tiers attached to Janet connectivity via Jisc. In both cases protection is attached to a connection, priced in tiers, and scoped to traffic crossing it.

If you are the ISP or hosting provider

Smaller UK ISPs, WISPs and hosts face the same questions from the other side. Protect shared infrastructure first: core and edge routers, recursive resolvers, RADIUS, mail relays and the customer-facing portal. An attack on one customer that takes out your resolvers affects everyone, and that is the outage your subscribers will remember.

Then make the customer-impacting choices deliberately. Per-customer detection thresholds rather than one network-wide number. Opt-in scrubbing as a priced tier, with blackholing reserved for traffic that exceeds what you can filter. And communicate a null route honestly: a status update saying “we have discarded traffic to this address to protect other customers, estimated hold-down 60 minutes”earns more trust than “attack mitigated”. Resellers should document whose capacity sits behind the service, the return-path design and the escalation chain, because the buyers reading this article will ask.

Frequently Asked Questions

Does ISP DDoS protection cover attacks on my website?

Partly. It covers volumetric floods that would saturate the circuit your web server sits behind, which is real and valuable protection. It will not normally stop an application-layer HTTPS request flood, because that traffic looks legitimate and stays below bits-per-second thresholds, and it does not cover attacks on your authoritative DNS or on anything hosted elsewhere.

Is DDoS protection included with UK business internet, or charged extra?

Both, depending on tier. Many UK providers include basic detection and blackhole response at no extra cost on DIA and transit services, then charge for scrubbing with clean-traffic return, usually priced on protected bandwidth, protected IP count or always-on versus on-demand. Ask which of those variables drives the quote, and confirm in writing what the free tier does when an attack starts.

What is blackholing, and why does it leave my site offline?

Blackholing, or remote-triggered black hole filtering (RFC 5635), announces your address upstream with a BGP community that tells routers to discard every packet destined for it. All traffic is dropped, legitimate requests included, so the attack stops reaching the provider’s core while your service stays unreachable. Check whether the discard applies to a single /32 or to the whole prefix, and what the hold-down period is.

Can I use my ISP’s protection alongside a CDN or reverse proxy?

Yes, and that combination is usually the right one. The proxy absorbs HTTP(S) floods and hides the origin; the ISP layer catches volumetric traffic aimed directly at the circuit when the origin IP leaks through mail records, old subdomains or certificate transparency logs. The two defend different layers, so treat them as complementary rather than choosing one.

How fast should an ISP mitigate a DDoS attack?

Providers commonly quote detection within a minute or two of flow sampling and mitigation inside a small number of minutes for automated responses, but the contractual wording matters more than the headline figure. Establish whether the clock starts at automated detection or at your phone call, what the figure is for on-demand diversion versus always-on, and what remedy applies if it is missed. The NCSC’s denial of service guidance collection is a sensible reference when drafting those requirements.

Buying ISP DDoS protection in the UK is not a mistake. Buying it believing it is a complete answer is. Find out whether you have scrubbing or a null route, whether the null route is per address or per prefix, whose capacity sits behind the promise and who is authorised to act at three in the morning. The answers are easy to get before you sign, and expensive to discover afterwards. Many UK firms still have not asked, which is one reason preparedness research keeps finding the same gaps.

DDOS Protected Hosting Provider: 6 Checks Before You Buy

Search for a DDoS protected hosting provider and the first page of results looks settled: a Tbps figure, a monthly price, a green tick next to “DDoS protection included”. Most of those pages never say whose network the filtering happens on, what the acceptable use policy permits the provider to do to your IP address during an attack, or whether a flood of HTTP requests at modest bandwidth is covered at all. The badge is not the protection.

What follows is six checks, written as questions a provider should answer in writing before the order form, along with the lookups and paperwork that prove or disprove each answer. The National Cyber Security Centre’s denial of service guidance sets the baseline framing for UK buyers: understand your dependencies, know what your provider has committed to, and test the assumption before you need it.

What “DDoS protected hosting”actually covers (and what it rarely does)

Three shapes of protection, built for different traffic

Buyers end up with one of three arrangements, sometimes without being told which. Filtering at the hosting provider’s own network edge, where traffic to your server passes through a mitigation appliance or platform before it reaches the rack. A reverse proxy in front of your hostname, where DNS points at the provider’s anycast network and your origin sits behind it. Or BGP scrubbing for prefixes you announce yourself, where routes are diverted to a scrubbing centre and clean traffic returns over a tunnel or cross-connect.

Edge filtering is good at packets. Reverse proxies are good at requests. BGP scrubbing is for organisations with their own IP space and an AS number, and it protects everything in the prefix, including mail, VPN concentrators and DNS. Buying the wrong shape is the most common and most expensive mistake on this list.

The same badge, two different problems

Game-server hosting and web hosting advertise identical protection for attacks that have almost nothing in common. A game host is defending UDP ports against amplification and high packet-per-second floods, where the failure mode is a saturated link or an overwhelmed NIC. An ecommerce site is defending a basket endpoint against HTTP request floods that arrive politely over TLS and look like customers. Hardware tuned for one is frequently blind to the other.

Bundled as standard, or charged as an add-on

Read the plan page as a price list rather than a feature list. Protected IPs are often charged per address beyond the first; clean bandwidth has a ceiling with overage above it; web application firewall rules are a separate tier; authoritative DNS hosting is free but unprotected; attack reporting is sometimes available only on managed plans. Our breakdown of what DDoS protection really costs in the UK covers how those line items stack up at renewal.

The test to run before you talk to anyone

Write down every service you expose and mark which ones sit behind the protection: website, API, authenticated admin panel, SSH or RDP, SMTP and IMAP, authoritative DNS, game ports, monitoring endpoints, staging. Most lists come back with four or five items outside scope. That inventory is the only honest starting point for a conversation with a vendor.

Check 1: whose network and scrubbing capacity are you really buying?

A large share of hosting brands selling mitigation are reselling it. The filtering belongs to a transit provider, a colocation operator or a scrubbing vendor further up the chain, and the capacity headline on the landing page is that upstream’s number, not the reseller’s. Nothing wrong with reselling. Plenty wrong with not knowing.

Ask three things and verify them independently: which autonomous system number announces the IP space your server will sit in, who the upstream transit providers are, and which mitigation platform or vendor performs the filtering. Routing and peering data is public. Look the ASN up in RIPE’s database and a route-collector service, check the upstreams, and see whether the announcement comes from the brand you are paying or from someone else entirely. If the answer is “we don’t disclose our suppliers”, you are being asked to buy a capability nobody will name.

Shared capacity is also shared during an attack. A 2 Tbps platform figure means little if your mitigation competes with every other tenant behind the same scrubbing centre while a broad campaign is running, which is why headline numbers deserve the scepticism we set out in our guide to judging Tbps claims.

The question that produces the most useful answer is about people, not pipes: during an attack on your IP, which organisation’s engineers make the mitigation decisions, and what is the escalation path between them and you? Our interview with Derek Raines of GigeNET is a useful read on how a network operator actually thinks about that chain of responsibility.

Check 2: will they mitigate your traffic or blackhole your IP?

Remote-triggered blackholing is the cheapest mitigation in existence. The provider tags your address with the well-known BGP BLACKHOLE community defined in RFC 7999, upstream networks drop everything destined for it, and the attack traffic stops at the border. The attack also stops reaching you. From the outside, a null-route and a successful flood are indistinguishable.

The permission to do this is usually already in the contract. Acceptable use and fair-use clauses in hosting agreements commonly allow suspension, null-routing or forced migration when an attack on one customer degrades service for neighbours on the same edge. A realistic version: a few gigabits per second of UDP reflection aimed at a single tenant starts affecting the shared uplink, the provider blackholes that one address, and the customer reads a ticket reply describing a total outage as successful mitigation.

Settle four points before signing. What traffic level or condition triggers a blackhole; how long the null-route stays in place by default; who authorises its removal and how quickly; whether you are notified at the time and whether there is a charge. Dedicated hardware, dedicated IP ranges or bring-your-own-address arrangements change the calculus, because your traffic is no longer a nuisance to someone else’s tenants. If the provider cannot commit to filtering rather than dropping, a separate cloud DDoS scrubbing service in front of the hosting is the cleaner fix, even though it costs more.

Check 3: is anything above layer 4 actually protected?

Hosting-level filtering watches bandwidth and packet rates, because that is what network appliances are built to see. Do the arithmetic on a request flood and the gap becomes obvious: around 10,000 HTTP requests per second against a search or basket endpoint, each request a kilobyte or two, amounts to a couple of hundred megabits per second. On a 10 Gbps edge that is background noise. The PHP worker pool, the database connection limit and the cache miss path are what fall over, while every network threshold stays untouched and no alarm fires.

Application-layer cover needs request rate limiting per client and per endpoint, caching that absorbs repeated requests, challenge logic for suspicious clients, some form of bot scoring, and a human who tunes all of it against your traffic patterns. Ask who owns that tuning. “Layer 7 is out of scope”is an honest answer. “Here is a self-service panel”means the rules are yours to write and troubleshoot at 03:00. The seven gaps we document in application layer DDoS protection are mostly ownership failures rather than technology failures.

Then there is the trade-off no pricing page mentions. Aggressive rules and interstitial challenge pages block real customers, break payment callbacks, upset mobile apps with pinned certificates and strangle partner API integrations that do not run a browser. Whoever signs the contract should know who carries that false-positive risk, and who is allowed to switch a rule off when conversion drops.

Check 4: who protects your authoritative DNS?

DNS arrives free with the hosting account, which is exactly why it sits outside the protection scope. A perfectly reachable server behind an unresolvable domain is still an outage, and the recovery is slower because you cannot move traffic without the very records that are unreachable.

Confirm four things in writing: whether the nameservers are anycast or single-site, how many distinct networks and locations serve your zone, whether query floods are rate-limited or filtered at those nameservers, and whether DNSSEC signing is supported. Two nameserver hostnames on the same subnet in the same data centre is one network wearing two names.

Secondary DNS with a second operator is the pragmatic answer for most buyers, and it costs little. Plan your TTLs alongside it: records at 300 seconds give you room to move traffic to an alternative origin in minutes, while a 24 hour TTL commits you to a day of whatever you chose last week. Before you sign, query each advertised nameserver directly for your zone (dig @ns1.example.net yourdomain.co.uk SOA) and check the IPs against the ASN data from Check 1. If every nameserver answers from one network, you have a single point of failure dressed as redundancy.

Check 5: can anyone reach your origin directly?

When protection is bypassed, the cause is usually not attack volume. The attacker simply found the server address and attacked that instead of the protected hostname. Data centre DDoS protection applied at the proxy or scrubbing layer cannot filter traffic that never passes through it.

Origin addresses leak from predictable places: historical DNS records held by passive DNS services, Certificate Transparency logs containing certificates issued for a direct IP or a forgotten subdomain, outbound mail headers that carry the sending server’s address, status pages and staging hosts pointed straight at the box, and verbose error pages that print internal hostnames.

The hardening is unglamorous and the provider should support all of it: an origin firewall that accepts traffic on web ports only from the published proxy or scrubbing ranges, a change of server IP after migration behind a proxy so the old address in historical records is dead, outbound mail routed from a separate address or relay, and no certificate issued to the bare IP. Ask for evidence rather than assurance. A firewall rule export, the current allowlist of upstream ranges, and a connection attempt to the origin IP from an arbitrary network that times out are all proof. A support agent saying “the server is protected”is not.

Check 6: what does “managed”commit them to in writing?

The dividing line is simple. If nobody on the provider’s side is empowered to change mitigation policy at 03:00 on a Sunday without your sign-off, you have bought monitoring, not management.

Read the SLA clock carefully. “Time to mitigate measured from detection by our monitoring”and “time to mitigate measured from receipt of a customer notification”are different products at a similar price. On a shared platform, detection is often triggered by aggregate edge traffic rather than by anomalies on your specific service, which is precisely how the request flood in Check 3 stays invisible until a customer complains. Ask what counts as detection for your IP, and what the clock does while a ticket sits in a queue.

Then the human questions. Which phone number reaches an engineer out of hours, which of your named contacts are pre-authorised to request mitigation changes without a purchase order, and how do they authenticate when your own mail is down? After the event, ask for a real attack report: vectors with a breakdown by protocol, peak packet and request rates, the mitigation actions applied and their timestamps. A screenshot of a traffic graph is not a report. If you are still working out whether an incident was an attack at all, our walkthrough on telling a DDoS apart from an ordinary outage is the faster diagnostic.

Price the fine print too: charges per protected IP, clean bandwidth overage rates, contract length and notice period, and how painful migration out would be once your DNS, certificates and firewall allowlists are tied to that platform. Build the business case from your own numbers. Revenue or contractual penalty per hour, multiplied by a realistic worst-case outage, compared against the monthly difference between a basic protected VPS and dedicated mitigation with named response commitments. The NCSC’s warnings about sustained hacktivist campaigns against UK organisations, covered in our seven-step response to the NCSC hacktivist DDoS alert, make the worst case less hypothetical than it looked a few years ago.

Frequently Asked Questions

Is a DDoS protected hosting provider enough on its own?

For a single website or game server with a low cost of downtime, often yes, provided layer 7 is genuinely in scope and the provider will filter rather than null-route. For anything with revenue or statutory obligations attached, hosting-level filtering is one layer among several: it needs authoritative DNS that is separately resilient, a locked-down origin, and a tested escalation route to a human.

What is the difference between DDoS protected hosting and a cloud scrubbing service?

Protected hosting filters traffic at the edge of the network your server already sits on, and the scope is whatever that provider chooses to cover. A cloud DDoS scrubbing service is bought separately and diverts traffic to the vendor’s scrubbing centres, either by pointing DNS at a reverse proxy or by rerouting your own BGP prefixes, and it travels with you if you change host. Scrubbing usually costs more and comes with firmer response commitments.

Can a hosting provider null-route my IP during an attack?

Yes, and most acceptable use policies explicitly allow it when an attack on one customer degrades service for others on the same infrastructure. The remedy is contractual rather than technical: agree in advance what triggers a blackhole, how long it lasts, who can lift it and whether you are notified.

Does DDoS protected hosting include my authoritative DNS?

Usually not. Nameservers bundled with a hosting account are frequently single-site and outside the advertised protection scope, so confirm whether they are anycast, how many separate networks answer for your zone, and whether secondary DNS with a second operator is available.

What should I ask a DDoS protected hosting provider before signing?

Which ASN announces your IP space and which mitigation platform filters it; what triggers a null-route and who lifts it; whether layer 7 is in scope and who tunes the rules; who protects authoritative DNS; how the origin is restricted to proxy or scrubbing ranges; and whether the SLA clock starts at their detection or your ticket. Get the answers in writing before the contract, not during the attack. Further background on attack trends and vendor practice is collected across DDoSInfo.

NCSC Hacktivist DDOS Warning: A 7-Step Response

The NCSC hacktivist DDoS warning has been read, filed and forwarded inside a lot of UK organisations over the past two years, usually with a covering note that says “for info”and a promise to raise it at the next security working group. Filing it is not a response. The warning describes a threat that is cheap to launch, picked by sector list and announced on Telegram before and after the fact, which means the organisations it names can be hit on a Thursday evening without anyone having placed a single order with a mitigation provider.

What follows is a seven-step plan to move from “we read the alert”to a position where your network, application and DNS surfaces are each covered, your origin address is not leaking, and somebody named can authorise mitigation at two in the morning.

What the NCSC hacktivist DDoS warning actually says, and who it applies to

In April 2023 the National Cyber Security Centre (NCSC) issued an alert about an emerging threat to UK critical national infrastructure from state-aligned groups sympathetic to Russia’s invasion of Ukraine. The substance was unambiguous: these actors are ideologically rather than financially motivated, less predictable than criminal crews because they are not negotiating for money, and most capable of distributed denial-of-service (DDoS) attacks, website defacement and the spread of misinformation. The NCSC has repeated versions of that assessment since, and its published denial-of-service guidance has been the practical counterpart to it.

Self-described pro-Russia groups, NoName057(16) and Killnet among the most publicised, have claimed large numbers of DDoS attacks against European government, transport and financial websites. Attribution and genuine command relationships remain an open question, and should be treated as one. The operational picture is clearer than the political one.

“Low sophistication”is not “low impact”

Most coverage repeats the phrase low sophistication and moves on, which leaves readers with the impression that the risk is cosmetic. It is not, because impact depends on when the service is unavailable rather than for how long. Take a council planning portal with a statutory consultation closing at 23:59. A twenty-minute application-layer burst starting at 23:40 does more damage in legal and reputational terms than a two-hour volumetric flood on a quiet Sunday afternoon. Same attacker, same toolkit, wildly different consequence.

Anywhere you have a published availability commitment, a regulatory reporting window, a payment cut-off or a same-day deadline, you have converted a nuisance into an exposure.

Who is in scope beyond the named sectors

The alert named critical national infrastructure, but the practical target list is wider: hosting providers, SaaS suppliers, payment partners, parcel and booking platforms, and anyone whose logo appears on a target organisation’s website. Groups chasing visible disruption frequently hit a supplier as a proxy for the body they actually want to embarrass, because the supplier is usually smaller, less defended and still produces a usable screenshot. If your customer is a government department, you are on the list whether or not you consider yourself part of the sector. That dynamic is one reason DDoS attacks on government websites keep succeeding even where the department itself is well protected.

Steps 1 and 2: map your three attack surfaces, then find the one nobody owns

Before anyone buys anything, write down three surfaces and the name of the person or supplier who manages each. In this order: network and transport (your IP ranges and transit), application layer (HTTPS endpoints, APIs, login flows), and authoritative DNS.

Step one is producing that one-page map. Step two is the uncomfortable part: finding the surface with no owner. In practice it is almost always DNS. An organisation reads an NCSC alert, buys a reverse proxy for the main website, ticks the box, and leaves the zone sitting on a registrar’s default nameservers with no secondary provider. Take out name resolution and the proxy becomes irrelevant, because nobody can resolve the hostname that points at it. If you are reviewing that surface for the first time, our buyer’s guide to authoritative DNS DDoS protection sets out what a second provider should actually give you.

On the application layer, list the endpoints where one request costs you far more than it costs the attacker: site search, postcode and address lookup, PDF or report generation, basket calculations, login and password reset. A hacktivist tool sending a few thousand requests per second at a search box can saturate a database tier that shrugs off ten times the traffic against static pages. That asymmetry, rather than raw bandwidth, is what the real gaps in application-layer protection tend to come down to.

Step 3: close origin IP leakage before you trust your proxy

When a proxy is bypassed during these campaigns, the cause is rarely attack volume exceeding scrubbing capacity. It is nearly always a leaked origin address. Attackers do not need a zero-day for this; they need a search engine and twenty minutes.

Audit the usual leak paths, which are predictable enough to work through as a checklist: historical DNS records for the domain and its subdomains; certificate transparency log entries that expose internal and staging hostnames; mail servers, VPN concentrators or FTP hosts sitting on the same /24 as the web origin; old dev, uat and test hostnames still resolving to the real server; and error or debug pages that print a backend IP address in a stack trace.

The fix is free and routinely skipped. Lock the origin firewall so it accepts HTTP and HTTPS only from your provider’s published IP ranges, rotate the origin address after onboarding so the pre-proxy history is worthless, and re-check the ranges quarterly because they change. Then verify it rather than assuming: from a host outside those ranges, attempt a direct connection to the origin address on 80 and 443 and confirm it is refused or dropped. An untested allow-list is a belief, not a control.

Steps 4 and 5: choose always-on or on-demand, then time the escalation path

Step four is the architectural decision. Hacktivist activity tends to arrive as short, repeated bursts timed for attention: fifteen minutes, a pause, another ten minutes, then again the following evening. That pattern punishes on-demand models badly. If diversion depends on somebody noticing, somebody else authorising, and a BGP announcement propagating, the burst can be over before traffic reaches a scrubbing centre, and you will have paid for mitigation that arrived after the screenshot.

Advertised capacity in terabits per second is the least useful number in most sales decks for this threat profile. Time-to-mitigate is the variable that decides the outcome. Read the service level agreement carefully and establish what starts the clock: detection by the provider’s own monitoring, or receipt of a notification from you? Those two wordings can differ by half an hour of real downtime. Capacity still matters for other scenarios, and the arithmetic behind a terabit-scale DDoS attack is worth understanding, but it is not the constraint that loses you a 23:59 deadline.

Step five is testing the human path, which costs nothing. At 21:00 on a weekday, ring the provider’s network operations centre number, authenticate as you would during a live incident, and request authorisation for a simulated diversion. Time every stage: ring to answer, answer to authentication complete, authentication to a named engineer confirming they can change policy. Write the total down. That figure, not the SLA, is your real time-to-mitigate, and it is the single most persuasive document you can take into a renewal negotiation. Run the same drill when key staff change.

Step 6: pressure-test what “managed”means in your contract

The word managed carries no fixed meaning in DDoS contracts. If a human on the provider’s side is not empowered to change policy at 03:00 without waiting for your sign-off, you have bought monitoring, not management.

Insist that four things appear in writing: onboarding and initial rule tuning; ongoing traffic baselining so anomalies are measured against your normal; a named escalation matrix with authority levels and out-of-hours contacts; and an explicit statement of who applies changes during an attack. Then ask the resale chain question, because it decides minutes on the mitigation clock. Whose network and scrubbing capacity are you actually buying, and how many organisations sit between your phone call and the engineer typing the rule? Three handoffs at 02:00 is not a hypothetical problem.

Before signing, ask to see a redacted report from a real mitigated attack. It is the cheapest competence signal available. A good one names the vectors with a breakdown by volume, shows source distribution, records mitigation timestamps against detection timestamps, and lists the rules applied and why. A traffic graph with a reassuring dip in the middle tells you nothing. Treat SLA credits with the same scepticism; a credit worth a month’s fee does not cover a missed statutory deadline, and the realistic view of what the different DDoS protection models cost in the UK is a better planning input than a credit table.

Step 7: write the first hour down, then rehearse the communications

Step seven is a one-page runbook, not a plan document nobody opens. Five lines will do: confirm it is an attack rather than a self-inflicted outage; capture evidence; notify the provider through the escalation path you timed in step five; publish a holding status message on infrastructure entirely separate from the affected site; brief internally. The first line matters more than people expect, because a failed deployment and a layer-seven flood look identical on a monitoring dashboard for the first few minutes, and the question of DDoS or ordinary outage changes who you call.

Evidence capture is the step skipped under pressure and regretted afterwards. Keep timestamped web and load balancer logs, netflow or sampled packet captures, and the provider’s attack report. Unauthorised acts that impair the operation of a computer fall under sections 3 and 3ZA of the Computer Misuse Act 1990, and that evidence is what makes a referral to the NCSC and a report to Action Fraud usable months later rather than an anecdote.

On communications, two rules. Claimed victories on Telegram routinely overstate impact, so check independently whether the service was actually unavailable, ideally from outside your own network, before accepting the attacker’s version. And do not respond publicly to the group. Visible disruption and a reaction are the point of the exercise; a quiet, factual status update starves the campaign of the thing it wants. Decide in advance who speaks to the press, the regulator and the board, and what they may say while the incident is live. Usually that is confirmation of a service issue, no speculation on attribution, and no capacity or architecture detail.

Budgeting your response to the NCSC hacktivist DDoS warning

Price the downtime before pricing the protection. Lost transactions per hour, staff hours burned, the cost of a missed statutory deadline, and the slower reputational drag of a service being seen to fall over. That number sets your sensible ceiling, and it is frequently lower than vendors hope and higher than finance assumes.

Where the money goes: an always-on proxy for web and API traffic; a BGP scrubbing retainer if you announce your own ranges; a secondary authoritative DNS provider; and engineering time for web application firewall tuning, which is the line most often underfunded. The forgotten items are clean traffic or egress charges during an attack, onboarding fees, change request charges once rules need adjusting, and out-of-hours escalation premiums. Ask for all four in writing before you compare quotes.

On a constrained budget, sequence by cost. Steps one, two, three and five are mostly attention rather than money: the surface map, the ownership gap, the origin lock-down and the out-of-hours drill. Do those this quarter. Secondary DNS is usually modest. The always-on versus on-demand decision and the contract renegotiation can wait for the next budget cycle, armed with the drill timings you recorded. Groups whose motives run to publicity rather than profit behave in fairly predictable ways once you understand what they are optimising for, which is what makes a staged response reasonable rather than reckless.

Frequently Asked Questions

What does the NCSC hacktivist DDoS warning actually advise organisations to do?

The NCSC’s April 2023 alert on state-aligned groups sympathetic to Russia’s invasion of Ukraine asked critical national infrastructure operators to act on its existing resilience guidance rather than wait for a specific threat. In DDoS terms, that means understanding your public-facing surfaces, having mitigation arranged in advance, and knowing your escalation path. The NCSC’s published denial-of-service guidance is the practical companion to the alert.

Does the NCSC hacktivist DDoS warning apply to private suppliers, not just government bodies?

In practice, yes. Groups seeking visible disruption often target a supplier, hosting provider or payment partner because it is easier to knock over than the organisation they want to embarrass, and the outage still generates the headline. If your name or logo appears on a target’s site, treat yourself as in scope.

How big are hacktivist DDoS attacks in practice, and does size matter most?

Typically they are short, repeated bursts rather than sustained terabit floods, and frequently application-layer rather than purely volumetric. Size is not the variable that decides the outcome; how quickly mitigation engages is. A modest attack that runs unmitigated for twenty minutes during a deadline window beats a large one that is scrubbed in sixty seconds.

Should we switch to always-on mitigation because of the warning?

If your exposure includes deadline-bound or transactional services, always-on protection for web and API traffic is the stronger fit, because on-demand diversion and BGP propagation delay can exceed the length of the burst. If your public services are informational and tolerate a short interruption, an on-demand retainer may be proportionate, provided you have timed the real escalation path rather than trusting the SLA wording.

Who should we report a hacktivist DDoS attack to in the UK?

Report cyber incidents to the NCSC, and report the crime to Action Fraud, or to Police Scotland on 101 in Scotland. Regulated organisations may also have sector reporting duties with timescales of their own. Keep timestamped logs, netflow samples and the provider’s attack report, since that evidence is what supports any later action under the Computer Misuse Act 1990.

DDOS Attacks on Healthcare Providers: 6 Weak Points

Picture the first Tuesday clinic of the month at a district general hospital: twenty-eight outpatient slots booked through a third-party portal, a pathology feed arriving over SFTP from a regional lab, community nurses logging in through a VPN concentrator that was sized in 2019, and a website that quietly stopped being the trust’s problem the day the original web agency took over the domain. Then the portal stops answering. DDoS attacks on healthcare providers rarely succeed because the traffic volume was extraordinary; they succeed because one of those components had no owner, no mitigation and nobody awake to act on it.

This piece does not rehearse sector statistics. It names the six places UK health estates actually break during a denial-of-service event, and what to put in a contract so they do not break twice.

Why health estates fall over at volumes other sectors absorb

A bank runs its own autonomous system, its own IP space and a security operations centre with a rota. A trust runs a federation. The main website might sit with a regional NHS host, the patient portal with a clinical software vendor, e-referral with another, video consultation with a third, the integration engine on a virtual machine in a shared data centre, and the authoritative DNS wherever it was parked a decade ago. Six owners, six contracts, six different answers to the question of who is allowed to phone a mitigation provider at 02:00.

The damaging outcome in a clinical setting is not data theft. It is unavailability. A booking engine that is unreachable for ninety minutes produces paper fallback, phone triage, a clinic list worked from printouts, and a rebooking backlog that is still being cleared weeks later. Ambulance diversion is the extreme case, but the ordinary case is quietly expensive: consultant time burned on a stalled list, administrative overtime, and appointment slots that cannot be recovered because the capacity simply does not exist.

Motive shapes the target, not the size of the pipe

Hacktivist pressure campaigns pick targets for visibility, which means public-facing portals and anything with a recognisable name. The US Department of Health and Human Services’ Health Sector Cybersecurity Coordination Center (HC3) published an analyst note in January 2023 on the pro-Russian group KillNet targeting the health sector with denial-of-service attacks, and pro-Russian groups have since claimed attacks against European public sector sites. Ransom-motivated actors behave differently: they time the disruption around a known pressure point, such as a winter surge or the first working day after a bank holiday, and they test which surface hurts most. Reading the motive early tells you whether to expect a short noisy burst or a sustained campaign, which is the practical value of understanding what hacktivist attack motives predict.

Weak point 1: authoritative DNS that nobody in the trust owns

Ask an information governance lead who manages the trust’s authoritative nameservers and the answer is often a pause. The zone is frequently still with the agency that built the original site, or inside a legacy hosting account whose billing contact left in 2018. Domain Name System (DNS) is the layer most reliably left unmanaged in health estates, and it is the one with the widest blast radius.

A query flood against a single authoritative provider does not take down one website. It takes down every name in that zone at once: the patient portal, staff email routing, the identity provider used for single sign-on, and any API hostname your suppliers resolve. Web application firewalls and reverse proxies are irrelevant at that point, because nothing ever resolves far enough to reach them.

Three practical steps. Inventory every zone the organisation depends on, including the ones registered by departments and charities under your name. Check whether you have genuinely diverse authoritative nameservers (two providers, separate anycast networks, not two hostnames on one platform). Set time-to-live values you can actually work with during an incident, because a 24-hour TTL means your emergency change takes a day to propagate. The detail of provider selection is covered in this buyer’s guide to authoritative DNS protection.

Questions worth putting to your DNS host in writing: what query-per-second capacity do you provision per customer, how many points of presence carry our zone, and who answers the phone at 02:00 on Boxing Day?

Weak point 2: origin IP leakage behind the patient portal

Proxy bypass is the most common way a protected site falls over, and it is almost never a capacity problem. The attacker has simply found a route that goes around the proxy entirely.

Health estates leak origins in predictable places: an old A record for a decommissioned booking subdomain that still points at the real server, a UAT or staging environment on the same subnet, a mail host sharing the range, a certificate transparency log entry naming an internal hostname, or a PDF and imaging endpoint serving large files straight from the origin because someone excluded it from the proxy for performance. Attackers enumerate those first. Appointment booking and repeat prescription ordering are the endpoints they probe hardest, because both are expensive per request on the back end.

The fix is unglamorous. Lock the origin firewall to the proxy’s published address ranges, deny everything else, then verify it from outside your network rather than assuming the rule works. Re-verify after every migration. Application-layer protection is only as good as the path discipline underneath it, which is the recurring theme of these application layer protection gaps.

Weak point 3: clinical SaaS and integration layers outside your contract

Most clinical availability depends on networks the trust does not control. Booking engines, e-referral, remote patient monitoring, pathology result delivery, prescription services and video consultation platforms all sit on someone else’s infrastructure, often in shared tenancy where an attack aimed at a neighbour can degrade your service.

Protection so belongs in supplier contracts, not only in your own hosting arrangement. Insist on four things in writing: the named mitigation provider and the underlying network doing the scrubbing; a stated time to mitigate with the conditions under which the clock starts; a notification duty within a defined window when the supplier is under attack; and a written post-attack report with a vector breakdown.

Then do the mapping exercise. Take each clinical pathway and ask what happens if that one supplier is unreachable for two hours on a weekday morning. Some pathways degrade gracefully. Others stop. The ones that stop are the ones to argue about at contract renewal.

Weak point 4: remote clinician access and the network edge

VPN concentrators, remote desktop gateways and session brokers are low-capacity choke points sitting in front of high-value work. A state exhaustion attack fills the session table or the TLS handshake queue while using a fraction of the link’s bandwidth. Your monitoring shows the circuit at 12 per cent utilisation and the clinicians cannot log in. That combination causes more wasted triage time than any volumetric flood.

Reverse proxy protection does nothing here, because none of this is HTTP traffic you can route through a content delivery network. If your organisation holds its own IP space and autonomous system number, Border Gateway Protocol (BGP) based scrubbing covers the whole range, including SFTP result feeds, HL7 interfaces and API endpoints. If it does not, you need per-service protection from whoever owns the addresses, and you need to know that before an incident rather than during one.

Weak point 5: on-demand mitigation that misses clinical timeframes

On-demand mitigation sounds economical. Detection, then a BGP announcement, then route convergence, then traffic actually arriving at the scrubbing centre. Each step costs real minutes, and minutes map directly onto cancelled slots during a running clinic.

Read the service level agreement for what triggers the clock. A “15 second time to mitigate”usually assumes always-on traffic baselining, pre-agreed thresholds and signed-off authorisation; without those, the clock starts when a human on your side raises a ticket and gets authenticated. Ask who in your organisation is authorised to trigger mitigation out of hours, and check that person exists on an August bank holiday weekend. Many escalation matrices name a role rather than a rota.

Diversion has trade-offs worth stating openly: added latency on every clinical session, asymmetric routing that can break stateful appliances, and services (voice, some VPN tunnels, IP-allowlisted supplier feeds) that fail when source addresses change. Test those before you need them, not at 09:15 on a Monday.

Weak point 6: a ‘managed’ contract that is really a portal login

The dividing line is simple. Managed means onboarding and rule tuning against your real traffic, a tested runbook, a named escalation path and an engineer empowered to change policy during the attack without waiting for your ticket. If nobody on the provider’s side can act without your sign-off, you have bought monitoring, not management, and out of hours that means nobody acts at all.

In public sector procurement the resale chain matters. The logo on the quote is often not the network doing the scrubbing; capacity, peering and support hours frequently belong to a provider two steps down the chain. Ask who operates the scrubbing centres, where they are, and whether support is in-house or subcontracted overnight. Then judge on evidence: sample post-attack reports with real vector breakdowns, references from organisations of comparable size, and a straight answer on how false positives are handled.

Healthcare tuning has one rule generic providers get wrong. Never rate-limit a clinician into a locked-out state. Hospital networks present hundreds of users behind a handful of NAT addresses, kiosk browsers carry odd user agents, and automated feeds (results, device telemetry, interoperability polling) look exactly like scripted abuse to a default ruleset. Allowlist them deliberately, by source and by behaviour, before go-live. General principles on how denial-of-service attacks work and how they are mitigated are a useful grounding for the governance papers that accompany this sort of procurement.

Building the business case and surviving the first hour

Price the downtime before you price the protection. Take one cancelled outpatient list: the lost slots, consultant and nursing time spent on paper fallback, administrative overtime, out-of-hours recovery, and the rebooking backlog that spreads across the following weeks. Put a figure against it using your own costing data, then set that beside an annual protection contract. That comparison persuades finance directors; fear does not.

UK managed protection is usually priced on a committed bandwidth or protected-IP basis with a monthly fee, plus onboarding, and often with burst or overage charges once attack traffic exceeds a threshold. The line items buyers forget at first invoice are additional protected subnets, extra portal users, out-of-scope incident response hours and the cost of a second mitigation point for DNS. The breakdown in this guide to what UK DDoS protection actually costs is a reasonable starting point for a budget paper.

For the first hour, work in sequence. Confirm it is an attack rather than a failed deployment or an upstream fault, using the approach in this piece on telling a DDoS apart from an ordinary outage. Check three surfaces in order: DNS resolution, the proxy or edge, then the origin and the remote access concentrators. Notify affected clinical suppliers and ask them to confirm their own status. Capture evidence as you go (packet samples, flow records, timestamps, portal screenshots), because reconstruction afterwards is always worse.

Governance follows. Inform the on-call director and the information governance lead, log the incident against the NHS Data Security and Protection Toolkit processes your organisation already uses, and consider obligations under the Network and Information Systems Regulations 2018 if your organisation is designated an operator of essential services. UK GDPR Article 32 expects availability and resilience of processing systems, so a sustained outage is a security matter, not only an operational one. Denial-of-service attacks are offences under the Computer Misuse Act 1990, which is the basis for reporting to Action Fraud and, for significant incidents, to the National Cyber Security Centre.

Frequently Asked Questions

Why are healthcare providers targeted by DDoS attacks?

Visibility and urgency. Hacktivist groups choose targets whose disruption gets reported, and health services qualify; HC3 in the United States issued an analyst note in January 2023 about pro-Russian actors targeting the sector. Extortion-motivated attackers pick healthcare because the tolerance for downtime is close to zero, which increases the chance of a fast payment or a fast concession.

Can a DDoS attack on a hospital affect patient care directly?

Yes, indirectly but materially. If booking, e-referral, results delivery or remote clinician access is unreachable, staff revert to paper and telephone, lists slow down and appointments get cancelled. The clinical risk sits mostly in delayed care and the backlog, rather than in any loss of patient data.

Does a patient portal behind a reverse proxy still need network-level protection?

Usually, yes. A proxy only protects traffic that goes through it, so a reachable origin, an exposed UAT host or a mail server on the same range reopens the direct path. Non-HTTP services (VPN, SFTP feeds, HL7 interfaces) are not covered by a web proxy at all.

How much does managed DDoS protection cost for an NHS trust or private hospital group?

Pricing varies by committed clean bandwidth, number of protected IP ranges, always-on versus on-demand, and support hours, so there is no single figure worth quoting. Build the comparison from your own downtime cost per cancelled clinic list, and ask every bidder to quote onboarding, overage and out-of-scope incident hours separately.

What should we do in the first hour of a suspected DDoS attack on a clinical system?

Confirm it is an attack rather than a deployment or upstream failure, then check DNS, the edge and the origin in that order. Notify your mitigation provider and any affected clinical suppliers, start the clinical fallback process, and record evidence with timestamps for reporting to Action Fraud and the NCSC and for any later contractual or legal action.

DDOS Scrubbing Capacity: How to Judge Tbps Claims

Open almost any mitigation provider’s data sheet and the DDoS scrubbing capacity figure sits near the top, in bold, usually followed by a unit that ends arguments: 10 Tbps, 30 Tbps, 200 Tbps and rising. The number is there to close the conversation. It should open it, because the figure on the page and the capacity that will actually stand between your prefix and a botnet on a Tuesday afternoon are rarely the same thing.

Scrubbing capacity means the volume of attack traffic a provider can ingest, inspect and filter before passing clean traffic on to you. Simple enough. The difficulty is that vendors measure it in at least three incompatible ways, and the one they publish is almost always the most flattering.

What a scrubbing capacity figure is actually measuring

Three distinct numbers get printed under the same label.

Total network capacity is everything the provider’s backbone can carry, including transit and content delivery traffic that has nothing to do with mitigation. Aggregate mitigation capacity is the sum of filtering capability across every scrubbing location they operate. Per-centre capacity is what a single site can ingest and clean. Only the third one is about you.

At the time of writing, published figures span two orders of magnitude in framing. Some platforms quote well over 100 Tbps spread across several hundred points of presence; others quote around 30 Tbps across roughly two dozen dedicated scrubbing centres. Do the division before you do anything else. A headline that divides into a few hundred gigabits per location is telling you something very different from one that divides into several terabits, and the fewer, larger model is often the stronger one for a single-region customer. Capacity is never distributed evenly anyway, which is exactly why the next question matters: what is the ingest and mitigation capacity of the specific centre my traffic is diverted to, and what happens when that centre is the one under pressure?

Anycast changes the question

On an anycast platform, a volumetric flood is absorbed wherever the sources are, which is genuinely useful against a globally distributed botnet. It is less useful when the attack sources are concentrated in Europe and your diversion lands in one or two European sites. Aggregate capacity across hundreds of global locations is an architecture statement. It is not a promise about your prefix.

Inside the platform there are also per-customer ceilings that have nothing to do with the network: a clean-traffic commit, a cap on how many protected prefixes or hostnames you may onboard, and in appliance-backed or licensed models a throughput entitlement written into the order form. A 100 Tbps platform will happily enforce a 500 Mbps licence against you.

Where UK traffic lands, and why the nearest centre decides the outcome

For most UK buyers the relevant ingest points are London and Slough, and the relevant peering is at LINX and LONAP. Ask which facility your prefix would be diverted into, what that site’s ingest capacity is, and where it fails over. The answer to the third question is frequently Amsterdam or Frankfurt.

That failover is not neutral. London to Frankfurt is in the region of ten to fifteen milliseconds of round-trip time on a good path, and a checkout flow or a chatty API that makes twenty or thirty sequential calls will show it. Sessions that were comfortable become marginal. Timeouts tuned for in-country latency start firing. You mitigated the attack and still lost conversions, which is a conversation worth having before you sign rather than during an incident.

Data centre DDoS protection sold at the rack deserves particular scepticism. The colocation provider may advertise protection, but the filtering usually happens at an upstream transit provider’s edge or a third-party scrubbing partner, under a contract you have never read, with a threshold you have never been told. Ask who owns the mitigation, not who sold it.

Bits per second is the wrong unit for most real attacks

This is the part buyers underestimate. Forwarding hardware fails on packet rate long before it fails on bandwidth. At minimum Ethernet frame size, a 10 Gbps link carries roughly 14.9 million packets per second; 100 Gbps of 64-byte packets is close to 149 Mpps. Routers, firewalls and intrusion-prevention appliances run out of forwarding capacity and state-table headroom at those rates while the bandwidth graph still looks calm. A flood that never approaches an advertised terabit ceiling can still flatten an edge device.

Carpet bombing exploits the other half of the problem: detection thresholds. Spread a few hundred megabits per second across the 1,024 addresses of a /22 and you have tens of gigabits arriving at the network while no single IP crosses a per-host trigger set at, say, 1 Gbps. Nothing is detected. Nothing is diverted. Detection configuration, in that scenario, matters far more than the headline on the data sheet, and the same arithmetic applies to the terabit-scale attacks that make the headlines.

Layer 7 is a different unit again. Application floods are measured in requests per second and new connections per second, and TLS handshakes are deliberately asymmetric: cheap for the attacker, expensive for your termination point. Gigabits are irrelevant there. The relevant figures are proxy request capacity and policy quality, which is a separate discipline covered in our breakdown of where application layer defences actually fail.

So ask for three numbers, not one: Tbps, Mpps and concurrent sessions or requests per second, per scrubbing centre. Providers who track their own platform properly can answer. The ones who cannot are telling you something.

The contract terms that quietly resize your capacity

A mitigation can succeed technically and still cost you money or availability, because the commercial terms cap what the platform is allowed to deliver.

Clean-traffic commit and overage. You commit to a volume of clean traffic, often billed at 95th percentile. Mitigation works, legitimate traffic keeps flowing, and the invoice arrives with overage at a rate nobody modelled. Check whether attack traffic is excluded from the measurement, in writing.
Black hole thresholds. Lower tiers at hosting and cloud providers frequently protect up to a stated rate and null-route the address above it, usually by announcing it with the BLACKHOLE community defined in RFC 7999. The attacker gets exactly what they wanted, delivered by your own provider. Find the threshold in the plan documentation before you buy, and find out how long the null route stays in place.
Attack-size caps and fair use. “Unlimited mitigation”often carries a clause permitting renegotiation after repeated incidents, or a cap on single-attack volume buried in an appendix.
SLA credits. These are written against time-to-mitigate and availability, never against capacity. No provider refunds you for failing to deliver 30 Tbps.

Those terms, not the engineering, are where most unpleasant surprises live. We have gone through the pricing models in more detail in our guide to what UK DDoS protection really costs.

Whose capacity are you buying?

A large share of UK managed DDoS protection offers are resold. Hosting companies, managed service providers and smaller security firms front someone else’s scrubbing network under their own brand, which is not inherently a problem; it becomes one when nobody in the chain can change a policy during an incident.

Tracing the real network is straightforward. Look up the announcing AS for the protected prefix during and outside mitigation using RIPEstat or any public looking glass. Check the CNAME chain and the name servers. Read the vendor name in the footer of the attack report you are shown. Then ask directly: whose AS announces my prefix when I am under attack, and who has authority to change filtering policy on it?

The dividing line is simple. If a human on the provider’s side cannot adjust policy at 02:00 without hunting for your sign-off, you have bought monitoring, not management. Identical underlying capacity produces very different outcomes depending on who is tuning the signatures, writing the rate limits and making the diversion call, which is also why a clear method for separating an attack from an ordinary outage belongs in the runbook on your side too.

Capacity across all three surfaces, including the one left out

Protection is usually sold for one surface and assumed for three.

Network and transport. BGP diversion to a scrubbing centre, returned over GRE or a cross-connect. This is the layer the Tbps figure describes, and the only one it describes.

Application. Reverse proxy capacity in requests per second, plus WAF rule quality and bot classification. Raw bandwidth tells you nothing here.

Authoritative DNS. Routinely outside the protection contract. A site can sit behind a very large scrubbing platform while its zone is served by a provider with a handful of anycast nodes, making name resolution the cheapest thing in the estate to knock over. Our buyer’s guide to authoritative DNS protection covers what to ask for there.

And then there is origin exposure, which defeats capacity entirely. Proxy bypass is far more often caused by a leaked origin address than by an attack that genuinely outsizes the platform. The usual culprits: an MX record pointing at the same host, an old A record on a forgotten subdomain, historical DNS data, certificate transparency logs listing every hostname you have ever requested a certificate for, and an admin or SSH endpoint reachable on the origin IP. Audit those first. Then restrict the origin to accept traffic only from your provider’s published ranges. Unlimited scrubbing capacity in front of a directly reachable server protects nothing.

Sizing from evidence rather than data sheets

Start with your own numbers, not the vendor’s. Take peak legitimate throughput, peak packet rate and peak requests per second from the last twelve months, add realistic growth headroom, and work out what an hour of downtime costs in revenue, transaction value, contractual penalties or statutory deadlines missed. Public sector and regulated services often find the deadline matters more than the revenue. The NCSC’s denial of service guidance makes the same underlying point: understand what normal looks like for your service before you try to specify protection for it.

Then decide between always-on and on-demand. On-demand is cheaper and introduces a diversion window governed by detection time, BGP convergence and, for DNS-based redirection, your record TTL. Always-on removes that window and costs more every month. Compare the monthly difference against the cost of the diversion window, not against an abstract preference for one architecture.

Pre-contract checklist

Named ingest locations serving UK prefixes, with per-centre capacity and the designated failover site.
Published Mpps and concurrent-session or requests-per-second limits, not just Tbps.
Per-IP and per-prefix detection thresholds, and how carpet bombing across a /22 is detected.
Any black hole or null-route threshold in your tier, in writing, with the removal process.
Clean-traffic commit, overage rate and whether attack traffic is excluded from billing.
Time-to-mitigate definition, measured from what event, with the SLA credit mechanism.
A redacted post-incident report from a real mitigation, with the vector breakdown.
The escalation matrix: named contacts, out-of-hours route and who authorises diversion.
The announcing AS during mitigation, confirming whose network you are buying.

Run that against every quote. A provider with genuine DDoS scrubbing capacity behind the marketing will answer all nine in a single call; the ones who keep returning to the headline terabit figure are telling you where their confidence actually sits.

Frequently Asked Questions

What does DDoS scrubbing capacity actually mean?

It is the volume of attack traffic a provider can ingest, inspect and filter before forwarding clean traffic to you. The complication is that the published figure may describe total backbone capacity, mitigation capacity summed across every location, or the capacity of one scrubbing centre. Only the last of those relates to what protects your prefix.

Is a higher Tbps figure always better protection?

No. A larger aggregate spread thinly across hundreds of locations can leave less capacity at the specific site serving your traffic than a smaller platform with a few large centres. Packet rate, detection configuration, policy tuning and contract terms all decide outcomes that bandwidth alone does not.

How much scrubbing capacity does a typical UK business need?

Size it against your own peak legitimate throughput and packet rate with growth headroom, rather than against the largest attack in the news. For most organisations the binding constraints are the per-customer commit, the detection thresholds and whether the origin is reachable directly, not the platform ceiling.

What is a black hole threshold and how does it limit mitigation?

It is a rate above which your provider stops filtering and simply discards all traffic to the targeted address, usually by announcing it with the BLACKHOLE community from RFC 7999. The attack stops reaching your network and so does everything else. Entry-level hosting and cloud plans commonly include one, so check the documented threshold and the removal procedure before buying.

How can I check whose scrubbing network my provider is really using?

Look up the announcing autonomous system for your prefix on a public looking glass or RIPEstat, follow the CNAME and name server chain, and read the vendor name on any attack report you are given. Then ask the provider directly who announces your prefix during mitigation and who is authorised to change policy out of hours.

Law Firm Cyber Attack Protection: Beyond Phishing

Law firm cyber attack protection, as it is sold and as it is bought, nearly always means email: a filtering gateway, phishing simulations twice a year, a mandate fraud warning on the completion statement, and a cyber policy with a conveyancing fraud sub-limit. That half of the problem has had a decade of attention, and most UK firms have genuinely improved. The other half has had almost none. Nobody at renewal asks what happens when the client portal, the document exchange and the firm’s authoritative DNS all stop answering at three o’clock on a Friday afternoon.

That is the gap this piece is about: availability, how it fails, and how to buy and verify protection for it without taking a vendor’s word for anything.

What attackers actually target in a law firm, and the half nobody covers

The confidentiality attacks are familiar. Business email compromise, invoice and mandate redirection on completion funds, credential theft against Microsoft 365, ransomware that encrypts a file share and the backups sitting on the same domain. Firms have bought tooling and training against all of it, and insurers have pushed hard in the same direction.

Availability attacks sit outside that conversation entirely. They include volumetric floods against the public website; request-level attacks aimed at the login flow and search function of a client portal or document exchange; attacks on the authoritative nameservers that publish every hostname the firm uses; and extortion emails demanding payment in cryptocurrency to stop, sometimes preceded by a short demonstration burst against the marketing site.

Legal is an attractive target for both motives, and for different reasons. Work is deadline-bound, so an outage has a hard commercial edge that an attacker can time. Clients in litigation and corporate transactions are acutely sensitive to any sign that the firm is unstable. And high-value matters are often publicly visible, from planning objections to M&A announcements, which gives an aggrieved party a clear target and a clear window. One UK practice found its systems disrupted badly enough by a flood of inbound mail that it rebuilt its web security afterwards, which is a reminder that the trigger is not always sophisticated and rarely announces itself in advance.

Mapping your own exposure in an afternoon

Before anyone looks at a quote, build four columns. Every client-facing hostname the firm owns, including the ones marketing created and forgot; who hosts each one; who runs the DNS for the zone; and the name and mobile number of the person you would ring about it at two in the morning. Most firms cannot complete column four for at least one row. That blank is the finding.

The three surfaces law firm cyber attack protection has to cover

Network and transport floods

These are the attacks discussed in gigabits per second, occasionally terabits. A decent hosting provider or ISP absorbs the small end without telling you. What they will not do is carry a sustained attack aimed at your single public IP address, because at a certain point the economically rational move is to null-route you to protect everyone else on that segment. Blackholing is not mitigation. It is the provider agreeing with the attacker.

Application-layer attacks

This is where portals actually fall over. A few thousand well-chosen requests per second against a document search, a login endpoint that does a bcrypt hash on every attempt, or a matter-lookup page that runs an unindexed query, will exhaust the database long before anything registers on a bandwidth graph. Protection sized purely on gigabits of clean traffic will sail through a volumetric flood and still let the conveyancing portal die quietly. Understanding the gaps in application-layer defences matters more for a law firm than headline scrubbing capacity, because the valuable systems are all request-driven.

Authoritative DNS, the layer nobody has reviewed

Ask who controls the firm’s nameservers. In a worrying number of practices the answer is a web agency’s registrar account, sometimes a former IT supplier’s, on a single DNS provider, with no secondary nameservers and no monitoring. Lose that and nothing else in the stack matters: the portal, webmail, the marketing site and any MX-dependent mail flow all stop resolving at the same moment, and the shiny proxy in front of the website never sees a packet. Redundancy here is cheap and badly under-bought; a second authoritative DNS provider is usually the highest-value hour of work available to a firm this week.

Third-party dependencies you do not control

Practice management SaaS, e-signature platforms, hosted document portals and card payment pages all inherit someone else’s protection posture. Your Lexcel file says you have business continuity; your supplier’s contract may say they will use reasonable endeavours. Those are not the same sentence. Put the question in writing to each supplier at renewal and keep the answer.

Why the proxy gets bypassed: origin IP leakage, not attack size

When a protected site goes down, the cause is far more often that the attacker found the origin than that they out-muscled the scrubbing network. The firm’s real server address leaks through routes nobody audits: the MX record, SPF entries listing the mail server, historical DNS records archived by passive DNS services, TLS certificate transparency logs that publish every hostname you have ever certificated, a webmail or VPN endpoint sitting on the same /24 as the web server, or a staging site at new.firmname.co.uk that resolves straight to the origin and has done since 2021.

The test is one question, and it is a yes or no. Does the origin accept TCP connections on 80 and 443 from anything other than the protection provider’s published IP ranges? If yes, the protection in front of the site is decorative. Three fixes, in order: allow-list the provider’s ranges at the host firewall or security group and drop everything else; validate the host header and a shared secret header at the web server so direct hits are rejected; and rotate the origin IP address after onboarding, because the old one is already in a passive DNS database somewhere.

Attack volume is the part vendors like to talk about. Reachability is the part that decides the outcome.

Extortion and the first hour

Triage before escalation

Not every Friday outage is an attack. A bad deployment, an expired certificate, a hosting provider’s own incident and a legitimate traffic spike from a press mention all look identical from reception. Check from outside the network, not from a machine on the office LAN; compare the web server’s request logs against the load balancer’s; look at whether the source addresses are geographically scattered and hitting one expensive URL repeatedly. Having a short, written routine to tell a DDoS from an ordinary outage saves the twenty minutes that usually get burned arguing.

If a ransom demand arrives

Paying achieves nothing reliable. Payment marks the firm as responsive to pressure, and the group that sent the email may not be the group capable of stopping the traffic. Preserve instead: the email with full headers, the exact timestamps of the first and peak traffic, sample requests and source data from the logs, and the provider’s post-attack report with its vector breakdown. That evidence is what makes any later legal or law enforcement route viable rather than theoretical.

Reporting duties

Four obligations sit in different places and a firm should know which apply before the day arrives:

The SRA Standards and Regulations require prompt reporting of serious breaches of the regulatory arrangements, which can include an incident that materially affects the firm’s ability to act for clients;
UK GDPR requires notification to the Information Commissioner’s Office within 72 hours of becoming aware of a personal data breach where there is a risk to people’s rights and freedoms, and the ICO is explicit that a loss of availability counts as a breach, not just unauthorised disclosure;
Clients on live matters need telling, in plain terms, where a deadline or completion is affected, and that message is better coming from the partner than from an estate agent;
Action Fraud takes the crime report, and the National Cyber Security Centre should be notified where the incident is significant.

Denial of service is a criminal offence in the UK under section 3 of the Computer Misuse Act 1990, which covers unauthorised acts intended to impair the operation of a computer. Useful to know, and worth stating to staff who assume this is a grey area. Realistically it does not shorten your outage by a second, and attribution is slow, so treat the criminal route as evidence preservation rather than recovery.

Buying protection: deployment models, managed meaning, and the cost case

Three models, and the choice is mostly determined by what the firm owns. Reverse proxy suits the common case: one marketing site, a client portal, a document exchange, all behind DNS you can repoint, with no IP space of your own. BGP scrubbing is for firms announcing their own prefix, typically those running an on-premises data room or legacy case system, and it protects everything in the range including mail and VPN. Hosting-level filtering is the cheapest and the weakest; it tends to stop at the volumetric tier and leaves the application layer to you.

On always-on versus on-demand: on-demand diversion is cheaper and adds a detection window plus a BGP announcement and propagation window before mitigation begins. For a firm whose work turns on 16:00 filing cut-offs and completion days, those minutes are a commercial decision, not a technical footnote. Decide now who is authorised to trigger a diversion at 23:00 on a Sunday without a partner’s sign-off, and write the name in the runbook.

What “managed”has to mean in the contract

Managed is a word, not a service level. The dividing line is simple. If a human on the provider’s side is not empowered to change a rate limit or a WAF rule at 16:40 on a Friday while the conveyancing portal is being hammered, without waiting for someone at the firm to raise a ticket, you have bought monitoring, not management. Get four things in writing: the onboarding and rule tuning done before the first attack rather than during it; named escalation contacts on both sides with out-of-hours numbers; explicit authority to change policy mid-incident; and a written post-attack report with timestamps, vectors and actions taken.

The business case, built from downtime rather than fear

Do the arithmetic openly. Take the fee earners who would be unable to work for an afternoon, multiply by the hours lost and by your own charge-out rates, and you have the cost of that single incident in lost recoverable time, before you count a missed completion, an abortive lender drawdown or the partner hours spent on client calls. Compare that number to an annual managed protection quote. Do not compare quotes to each other, which is how firms end up buying the cheapest version of the wrong thing. The structure of UK pricing varies by model, so check current figures with providers directly rather than relying on anything published months ago.

Judging providers on evidence rather than sales decks

Much of what is marketed in the UK as DDoS-protected hosting resells someone else’s scrubbing network. That is not disqualifying, but you need to know it. Ask whose capacity you are buying, which points of presence serve UK traffic (London is not a complete answer if the only nodes are in Frankfurt and Amsterdam), and who physically answers the phone at three in the morning, because that determines both the real capacity and who is accountable mid-incident.

Then press on the SLA. What does it pay out, what triggers it, how is time-to-mitigate measured, and who measures it? A service credit worth one month of fees against a lost afternoon of fee earner time is a gesture, not a remedy. And ask for a redacted report from a real incident. Report quality tells you more about the operations team than any capacity figure on a slide: whether they identified vectors, when a human intervened, and what they changed.

Run this short list alongside Cyber Essentials, Lexcel and the insurer’s questionnaire. Note that Cyber Essentials and Cyber Essentials Plus, for all their value, assess firewalls, secure configuration, access control, malware protection and update management. None of those five controls test whether your site stays reachable under attack. Availability is the box nobody ticks because nobody asks, which is precisely why it is still the weak point in most firms’ answers. Effective law firm cyber attack protection closes it by naming the surfaces, locking the origin, and putting a human with authority on the other end of the phone before the first demand email arrives. Background reading on how these attacks are structured and resourced is collected across DDoSInfo, and the case of the firm that hardened its web security after an attack is a reasonable place to start with partners who need convincing.

Frequently Asked Questions

What does law firm cyber attack protection need to cover beyond email security?

Availability of every client-facing system: the public website, client login portals, document exchange, and the authoritative DNS that publishes all of them. Email controls address confidentiality and fraud; they do nothing if the portal is unreachable on a completion day. Treat network floods, application-layer request attacks and DNS as three separate surfaces with separate owners.

Can a small law firm’s website really be taken offline by a DDoS attack?

Yes, and it rarely takes a large attack. A booter service costs very little and a few thousand requests per second aimed at a login page or document search can exhaust the database behind it. Smaller firms are often more exposed because their site and portal share one modest origin server with no filtering in front of it.

What should a firm do if it receives a ransom demand threatening to take its site down?

Do not pay and do not reply. Preserve the email with full headers, confirm whether an attack is actually in progress, notify your protection provider and hosting supplier, and report to Action Fraud and, if the incident is significant, the NCSC. Payment marks the firm as responsive to pressure and offers no reliable guarantee the traffic stops.

Does a law firm have to report a denial of service attack to the SRA or the ICO?

It depends on effect, not on the label. The SRA Standards and Regulations require prompt reporting of serious breaches, which can include an incident that materially affects the firm’s ability to act for clients. Separately, the ICO treats loss of availability of personal data as a personal data breach, so a 72-hour notification may be required where there is a risk to individuals. Take advice from the COLP rather than deciding on the day.

Is always-on or on-demand mitigation better for a firm with court filing deadlines?

Always-on, in most cases. On-demand diversion is cheaper but adds detection, announcement and propagation time before mitigation starts, and those minutes land badly against a filing cut-off or a lender’s close of business. If budget forces on-demand, agree the out-of-hours authorisation route in advance and name the person who can trigger it without a partner’s approval.

How much should a UK firm expect to spend on managed DDoS protection?

Pricing varies by model: reverse proxy plans are usually billed per protected hostname or per volume of clean traffic, while BGP scrubbing is priced against committed capacity and the size of the prefix. Get current quotes directly, since published figures date quickly. The useful comparison is not quote against quote but quote against your own downtime cost, calculated from fee earner hours lost in a single three-hour outage.

DDOS Protection Cost UK: What You Really Pay

Ask five UK providers to price protection for the same ecommerce site and the quotes will range from a small monthly subscription to an annual contract many times larger, all of them described as DDoS protection. That spread is not a negotiating tactic. The DDoS protection cost UK buyers face varies by two orders of magnitude because the word “protection”is being used to sell at least three different products, bought by three different sorts of customer, with wildly different amounts of human engineering attached. Work out which product you are actually being quoted and the numbers stop looking random.

What follows is a cost anatomy from the buyer’s side: what each pricing model charges for, which line items stay invisible until the first attack, and how to turn downtime into a figure your finance director will sign.

Why DDoS protection quotes in the UK swing so wildly

Three markets hiding behind one search term

The first market is bundled protection: filtering included with a hosting plan, a content delivery network (CDN) tier or a cloud load balancer. Marginal cost near zero, tuning near zero.

The second is mid-market managed service: a monthly fee, a named provider, some human involvement, usually a reverse proxy or a small scrubbing arrangement in front of a handful of properties. This is where most UK mid-market buyers end up, and where the contract language matters most.

The third is enterprise Border Gateway Protocol (BGP) scrubbing with committed capacity: you announce your own /24, traffic is diverted to scrubbing centres, clean traffic comes back over GRE tunnels or a cross-connect. You are buying network capacity, a routing relationship and an engineering team. It has a high floor because all three cost money whether or not you are attacked.

What an entry-level plan genuinely covers

Entry-level proxy plans advertised in the UK market at low monthly prices are real products, not bait. They buy a share of a large anycast proxy estate, automated volumetric filtering, a rate-limiting engine and a dashboard. For a brochure site or a small SaaS front end, that is often proportionate.

What they do not buy is anyone’s attention. Best-effort means exactly that: your traffic is defended by the same automated policy as everyone else on the shared tier, and if a layer 7 attack slips through the generic rules, the rule changes are yours to write. If nobody on the provider’s side is authorised to change policy at 03:00 without your written sign-off, you have bought monitoring, not management.

Why G-Cloud day rates are quoting people, not bandwidth

Public sector buyers looking at the Crown Commercial Service’s Digital Marketplace will see mitigation services listed at a price per unit per day. Those unit prices confuse people who assume they are paying for gigabits. They are not. G-Cloud style day rates typically price consultancy, onboarding, incident response time and diversion support, in other words a human being for a day. Comparing a day rate against a monthly subscription is comparing a plumber’s call-out charge with a water bill.

The question that explains most of the gap

Several UK “providers”do not own a scrubbing centre. They resell capacity on a larger network, wrap it in a portal and a support contract, and add margin. Sometimes there are two resale layers. Each one is another party that must be woken up before a mitigation policy changes, and another margin on your invoice.

So before you compare headline prices, ask who owns the scrubbing centres, whose autonomous system number (ASN) the traffic is cleaned on, and what your escalation path looks like in the middle of the night. Two quotes that differ by 10x for the “same”protection are usually not describing the same distance between you and the engineer who tunes the filter.

The pricing models behind the number on your quote

Per protected property or per protected IP. A flat monthly fee covering a defined number of domains, hostnames or IP addresses. The trap is counting creep. Staging, a customer portal, an API endpoint, a mail relay and a second data centre each add a chargeable unit, and the tidy monthly figure can multiply by the time the estate is honestly documented. Count every public-facing address before signing, not after.

Clean traffic bands with overage. The contract commits you to, say, 100 Mbps of clean traffic delivered, with an overage rate per Mbps or per GB beyond it. This is the single most common source of a surprise invoice after an attack, because attacks change traffic shape. Legitimate users refresh, bots retry, and some providers meter the traffic they forward after scrubbing rather than the flood they dropped. Read the metering definition, ask whether it is 95th percentile or peak, and ask what happens to billing during a declared incident.

Committed capacity and per-Gbps pricing. BGP scrubbing deals price a committed clean bandwidth tier plus the plumbing: GRE tunnel provisioning, or a cross-connect in a shared facility with its own monthly port fee. Budget for the network engineering time too. Announcing a /24 to a scrubbing provider, testing failover and documenting the withdrawal procedure is not a half-day job.

On-demand and emergency onboarding. On-demand looks cheaper on the monthly line because you pay for standby, not for constant traffic handling. The costs move elsewhere: diversion time while routes propagate, and in many contracts an emergency onboarding fee if you are attacked before you are provisioned. Compare the annual always-on premium against that fee plus the extra minutes of downtime, not against zero. Our breakdown of always-on versus on-demand DDoS protection works through where each model genuinely fits.

What each deployment model really costs once you add everything up

Reverse proxy or CDN-fronted protection

Lowest entry cost, priced on requests and bandwidth, quick to deploy with a DNS change. Its weakness is not capacity. It is origin leakage. If your server’s real IP address is still visible in historic DNS records, mail headers, TLS certificate transparency logs or an old subdomain, attackers route around the proxy entirely and hit the origin directly.

No pricing tier fixes an exposed origin. Budget for the remediation instead: new origin addressing, firewall allow-lists restricted to the provider’s published ranges, cleaning up stale A records and moving outbound mail off the web server. That work is usually a few days of engineering, and it is the difference between a paid proxy service that protects you and one that decorates your invoice.

BGP scrubbing and always-on routing

Higher floor, because you are buying capacity and a route rather than a shared proxy slot. It suits ASN holders, hosting companies, data centre operators and anyone protecting non-HTTP services such as game servers, VPN concentrators or VoIP. Costs to model: committed Gbps, tunnel or cross-connect fees, a /24 you actually control, and the internal staff time to run the diversion.

Hosting-level filtering

Bundled with a DDoS protected hosting package, near-zero marginal cost, and genuinely useful against crude volumetric floods. What you rarely get is tuning, a named escalation contact or a forensic report afterwards. If the provider’s answer during an incident is to null-route your IP to protect their other tenants, your site is down either way.

Whichever model you choose, the sticker price is not the total. Add web application firewall (WAF) licensing if it is not included, TLS termination and certificate management, log egress charges if you ship traffic logs into a SIEM, and internal staff hours. On a mid-market deployment those adders routinely equal the mitigation fee itself.

The line items buyers forget until the first invoice

Authoritative DNS. Left off the quote more often than any other component, then added later and billed separately by query volume. A site sitting behind a fully mitigated proxy is still unreachable if its name servers fold, and name servers are a soft target precisely because they are UDP-based and often hosted with a registrar nobody has thought about since 2019. Price network and transport layer, application layer and DNS as one budget line. Our buyer’s guide to authoritative DNS protection covers what to demand from that part of the stack, and the NCSC’s guidance on denial of service attacks is worth putting in front of anyone who thinks the web tier is the whole problem.

Attack reports and forensic exports. Sometimes a paid add-on, sometimes only available on enterprise tiers. Yet a vector breakdown with timestamps, source distribution and packet rates is the evidence you need for an insurer, a regulator, your own customers under an uptime clause, or any legal action following a DDoS attack. If the report costs extra, that is a line item, not a nicety.

What “managed”buys. The most expensive undefined word in a DDoS contract. Pin it down in writing: will the provider change rules mid-attack on their own authority, or does every tuning decision wait on a ticket and your approval? The approval model is cheaper monthly and far more expensive per incident, because the clock runs while your on-call engineer finds the portal password. Ask how many rule changes are included per year and what a change request costs beyond that.

SLA credits. Time-to-mitigate commitments are meaningful only if the measurement method is stated. There is a large practical difference between “60 seconds from detection”and “60 seconds from customer report”, and credits are almost always capped at a percentage of the monthly fee. A 100% credit on a £900 month does not cover a £20,000 trading outage. Treat credits as a signal of confidence, not as compensation.

Price your downtime before you price the protection

The business case is arithmetic, not fear. Build it from three components: revenue or transaction value per hour, incident staff cost, and contractual exposure to your own customers.

Take an illustrative mid-size UK retailer selling online. Spread across realistic trading hours, its annual online turnover gives an average revenue per hour, but peak Saturday afternoons in the run-up to Christmas might run several times that. A four-hour partial outage on a peak weekend, assuming half of attempted orders are lost rather than deferred, removes a meaningful slice of a trading weekend’s gross revenue. Add the people pulled onto an incident bridge for a day, plus an out-of-hours agency callout, and the total climbs again before anyone mentions refunds or reputational damage.

Against that, the annual cost of a managed DDoS protection UK contract is a fixed, known number. The break-even question becomes concrete: does your organisation expect more than roughly one significant outage a year? For an ecommerce operator during peak trading, a law firm running a client document portal under a professional obligation, a healthcare supplier with booking systems, or a B2B platform with liquidated damages in its uptime clauses, the answer is usually yes.

Resist the temptation to inflate. The Department for Science, Innovation and Technology publishes an average cost of the most disruptive breach in its annual Cyber Security Breaches Survey, and boards increasingly recognise that figure. It covers all breach types, skews low because it includes micro-businesses, and will be picked apart if you present it as a DDoS number. Quote the current edition by name and date if you use it, then rely on your own revenue-per-hour model for the actual case.

How to compare UK quotes on evidence rather than sales decks

Send every shortlisted provider the same ten questions and compare the answers side by side:

Who owns the scrubbing centres, and are you a reseller of another network’s capacity?
What is the total mitigation capacity, and what capacity is committed to me contractually?
Is mitigation always-on or on-demand, and what is the measured time to divert?
Can your engineers change mitigation policy mid-attack without my written approval?
How is time-to-mitigate measured, from detection or from my report?
What clean traffic is included, how is it metered, and what is the overage rate?
How many protected IPs or hostnames are included, and what does each additional one cost?
Is authoritative DNS protection included, and is it billed by query volume?
Is a post-incident attack report with vector breakdown included at no extra charge?
What is the named escalation path at 03:00 on a bank holiday, and what phone number do I call?

Then ask for something sales teams rarely offer: a redacted attack report from a real incident in the last twelve months. A capability slide proves nothing. A report showing attack start time, vectors, peak packet rate and the minute mitigation engaged tells you whether the operations team exists. If you want a structured starting point for evaluating vendors, our DDoS protection service comparison sets out how the main approaches differ in practice.

Terms worth negotiating: minimum term (push back on 24 months if you have not tested the service), a burst allowance that waives overage during a declared attack, waiver of emergency onboarding fees, and an exit clause that includes DNS TTL handover so you can leave without a self-inflicted outage.

Red flags, in order of seriousness: “unlimited”capacity claims, which no network can honour once you read the fair use clause; “fully managed”with no definition of who is authorised to act; mitigation SLAs with no stated measurement method; and any provider who will not name the network their traffic is cleaned on. One more, quieter one: a quote that covers only HTTP when half your revenue runs through an API or a DNS zone nobody has audited.

The honest summary of DDoS protection cost UK-wide is that you are pricing three things at once: capacity, authority to act, and evidence afterwards. Cheap plans give you the first. Only the contract tells you whether you are getting the other two, and only the second attack tells you whether you were right. Read the clauses before you compare the prices.

Frequently Asked Questions

How much does DDoS protection cost in the UK per year?

Entry-level proxy plans advertised in the UK market start at modest monthly subscriptions. Mid-market managed services typically land in the low thousands to low tens of thousands annually, depending on protected IP counts and committed clean traffic. Enterprise BGP scrubbing with committed capacity runs higher again, and public sector day rates on G-Cloud listings are quoted per unit per day for incident and consultancy work. Check current pricing directly, as published rates change.

Why is there such a big gap between cheap and enterprise DDoS protection pricing?

Partly technology, mostly people and margin. Cheap plans share automated filtering across thousands of customers with no dedicated engineering time; enterprise contracts commit capacity, a routing relationship and named responders. The resale chain matters too, because each layer between you and the network that owns the scrubbing centres adds margin and removes direct access to the engineers tuning the mitigation.

Does free or bundled protection from a host or CDN count as enough?

For a low-risk brochure site, frequently yes. For anything revenue-bearing, the limits show up fast: little or no tuning, no forensic report, and a provider whose incentive during a large attack may be to null-route your address to protect other tenants. Bundled filtering also rarely covers your authoritative DNS, which is a separate failure point.

What extra charges can appear on an invoice after an attack?

Overage on clean traffic bands is the most common, followed by emergency onboarding fees if you were on an on-demand plan and not yet provisioned. Then look for per-incident support charges beyond included hours, rule change fees above an annual allowance, paid forensic report exports and DNS queries billed by volume.

How do I justify the cost of DDoS protection to finance?

Model revenue or transaction value per hour at peak, add incident staff cost and any liquidated damages you owe customers under uptime clauses, then compare one realistic outage against the annual contract value. Present it as expected loss avoided, not as a doomsday scenario, and cite any national figures you use by source and year so the number survives scrutiny in the room.

Why DDOS Attacks on Government Websites Succeed

A Telegram channel posts a screenshot of a council homepage timing out, the local paper picks it up before lunch, and by mid-afternoon a service owner who has paid for protection for three years is explaining to a director why the site fell over at a traffic volume the provider’s own graph calls unremarkable. That is what most DDoS attacks on government websites look like from the inside. Not a terabit flood. A modest, short, well-aimed burst that found the one hostname nobody had checked.

The public explanations available to a UK public sector team are either definitional (“what is a DDoS attack”) or legal (“it is an offence”) or advisory (“raise your posture”). Useful, none of them answer the question a service owner actually has after an outage: we bought protection, so why did the site go down anyway? The answers are boringly consistent. Leaked origin addresses, unmanaged authoritative DNS, expensive dynamic endpoints, microsite sprawl, and a contract where nobody is contractually obliged to touch a mitigation policy at 02:00.

What an attack on a public sector site actually looks like

Since 2022, the dominant pattern against UK and European public bodies has been pro-Russia hacktivist activity claimed on Telegram: a target list posted in advance or shortly after, availability-only disruption, no attempt at intrusion, and a screenshot of a failed page load as the deliverable. The NCSC published guidance on 25 March 2024 following denial of service attacks against UK political party websites, and has continued to issue advisories about hacktivist groups targeting UK organisations. Treat the pattern as recurring background weather rather than a lightning bolt from the blue.

The screenshot is the payload

This changes the defence economics more than most vendors admit. If the objective is a claim of responsibility rather than sustained damage, the attacker needs five to twenty minutes of visible failure, not five hours. Attacks that fail get quietly dropped from the channel, which is why unsuccessful attempts on high-profile targets tend to vanish from the record; our write-up of hacktivists failing to take the Vatican’s site offline is the shape of an attack that never becomes a story.

Why modest volumes still make national news

A twenty minute outage on a corporate brochure site is a support ticket. The same outage on a council homepage, during a period of political sensitivity, becomes a story about resilience of public services. Journalists do not have your traffic graph. They have a screenshot and a “service unavailable”page.

Confirm it is an attack before anyone briefs communications

Hosting platform failures and DNS provider incidents produce almost identical symptoms to a layer 7 flood, and the first version of the story tends to stick. Establish the difference before you say anything: our walkthrough on telling a DDoS from an outage in ten minutes covers the mechanics. Over-claiming has a cost of its own, because an availability attack that a press office describes as a “cyber attack on resident data”creates a breach narrative you then have to unwind.

What these attacks do not do

A volumetric or application-layer flood does not read your database, exfiltrate records or authenticate to anything. It denies service. Conflating the two in a holding statement invites subject access requests, member questions and an ICO conversation you did not need to have.

Why council and department sites fall over at modest attack volume

Origin IP leakage, the usual culprit

When a proxied site goes down under a few gigabits, the attacker has almost always found the origin. Public sector estates leak origin addresses more than most, because nothing ever gets deleted from a zone file. An MX record pointing at the same server that hosts the site. A staging. Or www2. Host left behind by a supplier in 2019. A consultation subdomain from a 2016 local plan with a live A record on the same /29. Historical DNS datasets and certificate transparency logs make finding these trivial, and no reverse proxy protects an address the attacker can hit directly.

The fix is an audit rather than a product: enumerate every record in every zone you own, resolve each one, and confirm nothing outside the protected set resolves to the origin range. Then firewall the origin to the proxy’s published prefixes and your own management ranges. Most teams find at least one surprise.

Authoritative DNS, the layer outside the contract

Ask a public sector team whether their DNS is protected and a reasonable number will mention Protective DNS. PDNS is a good control and it is not the answer to this question: it protects outbound resolution from staff devices and networks, not the availability of the authoritative name servers citizens query to find you. If those name servers are two boxes in one data centre, or a single provider with a thin anycast footprint, an attack on the DNS layer takes the site off the internet without touching the web tier. The buyer’s questions are in our guide to authoritative DNS DDoS protection.

Endpoints that cost you far more than they cost the attacker

Static pages are cheap to serve and cheap to cache. Site search, planning application lookups, licensing registers, bin collection by postcode, form submissions and large PDFs are not. A few hundred requests per second against a planning search can take down an estate that shrugs off tens of thousands of requests for the homepage. Attack tooling finds these by crawling, and the asymmetry is the point: one request, one uncached database query, one PDF generated on the fly.

Microsite sprawl

This is the structural weakness of the sector. Campaign domains bought for a two-year programme, partnership sites shared with three other authorities, legacy portals from a predecessor body, all with different suppliers, different DNS and inconsistent protection. One unprotected hostname resolving to shared origin infrastructure undoes the protection on everything hosted alongside it. Inventory of hostnames is a security control, not administration.

Check the three surfaces in order: DNS, network, application

DNS

You want an anycast footprint with real geographic spread, a second independent provider (dual-primary, or secondary via zone transfer), and TTL discipline that reflects a trade-off people rarely state out loud: short TTLs give you agility to move records during an incident, while longer TTLs mean resolvers keep serving cached answers if your name servers become unreachable. If you run DNSSEC across two providers, you need a multi-signer arrangement (RFC 8901) or careful key sharing, which is precisely the detail that gets discovered during the incident rather than before it. Our rundown of staying reachable through a DNS provider outage covers the failure modes.

Network and transport

Three honest options. A reverse proxy or CDN suits HTTP services and is the default for most citizen-facing sites, but only works if the origin is genuinely hidden. BGP scrubbing protects whole address ranges including non-HTTP services, and requires that you hold your own IP space and can announce at least a /24, which rules it out for the many authorities sitting on supplier addresses. Hosting-level filtering is the cheapest and most often oversold: ask directly whether “mitigation”at your host means scrubbing or null-routing your IP, because a remotely triggered black hole completes the attacker’s objective on your behalf.

Application layer, and the accessibility decision nobody schedules

Rate shaping per client, per path and per token is where you defend expensive endpoints. Challenge policy is harder, and it is an accessibility decision as much as a security one. A blanket CAPTCHA on a housing benefit or planning objection form excludes the people least able to route around it, and UK public sector sites sit under the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, with government guidance now pointing at WCAG 2.2 AA (check the current position before you write a policy). Plan graduated responses: cache aggressively, shape by path, use lightweight non-interactive checks, and keep one tested low-friction route (a phone line, an alternative host, a plain form) that you can publish when you do turn challenges up.

A ten minute check a duty engineer can actually run

Query each authoritative name server directly and non-recursively (dig +norecurse @ns1.example SOA yourdomain.gov.uk). No answer from any of them and the problem is DNS, not the web tier.
Resolve the public hostname from two networks, one of them off your corporate connection.
Curl -sS -o /dev/null -w “%{http_code} %{time_total}\n”against the public hostname, then the same request pinned to the origin with –resolve and the correct Host header. Origin healthy plus public hostname failing points at the edge; both failing points at origin or capacity.
Compare requests per second, bandwidth and 5xx rate on the protection portal’s traffic graph against the same hour last week.
Check the hosting and DNS provider status pages before you declare anything.

What “managed”has to mean in a public sector DDoS contract

The dividing line is simple. If nobody on the supplier side is empowered to change a mitigation policy at 03:00 without waiting for your sign-off, you have bought monitoring, not management. Write it down in the contract: onboarding and rule tuning, always-on baselining, named escalation contacts on both sides, the out-of-hours trigger, and the authority to act.

Trace the resale chain

Plenty of “managed DDoS protection”bought through a hosting partner is resold capacity from a platform two steps removed, and the escalation path runs through two service desks before it reaches an engineer with policy access. Ask whose network, whose scrubbing centres, which regions, and who answers the phone. Get the answer in writing, with names or at least role-based rotas.

Judge providers on evidence, not capacity slides

Aggregate terabits of global capacity tells you little about what is available in the London or Amsterdam scrubbing centre on the day. Press instead on: time-to-mitigate wording in the SLA and what the remedy actually is; whether the SLA covers detection, mitigation or both; the quality of post-attack reports, including vector breakdown, packets and requests per second, sources and mitigation timeline, because that document is what your auditors and any police report will rely on. Ask for a redacted real report before you sign.

Buying routes and the business case

Crown Commercial Service frameworks are the usual route (check which iteration is live when you buy), and multi-supplier estates need one owner of the protection standard across all hostnames rather than each supplier doing its own thing. Build the case from the cost of a day offline: staff time diverted to phones and reception, missed statutory deadlines, delayed payments, member and press handling. Headline capacity numbers make a weak business case; a statutory consultation closing at midnight makes a strong one.

Always-on or on-demand when your service has statutory deadlines

Detection-and-divert means an attack has to be spotted, a route or DNS change made, and traffic drawn into the scrubbing centre before mitigation begins. Against a fifteen minute hacktivist burst, that sequence can complete just as the attack stops. You mitigated nothing and the screenshot already exists. For the citizen-facing hostname, always-on cover is the pragmatic choice even on a tight budget; the wider trade-offs are set out in our comparison of always-on and on-demand protection.

Calendar risk usually settles the argument. The 31 January self-assessment deadline, pre-election periods, GCSE and A-level results days, grant application windows and consultation closing dates are all dates where a thirty minute outage carries legal and reputational weight rather than just annoyance. A hybrid is common and defensible: always-on for the portal and transactional hostnames, on-demand for wider address space and internal ranges where a few minutes of diversion time is tolerable.

Then verify the promise. Run an onboarding test with the provider, agree reporting cadence in peacetime, and ask for evidence of past mitigations at comparable size. A provider who cannot show you a real timeline from a real event is selling you a diagram.

The first hour

Run a fixed sequence rather than improvising: confirm scope (one hostname or the whole estate), check DNS resolution, check reachability to origin and edge, check application behaviour and error mix, then declare and escalate to the named contact. Publish your status update somewhere that does not depend on the failing infrastructure, because a holding page served from the same name servers or the same origin is no use at all. Social channels, a separately hosted status domain and the phone lines all need to be pre-agreed, not improvised while the homepage times out.

Capture evidence as you go: timestamps in UTC, packet or request samples, firewall and proxy logs, mitigation logs and the provider’s attack report. Denial of service is an offence under section 3 of the Computer Misuse Act 1990, with a statutory maximum of up to 10 years, and the National Crime Agency’s position is that using booter or stresser services is itself an offence. Report through Action Fraud, and via your NCSC reporting route as a public sector body; our UK playbook on legal action after an attack sets out what evidence keeps options open. For dated context on how the incident mix shifted, analysis of incidents reported to the ICO and the FCA put denial of service at around a quarter of reported hacking incidents in the first half of 2022, against 4% the year before; the figure is old now, but the direction of travel it showed has not reversed.

Finish with a review that changes something. Re-audit origin exposure, name the owner of every zone and every hostname, close the contract gaps you found at 02:00, and write the triage sequence into the runbook with the escalation numbers on the front page. DDoS attacks on government websites succeed because these small things stay undone between incidents, not because the attackers are formidable. Fix the leaked records, put a second name server provider in place, protect the expensive endpoints, and make sure someone is genuinely on the hook to act before the next target list appears.

Frequently Asked Questions

Why are government websites such frequent DDoS targets?

Because they are symbolic, easy to name and produce disproportionate publicity for a small amount of traffic. Hacktivist groups aligned with geopolitical causes pick targets that make a recognisable screenshot, and a council or department homepage does that better than an anonymous corporate site. The NCSC’s March 2024 guidance, issued after denial of service attacks on UK political party websites, reflects that pattern.

Are DDoS attacks on government websites a data breach?

A denial of service attack disrupts availability; it does not in itself give the attacker access to data. It can still be a reportable security incident, and availability is part of data protection obligations, so take advice on your specific circumstances. Describing an availability attack as a data breach in public creates problems you then have to correct.

Is a DDoS attack illegal in the UK, and who should it be reported to?

Yes. Section 3 of the Computer Misuse Act 1990 covers unauthorised acts that impair the operation of a computer, carrying a statutory maximum of up to 10 years, and the National Crime Agency treats the use of booter and stresser services as an offence in itself. Report to Action Fraud, and public sector bodies should also use their NCSC incident reporting route.

How much does protection for a public sector website cost?

There is no meaningful single figure, and anyone quoting one without asking questions is guessing. Price is driven by the number of protected hostnames, whether authoritative DNS is included, clean traffic volumes, overage rates per Gbps or per million requests, and above all whether managed escalation is real or nominal. Ask for the overage terms and the out-of-hours escalation commitment in writing, because those are where the surprises live.

Does a CDN or reverse proxy alone stop attacks on a council website?

Only if the origin is genuinely hidden and every hostname you own sits behind it. Legacy mail records, staging subdomains and old A records routinely expose the origin address, at which point the proxy is bypassed entirely. Pair the proxy with an origin firewall limited to the provider’s prefixes, and audit your zones for records that resolve straight to the server.

Should a government service use always-on or on-demand mitigation?

For citizen-facing and transactional hostnames, always-on is the safer choice, because hacktivist bursts of five to twenty minutes can finish before a detect-and-divert model has finished rerouting traffic. On-demand remains reasonable for wider address space and internal ranges. If you have statutory deadlines or election periods in your calendar, weight the decision towards always-on for the services that carry them.

Application Layer DDOS Protection: 7 Real Gaps

A business that has signed a scrubbing contract, bought a web application firewall (WAF) licence and put a managed service retainer on the renewal calendar tends to file DDoS under “handled”, somewhere between the firewall renewal and the cyber insurance schedule. Then the search page stops answering on a Tuesday afternoon, the origin database sits at 100 per cent CPU, and the edge bandwidth graph never moves. That is the moment most buyers discover that application layer DDoS protection and network-layer capacity are two different purchases, and they only bought one of them properly.

What follows assumes you already have something in place: a reverse proxy, a WAF, a hosting-level filter, maybe all three. The question is not what a Layer 7 attack is. The question is why the thing you are paying for did not stop it.

Why Layer 7 attacks slip past protection you already pay for

An application-layer, or Layer 7, attack sends requests that look legitimate. Valid HTTP, correct headers, often real browsers or real mobile clients driven by malware. The traffic targets whatever endpoint costs the most to serve: a full-text search, a faceted product filter, a login that triggers a password hash, a PDF or invoice render, a GraphQL query that fans out across three services. Volume is beside the point. A few thousand requests per second against a search endpoint can exhaust a connection pool that would shrug off a hundred times that in cached image requests.

So a 40Gbps clean bandwidth commitment tells you nothing about whether 8,000 requests per second to /search gets stopped. Those are different units measuring different failure modes. Network-layer defences count bits; Layer 7 defences have to count requests, weight them by cost, and decide which sessions are real.

Assess three surfaces separately, not as one product

Every estate has three surfaces that fail independently, and contracts routinely cover one or two of them:

Network and transport: volumetric floods, reflection and amplification, SYN floods. This is where scrubbing capacity and BGP diversion matter.
Application layer: HTTP and HTTPS request floods, slow-read and slow-post attacks, API abuse. This is proxy, challenge and rate-limiting territory.
Authoritative DNS: if the name does not resolve, everything above it is decoration.

Write those three headings on a page and map each line of your current contract to one of them. The gaps usually appear within ten minutes.

Read your own telemetry first

The diagnostic signature is unglamorous and reliable. Edge bandwidth flat at normal levels, request counts up sharply on one or two URL paths, origin CPU and database connections climbing, error rates rising on those paths before anywhere else. That pattern points at an application flood, not a pipe-filling attack. If you are still deciding whether you are under attack at all rather than suffering a self-inflicted outage, the triage steps in this guide to telling a DDoS from an ordinary outage will save you arguing about it for an hour.

Gap 1: your origin IP is still reachable, so the proxy is optional

More reverse proxies are bypassed through origin IP leakage than through sheer attack volume. Not close, in practice. An attacker who knows the origin address simply skips the edge entirely and hits the web server directly, and every rule you tuned at the proxy becomes advisory.

The address leaks from predictable places: historical DNS A records captured by passive DNS services long before you onboarded; mail headers from transactional email sent by the same host; TLS certificate transparency logs, which have been mandatory for publicly trusted certificates in Chrome since 2018 and are publicly searchable, so issuing a cert for staging.yourcompany.co.uk or admin.yourcompany.co.uk publishes that hostname to anyone watching; verbose error pages that print internal hostnames; and API endpoints that were pointed direct-to-origin for latency reasons and never moved back.

The fix is dull and effective. Firewall the origin so it accepts inbound traffic only from your provider’s published IP ranges, rotate the origin address after onboarding so historical records are worthless, and then verify it: curl the origin IP directly with the Host header set, from a network outside your own, and confirm you get a refusal rather than a page. Do that before you buy anything else. There is no point evaluating challenge algorithms while the front door has no lock on it.

Gap 2: the WAF is blocking signatures, not behaviour

A WAF ruleset is built to recognise malicious payloads: SQL injection strings, path traversal, known exploit patterns. A Layer 7 flood contains none of those. Each individual request is unremarkable and would be served happily on a quiet Wednesday. Volume in aggregate is the attack, and signature matching has nothing to match.

What actually works sits one layer up in logic: per-session request budgets rather than per-IP counters; JavaScript and cryptographic proof-of-work challenges that cost the client something; and cost-weighted rate limits, which is the control most estates are missing. A request for a cached product image and a request that triggers a full-text search or a PDF render are not equivalent, and a flat limit treats them as if they were. Set it low enough to protect search and you throttle genuine shoppers browsing a catalogue. Set it high enough for browsing and the expensive path stays wide open.

Per-IP limiting also collapses against distribution. A botnet spread across tens of thousands of residential addresses, each sending a handful of requests a minute, never trips a per-IP threshold anywhere. Every source looks like a normal user on a normal broadband line, because it largely is one. The defender’s view of botnet-driven floods is worth reading if you want to understand why source-based blocking degrades as the botnet grows.

One more thing procurement should force into the timeline: the false-positive conversation. Tuning thresholds for your real traffic shape, including scrapers you want to keep and the price-comparison feed you depend on, belongs in onboarding week. Not at 04:00 during an incident, with the commercial director asking why paying customers are seeing a challenge page.

Gap 3: your API and mobile traffic bypass the human-facing defences

Browser challenges, fingerprinting and cookie-based session tracking assume a browser. Your mobile app does not have one. Neither does your partner’s integration, your payment webhook receiver, or the B2B client pulling stock levels every thirty seconds. Turn on aggressive challenges and you break them; exempt them and you have created an unprotected lane straight to the most expensive endpoints you own.

Authenticated APIs are the attractive target precisely because they skip caching and touch the database on every call. Checkout APIs, GraphQL endpoints that allow deeply nested queries, and account-history calls all cost real compute per request. Sensible controls here are different in kind: rate limits keyed to API tokens or account identity rather than IP; explicit request cost budgets where a heavy query consumes more of the allowance than a light one; schema validation and query depth limits on GraphQL; and mutual TLS or signed requests for partner traffic so you can distinguish it cleanly.

Check subdomain coverage while you are there. One forgotten host, a legacy api-v1 or a marketing microsite on the same origin, undoes the proxy configuration for everything behind it.

Gap 4: authoritative DNS sits outside the contract

Layer 7 protection and DNS protection are frequently sold as one story and scoped as two line items. Read the schedule. Authoritative DNS is the layer most often left unmanaged, usually because it came free with the registrar years ago and nobody revisited it.

Ask who answers queries for your zone when your primary DNS provider is itself the target, how many anycast points of presence serve UK resolvers, and whether secondary DNS with a second independent provider is included or chargeable. Then look at your TTL values. A 3,600 second TTL means up to an hour before a failover to a backup provider takes effect across resolvers; 60 to 300 seconds, set in advance and left there, gives you near-immediate redirection when you need it. Lowering TTLs during an incident does not help, because the old values are already cached.

Our buyer’s guide to authoritative DNS protection goes through anycast footprints and secondary configurations in more detail, and the record of what happens when a DNS provider itself goes down explains why single-provider dependency keeps producing the same headline.

Gap 5: nobody is contractually obliged to act during the attack

The dividing line is simple. A self-service plan gives you a dashboard, a rate-limiting engine and rules you write and troubleshoot yourself. A managed service means a named engineer on the provider’s side is empowered to change policy at 03:00 without waiting for your sign-off. If that authority is not written down, you have bought monitoring, not management.

Deployment model matters more at Layer 7 than most buyers expect. On-demand mitigation, where traffic is diverted via BGP once an attack is detected, is a defensible trade-off for volumetric floods; detection plus diversion plus route convergence is tolerable when the alternative is paying for always-on capacity you rarely use. It is a poor fit for application attacks. A 5,000 requests-per-second flood against a search endpoint can drain your database connection pool well before diversion completes and traffic starts flowing through the scrubbing path. By the time mitigation is live, you have already taken the outage. The comparison of always-on and on-demand models sets out where each one genuinely earns its cost.

In procurement, run the escalation test rather than reading the SLA summary. Ask who answers the phone at 03:00 on a Sunday, whether that person is in the UK or following the sun, what they are authorised to change unilaterally, and how a customer raises severity. Then look at the wording: time to mitigate versus time to first human response (they are not the same metric), what counts as an attack start for the purposes of the clock, and the exclusions. Many time-to-mitigate commitments apply only to network-layer events and quietly exclude application-layer mitigation altogether.

Gap 6: you are buying a resale chain, not a network

A large number of UK providers resell another vendor’s proxy or scrubbing platform under their own brand. That is not automatically a problem; the underlying platforms are often excellent, and the reseller may add genuine tuning value. The problem is the extra escalation hop. During an incident, the distance between you and the engineer who can actually push a rule change is measured in handoffs, and each one costs minutes you do not have.

Questions that tend to get honest answers: which points of presence serve UK traffic and where do they sit; what is the underlying platform; who holds the capacity contract; can your engineers speak directly to the platform’s operations team during a severity-one event, or does everything route through account management. If the answers are vague, the escalation path is probably vaguer.

Gap 7: no post-attack evidence, so nothing improves

Judge a provider on the quality of a redacted post-incident report, not on a headline Tbps figure. Anyone can print a capacity number. A report that names the endpoint under attack, the rule that fired, the time from detection to mitigation and the residual request rate still reaching your origin tells you whether there was an engineer watching.

A usable attack report contains request rates broken down by endpoint and method, source distribution by network and geography, the vector breakdown, which mitigation action was applied and when, and what got through. That evidence has value well beyond engineering. Cyber insurers ask for it, boards ask for it, and any legal route following an attack depends on contemporaneous logs rather than recollection. The UK’s National Cyber Security Centre sets out the same expectation in its denial of service guidance collection: know what normal looks like, and capture what happened.

On the business case, argue from downtime cost per hour, not the headline monthly fee. UK managed pricing is typically assembled from four components: clean bandwidth commitment, the number of protected assets or domains, request volume tiers, and the level of incident support. Those variables move independently, so two quotes with similar monthly figures can differ enormously in what they cover at Layer 7. Work out revenue and recovery cost for a four-hour outage during your busiest trading window, and the comparison becomes straightforward.

The pre-purchase checklist

Curl your origin IP directly from an external network with the Host header set. Do you get a page?
Ask for the endpoint-level rate-limiting configuration, weighted by request cost, that the provider proposes for your top five most expensive paths.
Confirm in writing which mobile and API traffic is covered, and how, given those clients cannot solve browser challenges.
Check whether authoritative DNS is inside the managed scope, and whether secondary DNS is included.
Establish who changes rules at 03:00, their authority level, and the time-to-mitigate definition that applies to Layer 7 specifically.
Ask what the underlying platform is and how many escalation hops sit between you and it.
Request a redacted Layer 7 post-incident report as a sample deliverable before you sign.

If you are still mapping requirements before shortlisting, our overview of DDoS attack solutions and how they differ covers the architectural options in more detail. Effective application layer DDoS protection is rarely a product decision. It is a coverage decision, an authority decision and an evidence decision, and the estate that gets those three right will survive a request flood that flattens a better-funded competitor.

Frequently Asked Questions

What is the difference between application layer DDoS protection and network layer scrubbing?

Network-layer scrubbing removes volumetric and protocol attacks measured in bits and packets per second, usually by diverting traffic through a scrubbing centre. Application layer DDoS protection inspects HTTP and HTTPS requests, counts them per endpoint and per session, and decides which clients are genuine. A contract covering one does not necessarily cover the other, and the SLA clocks are often defined separately.

Can a WAF alone stop a Layer 7 DDoS attack?

Rarely. A WAF is built to recognise malicious payloads, and a request flood consists of well-formed, individually legitimate requests. Stopping it needs behavioural controls: session-level request budgets, challenges, bot scoring and cost-weighted rate limits on your most expensive endpoints. A WAF with those features enabled and tuned can do the job; a signature-only ruleset will not.

How do attackers find my origin IP and get past the proxy?

Through historical DNS records held by passive DNS services, mail headers from transactional email sent by the same host, certificate transparency logs that publish staging and admin hostnames, verbose error pages, and API endpoints pointed straight at the origin. The countermeasure is to restrict inbound traffic at the origin firewall to your provider’s published IP ranges and rotate the origin address after onboarding.

Does application layer DDoS protection cover APIs and mobile app traffic?

Only if it was scoped to. Browser challenges and JavaScript fingerprinting do nothing for clients that cannot execute JavaScript, so API and mobile paths need token-based limits, request cost budgets, schema and query depth validation, and signed or mutually authenticated requests. Ask the provider specifically how non-browser clients are handled, and check every subdomain is behind the edge.

What does managed application layer DDoS protection typically cost in the UK?

Pricing is usually assembled from clean bandwidth commitment, the number of protected domains or assets, request volume tiers and the incident support level, so published headline figures are hard to compare and change frequently; check current quotes directly. The more useful exercise is calculating your cost of downtime per hour during peak trading and testing the annual protection spend against that. Get each quote broken down by those four components so you are comparing the same coverage.