DDoS protection

Layered DDoS defence, so one attack is one site's problem

Floods are absorbed at the edge, network-layer attacks are filtered upstream, and whatever reaches the server is contained inside the target site's own kernel-level cage. Three layers, each doing a different job, so an attack aimed at one site does not become an outage for the ones beside it. This is the defence model behind a platform hosting 100,000+ PBN sites across every niche, and the baseline runs on every plan.

  • 3layers of mitigation: network, edge, server
  • 100,000+PBN sites hosted across every niche
  • Includedbaseline isolation, WAF and throttling
  • 99.99%uptime assurance

Three layers, because one is never enough

A volumetric flood, an L7 application flood and a slow connection-exhaustion attack are three different problems. We handle each of them where it is cheapest and fastest to handle — upstream of the fleet, at the edge, and inside the cage.

Network layer (L3/4)

Provider-level DDoS protection filters network-layer floods upstream of our worker fleet, before that traffic ever consumes a port, a NIC or a CPU cycle on the machine your site runs on. For advanced and enterprise risk profiles, Cloudflare Magic Transit and Spectrum extend the same filtering to non-HTTP traffic.

Application layer (L7) at the edge

Cloudflare sits in front of every site. It absorbs volumetric HTTP floods, runs an L7 WAF, applies per-site rate limiting, and uses bot management and managed challenges to separate real visitors from automated traffic — all before a request reaches origin.

Server layer

LiteSpeed Enterprise applies connection and request throttling with per-IP connection limits, Imunify360 runs a network firewall with brute-force protection and IP reputation filtering, and CloudLinux LVE entry-process caps bound how many concurrent requests a single site can ever hold open.

Per-site containment

LVE caps CPU, RAM, IO, IOPS, processes and entry-processes for every site individually. A flood that gets through the upper layers is throttled inside the target site's own cage, so the pressure it creates stays with that site rather than spreading across the server.

Containment is the point

Most hosting outages during an attack are not caused by the attack reaching its target. They are caused by the target's resource consumption starving everything else on the box. That is the failure mode this architecture is designed to remove.

  • Every site runs inside its own CloudLinux LVE resource cage — the attacked site is throttled at its own ceiling, and neighbouring sites keep the resources their own limits guarantee them.
  • CageFS gives each tenant an isolated filesystem view, so an attack that escalates into an intrusion attempt is contained rather than shared across tenants.
  • CloudLinux MySQL Governor throttles database usage per site, so an application-layer flood that hammers uncached queries cannot drag the database down for everyone else on the server.
  • Per-site LiteSpeed LSAPI workers are bounded by that site's LVE limits, so a flood cannot spawn unbounded PHP processes.
  • Per-IP connection limits and LiteSpeed connection throttling absorb slow-connection and connection-exhaustion attacks at the web server, not at the application.

Cache is the shock absorber most hosts forget

The cheapest request to survive is the one that never touches PHP or MySQL. Our two-layer cache means a large share of an application-layer flood is answered by static bytes rather than by your origin doing work.

  • LSCache, the LiteSpeed Enterprise full-page cache, serves cached pages without invoking PHP or the database — so repeated requests for the same URL cost a fraction of what they would on a stock stack.
  • A per-site Redis object cache offloads database reads for the pages that genuinely must be dynamic.
  • Cloudflare edge caching answers requests in the visitor's region, so flood traffic is dispersed across the edge network instead of converging on one origin.
  • Cart, checkout, my-account, nonce and session pages are excluded from cache by default, so hardening under load never breaks a transaction.
  • Purge is coordinated across both layers from one control, so raising cache coverage during an incident does not leave you with stale pages afterwards.

Signal to action, automatically

Mitigation is not a support ticket. Signals feed a policy engine that maps each one to an enforcement action, a customer notification and — where possible — an automatic remediation, with every transition logged.

Dynamic tightening

When a DDoS signal fires, the policy engine applies Cloudflare mitigation and per-site rate limiting, and can dynamically tighten that site's LVE limits. When the signal clears, the limits relax again. Graduated, reversible, and logged at every step.

Throttled, not switched off

If an attack is threatening the origin, the site moves to a 'throttled' state — tighter LVE limits and rate limiting, with the site still up and serving. Throttled recovers automatically once the pressure clears; it is not a suspension.

Native LVE auto-throttle

Below the policy engine, LVE throttles CPU, IO and process usage per site natively and automatically. It is the always-on first line, running whether or not anything has classified the traffic as an attack yet.

Full audit trail

Every enforcement transition records its reason, whether it was automatic or staff-initiated, and the evidence behind it. You are notified of what changed and how to resolve it, and every action is appealable.

