DDoS Protection for Hosting Providers and Data Centres

Every other sector’s DDoS problem is about one organisation’s traffic. A hosting provider’s problem is that the attack is aimed at one customer and the consequences arrive for all of them.

That single fact reorganises the design, the operations and the commercial terms.

At a glance

Appliance	Problem	Single-tenant estate	Hosting provider
Who is affected	The organisation under attack	Every tenant sharing the path
Cheapest response	Filter, and keep serving	Drop the target, which is what the attacker wanted
Policy granularity	One policy for the estate	One per tenant, or the policy fits nobody
Attack source	External	Sometimes a tenant of your own
Commercial exposure	Lost revenue during the outage	Contractual credits to uninvolved customers

The last row is the one that changes the business case. Damage is not proportional to the attack; it is proportional to how many customers shared the path with the target.

Shared fate

An attack against one tenant consumes shared resources: circuit capacity, the session tables of shared devices, the processing budget of anything inline, and the attention of the operations team. The tenant under attack may be a customer paying for a small virtual machine. The tenants degraded alongside them may be the platform’s largest accounts.

This is why damage does not scale with attack size. It scales with how many customers shared the path, which is an architectural choice made long before the attack.

The mitigations are structural rather than product decisions:

Segment the blast radius. Customers on separate address ranges, separate uplinks or separate edge devices share less. Complete separation is uneconomic; deliberate grouping is not.

Do not let one tenant reach shared ceilings alone. Any single tenant that can exhaust a shared session table has been given a capability nobody intended to sell.

Know where the shared choke points are. Usually a stateful device somewhere in the common path, and usually discovered during the incident rather than before it.

The null-routing problem

When one customer’s address is under an attack larger than the circuit, the fastest effective response is to discard everything destined for it — RTBH, applied at the provider’s edge or by the upstream.

It works. It protects every other tenant. And it completes the denial of service against the customer who was attacked, which is what the attacker set out to achieve.

The technique is not the issue. The issue is that this is a business decision being taken as an operational reflex, usually at 03:00, usually by someone with no authority to make it, and usually explained to the customer afterwards.

The fix is contractual and cheap: state in the service terms when null-routing may be applied, for how long, with what notice, and what compensation follows. A customer who has read that clause and signed is in a different position from one who discovers the policy during their own outage. It also converts an argument into an entitlement, which is faster for everyone.

More selective options exist and are worth having above the reflex: FlowSpec rules that discard only the attack’s characteristics, diversion of one tenant’s traffic to scrubbing, or filtering upstream on protocol and port. Each takes longer to apply than a null route, which is exactly why the ladder has to be written down before it is needed.

Per-tenant policy, and what isolation means

Multi-tenancy in this category is frequently sold as a reporting feature. For a hosting provider it is the mechanism that keeps different customers from breaking each other.

A tenant running a game server, a tenant running a corporate website and a tenant running an API have incompatible normal profiles. One policy across all three either refuses the game server’s ordinary traffic or is too permissive to protect the website. There is no single setting that serves them, which is why per-tenant policy is a platform requirement rather than a premium tier.

Four things need isolating, and products differ on how many they cover:

1. Protection thresholds, set per tenant from that tenant’s measured traffic.
2. Statistics visibility, so a customer sees their own traffic and nobody else’s.
3. Alarms, routed to the right customer.
4. Enforcement independence — one tenant’s volume must not trigger another tenant’s limits.

The fourth is the one to test rather than read about. A shared counter that a busy neighbour can push into a limit is isolation in the interface only, and it is a realistic failure.

You are also a source

A hosting estate is an attractive place to launch attacks from: the bandwidth is already paid for, the capacity is substantial, and a compromised or abusive tenant is hard to distinguish from a busy one.

The minimum is outbound rate monitoring per tenant, ingress filtering so that spoofed sources cannot leave your network, and a documented path from an abuse report to a suspension. All three also protect your own reputation, addressing and upstream relationships, which is usually the argument that gets them funded.

Making it a service rather than a cost

Most providers reach a point where a base level of protection is included for platform stability and additional protection is sold. That structure works, and the failure mode is offering no base at all — because an unprotected tenant’s incident still degrades paying customers.

The commercial mechanics, the tiering and the margin question are worked through in turning DDoS protection into a service, which applies to hosting providers and carriers alike. The buyer-side view of what such a platform must do is in the ISP buyer’s guide.

What to specify

• Per-tenant thresholds, statistics, alarms, and enforcement independence, the last one tested rather than described.
• Provisioning time for a new tenant policy.
• Per-tenant reporting produced without supplier involvement.
• The null-routing ladder: what is tried before it, and the contractual terms around it.
• Outbound monitoring and filtering per tenant.
• Capacity sized to the aggregate edge, with the shared choke points documented.