# DDoS Protection and Its Practical Limits

- Link: https://offshorehosting.pk/ddos-protection-practical-limits/
- Published: 2026-10-25T10:47:00+00:00
- Author: admin

# DDoS Protection and Its Practical Limits

A distributed denial-of-service (DDoS) attack tries to make your website unavailable
by overwhelming it with traffic — so much traffic, or so many requests, that legitimate
visitors cannot get through. It is one of the few attacks where the target does 
not need to have a vulnerability: the site can be perfectly patched and still go
down.

DDoS protection is widely sold and widely misunderstood. This guide explains the
types of attack, how mitigation works, and — most importantly — what it cannot do.

## The three kinds of DDoS attack

Attacks are usually grouped by the layer they target:

### Volumetric attacks (Layers 3/4)

The attacker floods the network with traffic — UDP floods, ICMP floods, DNS amplification—
aiming to saturate the connection itself. The goal is to fill the pipe so nothing
else gets through. These are measured in gigabits or terabits per second, and the
largest recorded attacks are now measured in tens of terabits. No single server 
can absorb that; only a large distributed network can.

### Protocol attacks (Layers 3/4)

These exploit the way network protocols work rather than raw volume: SYN floods 
that exhaust a server’s connection table, fragmented packet attacks, or Ping of 
Death-style malformed packets. They use less bandwidth than volumetric attacks but
can still take a server offline by exhausting a specific resource.

### Application-layer attacks (Layer 7)

These target the application itself: HTTP floods that request pages as fast as possible,
Slowloris attacks that open many connections and hold them open, cache-busting requests
that force the server to generate every page from scratch, and attacks on expensive
endpoints such as search or login. They can be devastating at relatively low bandwidth,
because each request forces real work — a database query, a page render, a login
attempt. A few thousand well-chosen requests per second can be worse than a gigabit
flood.

DNS attacks are a related category: floods of DNS queries, including random-subdomain(“
water torture”) attacks designed to exhaust the DNS resolver.

## How mitigation works

Effective DDoS protection works in layers, and each layer handles a different kind
of attack:

 * **Edge absorption.** Traffic is routed through a large, distributed anycast network—
   Cloudflare’s network, for example, is described as providing unmetered, unlimited
   DDoS protection at Layers 3, 4, and 7 to all customers, with mitigation handled
   by its Autonomous Edge. The network’s capacity absorbs volumetric floods before
   they reach your server. Your origin server never sees the bulk of the attack.
 * **Automatic detection and rulesets.** Managed rulesets identify known attack 
   patterns — SYN floods, DNS amplification, HTTP floods, Slowloris, botnet traffic—
   and block or challenge them. Adaptive protection learns your site’s normal traffic
   patterns and adjusts to them, which helps against attacks that mimic legitimate
   traffic.
 * **Rate limiting and connection controls.** At the application layer, rate limiting
   caps how many requests a single client can make, and web application firewall(
   WAF) rules block known malicious patterns. These run at the edge, before requests
   reach your origin.
 * **Caching.** A CDN caches static content at the edge, so repeated requests for
   the same page do not reach your server at all. Cache-busting attacks try to defeat
   this by requesting unique URLs; mitigation rules can detect that pattern and 
   challenge it.
 * **Origin hardening.** Even with edge protection, the origin server should not
   be directly reachable: firewall rules should accept traffic only from the protection
   service’s IP ranges, and the server’s real IP address should not be published
   in DNS. If attackers can find the origin IP, they can bypass the edge entirely.

Cloudflare reports that its automatic mitigation typically begins within seconds
of detection, with no manual intervention and no caps on attack size or duration
on its platform. That is a description of one provider’s service, not a universal
guarantee — always check what your own provider actually offers.

## What “DDoS protection included” may — and may not — mean

The phrase appears on many hosting plans, and it covers very different things:

 * **Network-level filtering at the data centre** (common): the provider’s upstream
   network drops obvious floods before they reach your server. This handles volumetric
   and protocol attacks reasonably well, up to the network’s capacity.
 * **Application-layer protection** (less common on basic plans): WAF rules, rate
   limiting, and bot management that understand HTTP traffic. Without this, an Layer
   7 attack can pass straight through network filtering, because each individual
   request looks like legitimate traffic.
 * **A named mitigation capacity or SLA** (check the terms): some providers state
   a capacity or an availability commitment for mitigation; others simply say “DDoS
   protection” with no numbers, no SLA, and no remedy if it fails.

Ask your provider which layers are covered, whether there is a cap on mitigated 
traffic, whether mitigation is always on or triggered manually, and what happens
if an attack exceeds the protection — is the site null-routed (taken offline deliberately
to protect the network), and for how long? [TO BE CONFIRMED: what DDoS protection
Offshore Hosting includes on each plan — confirm before publishing any such claim.]

## The practical limits