What is included, and what you buy when risk goes up

Baseline protection is not optional, because an attacked or compromised site threatens its neighbours, our server reputation and our IP ranges. Heavier protection exists for sites whose risk profile calls for it.

  • Included on every plan: LVE and CageFS isolation, LiteSpeed connection and request throttling, the Imunify360 network firewall with brute-force protection and IP reputation filtering, the proactive WAF, and real-time malware scanning.
  • Available as add-ons: advanced bot management, higher DDoS protection tiers, enhanced WAF rules, priority scanning and dedicated firewall rules.
  • Also upsold when you need it: one-click malware cleanup and remediation, for the case where an attack was the cover for a compromise rather than the goal.
  • Advanced network-layer mitigation via Cloudflare Magic Transit or Spectrum is available for enterprise and high-risk workloads.

Attacks that are really something else

A traffic spike is often a symptom. The same signal pipeline that handles floods also catches the compromises that produce them, so an incident gets classified correctly rather than just absorbed.

  • Imunify360 scans in real time and the proactive WAF blocks known exploit techniques before a patch exists for the underlying vulnerability — the route by which a site becomes someone else's attack tool.
  • Outbound mail is rate-limited per site and watched for volume spikes, bounce rates, blocklist hits and complaint signals, so a compromised site sending spam is caught in minutes rather than after a blocklisting.
  • Suspected malware and phishing are cross-checked against Google Safe Browsing, PhishTank and SURBL/APWG, and correlated with scan results before an enforcement decision is taken.
  • Resource abuse and crypto-miners surface as LVE CPU and IO faults logged per site, which auto-throttle the offender.
  • Every signal lands in one Abuse Desk in the admin console — aggregated, deduplicated and prioritised — rather than in four disconnected tools.

FAQ

If another site on my server is attacked, what happens to mine?

The design goal is containment. Every site runs inside its own CloudLinux LVE cage with capped CPU, RAM, IO, IOPS, processes and entry-processes, its own CageFS filesystem view, and per-site database throttling via MySQL Governor. An attacked site is throttled at its own ceiling rather than consuming the whole machine, and LiteSpeed per-IP connection limits bound how much of the web server it can hold. Containment is engineered at the kernel, not configured per customer.

Is DDoS protection included, or an add-on?

The baseline is included on every plan: LVE and CageFS isolation, LiteSpeed connection and request throttling, the Imunify360 network firewall, the proactive WAF and real-time malware scanning, with Cloudflare edge absorption and provider-level network filtering in front of the fleet. We include it because we cannot leave the protection of our own fleet optional. Advanced bot management, higher DDoS tiers, enhanced WAF rules and dedicated firewall rules are add-ons for sites that need them.

Will you take my site offline if it gets attacked?

Being a DDoS target maps to Cloudflare mitigation plus per-site rate limiting, and — only if the attack is threatening the origin — the 'throttled' state: tighter LVE limits with the site still up and serving. Throttled recovers automatically once the pressure clears. Suspension is reserved for non-payment or confirmed abuse, and even then the site serves a branded, reason-specific holding page rather than a broken one.

Does an application-layer flood still hit my database?

Not for anything served from cache. LSCache answers cached page requests without invoking PHP or MySQL, and a per-site Redis object cache offloads reads for genuinely dynamic pages. What remains is bounded by your site's LVE process and entry-process caps and by MySQL Governor's per-site database throttling, so database pressure from one site cannot spill onto the server. Cart, checkout, my-account and session pages stay uncached by default so hardening never breaks a transaction.

Can you protect traffic that is not HTTP?

Yes, at the network layer. Provider-level DDoS protection filters L3/4 floods upstream of our fleet regardless of protocol, and for advanced or enterprise requirements Cloudflare Magic Transit and Spectrum extend edge-grade mitigation to non-HTTP traffic.

How do I know an attack happened and what you did about it?

Every enforcement transition is logged with its reason, whether it was automatic or staff-initiated, and the evidence behind it. You are notified of what changed and what resolves it, every action is appealable, and privileged actions are audit-logged for your own compliance trail. Signals are aggregated in a single Abuse Desk rather than scattered across tools.

Can I try this before paying?

Yes. Footprint-Free Hosting starts with a card-free 7-day trial covering up to 5 sites — no payment details, no commitment. Plans are backed by a 30-day no-quibble money-back guarantee, free migrations and no vendor lock-in.

Defence that is already on when the traffic arrives

Network filtering, edge absorption, server throttling and per-site containment run from the moment you deploy — nothing to configure, nothing to switch on mid-incident. Start with a card-free 7-day trial, backed by a 30-day money-back guarantee and free migrations.

Start free