This is the part that matters most:

 1. **Protection is not prevention.** Mitigation reduces the impact of an attack; it
    does not make attacks impossible. A sufficiently large or novel attack can still
    degrade or interrupt service.
 2. **Layer 7 attacks are hard to distinguish from real traffic.** An attacker that
    mimics legitimate users — real browsers, real-looking requests, distributed across
    many IPs — is difficult to block without also blocking real visitors. Aggressive
    mitigation can cause false positives: real customers challenged, blocked, or shown
    captcha pages.
 3. **Your application is still a bottleneck.** Edge protection stops traffic that 
    never reaches you, but it cannot fix an application that does one expensive database
    query per request, or a login endpoint with no rate limiting. Harden the application
    itself: cache aggressively, rate-limit expensive endpoints, and make sure a single
    request cannot consume disproportionate resources.
 4. **DNS and email can be attacked too.** If your DNS is hosted on the same infrastructure
    as your site, a DNS flood can take both down. Separating DNS, and using a provider
    with its own DDoS protection for DNS, is part of the plan.
 5. **Origin exposure bypasses everything.** If your server’s real IP leaks — through
    an old DNS record, a mail server header, or a subdomain that points directly at
    the origin — attackers can target it directly and ignore the edge entirely. Audit
    your DNS records for direct origin exposure.
 6. **Mitigation can cost you.** Some providers charge for mitigation above a threshold,
    or null-route the target IP during a large attack. Read the terms before you need
    them, not during an incident — and read the SLA the way our guide to [reading a hosting SLA and uptime claim](https://offshorehosting.pk/blog/read-hosting-sla-uptime-claim/)
    explains.
 7. **DDoS protection is not security in general.** It does not patch software, stop
    intrusion, prevent data theft, or authenticate email. Pair it with HTTPS ([SSL certificates and HTTPS](https://offshorehosting.pk/blog/ssl-certificates-https-explained/)),
    email authentication ([SPF, DKIM, and DMARC](https://offshorehosting.pk/blog/set-up-spf-dkim-dmarc/)),
    and the rest of your security baseline.

## What to do before an attack

 * Put a CDN or edge protection service in front of the site **before** you are 
   attacked. Setting one up during an incident, while DNS is being changed and caches
   are cold, is far harder.
 * Hide the origin IP: proxy all DNS records, remove old records that point directly
   at the server, and firewall the origin to accept only the protection service’s
   traffic.
 * Enable caching for static content and rate-limit login, search, and form endpoints.
 * Keep a known-good backup off the server, and know how to restore it.
 * Have a communication plan: who decides to escalate, how customers are told, and
   where status updates are posted.
 * Monitor: set up alerts for traffic spikes and error rates, so you notice an attack
   in minutes, not hours.

## During an attack

Stay calm and work the checklist: confirm it is an attack rather than a traffic 
spike or a broken deployment; check the protection service’s dashboard for what 
is being blocked; tighten rate limits on the affected endpoints; contact your hosting
provider and ask what they are seeing upstream; and communicate with your users.
Do not make infrastructure changes in the middle of an incident unless you have 
tested them — a wrong firewall rule can finish what the attacker started.

## Key takeaways

 * DDoS attacks come in three kinds — volumetric, protocol, and application-layer—
   and each needs a different defence.
 * Edge networks absorb volume; WAF and rate limiting handle application-layer abuse;
   origin hardening closes the bypass.
 * “DDoS protection included” varies enormously: ask which layers are covered, whether
   there are caps, and what happens when protection is exceeded.
 * Application-layer attacks can look like legitimate traffic, and over-aggressive
   mitigation can block real users.
 * Protection is a layer, not a guarantee. Harden the application, hide the origin,
   cache aggressively, and have a plan before you need it.

## Sources

 * Cloudflare Docs, “About Cloudflare DDoS Protection” — https://developers.cloudflare.
   com/ddos-protection/about/
 * Cloudflare, “Mitigate DDoS Attacks” — https://developers.cloudflare.com/use-cases/
   application-security/ddos/
 * Cloudflare Learning Paths, “DDoS Protection” — https://developers.cloudflare.
   com/learning-paths/application-security/default-traffic-security/ddos/
 * AEserver, “DDoS Attacks in UAE: Complete Guide to Types and Protection” — https://
   www.aeserver.com/ddos-attack-dubai-uae/

## Sources

 * {‘title’: ‘About Cloudflare DDoS Protection’, ‘url’: ‘https://developers.cloudflare.
   com/ddos-protection/about/’}
 * {‘title’: ‘Mitigate DDoS Attacks’, ‘url’: ‘https://developers.cloudflare.com/
   use-cases/application-security/ddos/’}
 * {‘title’: ‘DDoS Protection — Cloudflare Learning Paths’, ‘url’: ‘https://developers.
   cloudflare.com/learning-paths/application-security/default-traffic-security/ddos/’}
 * {‘title’: ‘DDoS Attacks in UAE: Complete Guide to Types and Protection’, ‘url’:‘
   https://www.aeserver.com/ddos-attack-dubai-uae/’}