Dedicated Server DDoS Protection: How It Works & What to Look For

A firewall stops unauthorized access. It does nothing against a volumetric flood of 50 Gbps of junk traffic saturating your uplink before a single packet reaches your iptables rules. That is the core thing to understand about DDoS (Distributed Denial of Service) protection: it operates upstream of your server, at the network edge, and it is either provisioned by your hosting provider or it is not — there is no host-based configuration that substitutes for it once an attack exceeds your own port's bandwidth.

Why "Distributed" Is the Key Word

The distributed part of DDoS is what makes it fundamentally harder to defend against than a simple denial-of-service from one source. A single attacking IP is trivial to block with a single firewall rule; an attack coordinated across tens of thousands of compromised devices in a botnet, each sending a small amount of traffic from a different source address, cannot be meaningfully filtered by IP-based blocking at all — by the time you have identified and blocked one source, the attack has already shifted weight onto thousands of others. This is precisely why effective mitigation happens through traffic pattern analysis and scrubbing infrastructure rather than a growing blocklist.

What a DDoS Attack Actually Looks Like

The term covers several distinct attack types, and the right defense differs by type:

Volumetric and protocol attacks are stopped at the network edge, before traffic reaches your server — this is what "DDoS protection" from a hosting provider almost always refers to. Application-layer attacks often require a separate layer (a WAF or rate-limiting reverse proxy like Cloudflare in front of your origin) because the traffic looks like normal HTTP requests to network-level scrubbing.

Volumetric Attacks in Detail

A UDP flood simply sends a high volume of UDP packets to random or specific ports, forcing the target to process (and typically reject) each one, consuming bandwidth and processing capacity purely through volume. DNS and NTP amplification attacks are more efficient for the attacker: they spoof the victim's IP as the source of a small query sent to an open DNS resolver or NTP server, which then sends a much larger response to the victim — amplification factors of 50x or more are well documented, meaning an attacker with modest bandwidth can generate a genuinely large attack against the victim by abusing third-party misconfigured servers as unwitting amplifiers.

Protocol Attacks in Detail

A SYN flood exploits the TCP three-way handshake: the attacker sends a flood of SYN packets (the first step of a connection) without ever completing the handshake, exhausting the server's connection state table with half-open connections until it can no longer accept legitimate new connections. SYN cookies (covered below) are the standard server-side mitigation, but a sufficiently large flood still needs network-edge filtering since even efficient SYN cookie handling has throughput limits.

Application-Layer Attacks in Detail

An HTTP flood sends a high volume of apparently legitimate GET/POST requests, often targeting specifically expensive endpoints (a search function, a report generator, anything that triggers heavy database work) to maximize resource consumption per request rather than relying on raw volume. Slowloris takes the opposite approach: it opens many connections and sends data extremely slowly, keeping connections open and exhausting the server's connection pool without ever needing high bandwidth at all — a small number of well-crafted slow connections can take down a poorly configured web server.

How Provider-Side DDoS Mitigation Actually Works

Always-On Mitigation

All inbound traffic is routed through scrubbing infrastructure continuously, and malicious traffic is filtered before ever reaching your server's uplink. This adds negligible latency in modern setups and means there is no detection lag — the tradeoff is typically a higher baseline cost since the scrubbing infrastructure runs at all times regardless of whether you are under attack.

On-Demand (Reactive) Mitigation

Traffic flows normally until the provider's detection system identifies an attack pattern, at which point traffic gets rerouted through scrubbing. This is cheaper day-to-day, but the detection-to-mitigation window (often 30 seconds to a few minutes) means the start of an attack can still cause visible downtime before protection kicks in.

Null-Routing (Blackhole) — the Blunt Fallback

If mitigation capacity is exceeded or unavailable, some providers will null-route (blackhole) the targeted IP entirely — meaning your server goes fully offline, but the attack stops consuming shared network capacity that would otherwise affect other customers. This is a last resort, not real protection, and worth explicitly asking about since some budget "DDoS protected" plans quietly rely on it.

How Scrubbing Centers Actually Distinguish Attack Traffic From Real Traffic

Modern scrubbing infrastructure uses a combination of signature-based detection (known attack patterns like specific amplification signatures), behavioral/anomaly detection (comparing current traffic patterns against a learned baseline of your normal traffic), and rate-based thresholds per source. Sophisticated always-on providers maintain a rolling baseline profile of your typical traffic, which is why the same absolute traffic volume might be flagged as an attack for a normally low-traffic site but pass through unfiltered for a site that regularly sees that volume — this baseline-awareness is a meaningful quality difference between basic and enterprise-tier mitigation services.

Anycast Networks and Why They Matter for Mitigation Capacity

Larger DDoS mitigation providers use Anycast routing, announcing the same IP address from many geographically distributed scrubbing locations simultaneously, so an attack's traffic is automatically distributed and absorbed across the entire global network rather than concentrated at a single point. This is a major reason enterprise-tier mitigation can advertise multi-Tbps capacity — no single data center actually needs to absorb that entire volume alone, the load is inherently spread by the network topology itself.

What to Do During an Active Attack

1. Confirm it is actually a DDoS attack and not an unrelated application bug or a legitimate traffic spike (a viral link, a marketing campaign) — check traffic source diversity and request patterns before assuming malicious intent
2. Contact your provider's emergency/abuse line immediately if mitigation has not automatically engaged, rather than waiting to see if it resolves on its own
3. If you have a CDN/WAF layered in front of your origin, enable a stricter security mode (Cloudflare's "Under Attack Mode" or equivalent) which adds a JS challenge before requests reach your origin
4. Avoid making unrelated infrastructure changes mid-attack (do not restart services repeatedly, do not change DNS) since it introduces confounding variables that make the incident harder to diagnose afterward
5. Document the attack timeline, traffic characteristics, and mitigation response for a post-incident review, and to support any SLA-related credit claim if applicable

DDoS Protection Tiers Compared

Application-Layer Protection: What Network-Level Mitigation Misses

An HTTP flood or Slowloris attack sends technically valid requests, so network-edge scrubbing (which mostly analyzes packet patterns, not application semantics) often lets it through. For these, layer a CDN/WAF (Cloudflare, and similar services) in front of your origin server, which can rate-limit and challenge (CAPTCHA/JS challenge) suspicious application-layer traffic before it ever reaches your dedicated server's web stack.

Server-Side Hardening That Complements Network DDoS Protection

• SYN cookies enabled (net.ipv4.tcp_syncookies = 1 in /etc/sysctl.conf) to resist SYN flood exhaustion of connection tables
• Rate limiting at the web server level (nginx limit_req_zone, or Apache mod_ratelimit) against application-layer floods
• Reasonable connection and timeout limits so a single attacking client cannot hold disproportionate server resources
• Firewall rules (see our firewall configuration guide) to drop obviously malformed or spoofed packets close to the host as a last line of defense

A Practical nginx Rate-Limiting Configuration

A basic but genuinely effective rate-limiting zone for a public web server, defending specifically against application-layer request floods:

http {
    limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
    limit_conn_zone $binary_remote_addr zone=addr:10m;

    server {
        location / {
            limit_req zone=general burst=20 nodelay;
            limit_conn addr 20;
        }
    }
}

This allows a burst of up to 20 requests before enforcing a sustained rate of 10 requests per second per client IP, and caps each IP to 20 simultaneous connections — generous enough for normal browsing behavior (a page load with several assets) while meaningfully throttling a scripted flood from a single source. Tune the rate and burst values against your own real traffic patterns before relying on them in production, since overly aggressive limits will rate-limit legitimate users behind shared corporate NAT or a CDN.

Additional Kernel-Level Tuning

Beyond SYN cookies, a few additional sysctl settings help a server absorb connection-table pressure more gracefully during a protocol-layer attack:

net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_synack_retries = 2
net.core.somaxconn = 4096

These increase the queue depth for half-open and pending connections and reduce the number of retransmission attempts for unanswered SYN-ACKs, both of which reduce how long attack-related connection state lingers in memory.

DDoS Attacks Against Game Servers: A Special Case

Game servers are disproportionately targeted compared to their traffic volume or business value, largely because attacks are cheap to launch (readily available "booter" or "stresser" services rent out botnet capacity for a small fee) and the motive is often as simple as a disgruntled player disrupting a match rather than any financial gain. Game server traffic is also predominantly UDP with tight latency requirements, meaning even a fairly modest attack that would be a non-issue for a website can cause severe, immediately noticeable lag or full disconnection for players well before the attack approaches your uplink's theoretical capacity limit. If you run public game servers, confirm your provider's DDoS mitigation is explicitly tested against UDP-based game traffic patterns, not just generic HTTP/web traffic profiles, since some scrubbing configurations are tuned primarily for web traffic and handle game protocols less gracefully.

Real-World Attack Size Trends

Attack sizes have grown substantially over the past several years — attacks in the hundreds of Gbps range that would once have been considered exceptional are now reported with some regularity against larger targets, and multi-Tbps attacks, while still relatively rare, are no longer purely theoretical. For most small-to-mid-sized dedicated server customers, the realistic threat profile remains attacks in the single-digit-to-low-double-digit Gbps range, but the trend line matters when evaluating a provider's stated mitigation capacity — a plan advertising "10 Gbps protection" that was adequate five years ago may represent a meaningfully thinner safety margin against today's more common attack sizes.

What to Ask a Provider Before You Assume You Are Covered

1. Is DDoS protection always-on or reactive, and what is the actual detection time in the reactive case?
2. What is the mitigation capacity in Gbps, and is that shared across all customers or dedicated to your traffic?
3. Does the plan null-route (take you fully offline) once a certain attack size is exceeded, and at what threshold?
4. Is application-layer (Layer 7) protection included, or only network-layer (Layer 3/4)?
5. Is there an additional cost during an active attack, or is mitigation capacity included in the base price?

Common Misconceptions

• "My firewall protects me from DDoS" — a host-based firewall cannot stop traffic that already saturated the uplink before reaching it
• "DDoS protection means I'm immune" — it means attacks up to the provider's mitigation capacity are absorbed; sufficiently large or sophisticated attacks can still cause partial impact
• "Only big targets get attacked" — game servers, small e-commerce sites, and competitor-vs-competitor attacks in gaming/hosting niches are extremely common targets regardless of size
• "A VPN or proxy in front of my server is the same as real DDoS mitigation" — a consumer VPN has no meaningful scrubbing capacity and will itself be overwhelmed by a genuine volumetric attack
• "DDoS attacks only target websites" — DNS servers, mail servers, VoIP infrastructure, and game servers are all common and frequent targets independent of HTTP traffic

Comparing DDoS Protection Approaches: Provider-Native vs Third-Party Overlay

For any service with both a public web presence and non-HTTP components (a game server, a mail server, a custom API on a non-standard port), layering both approaches is the only way to get comprehensive coverage — a CDN alone leaves everything outside HTTP/HTTPS traffic completely unprotected.

Buyer's Checklist

• Confirm always-on vs reactive mitigation, and the real-world detection time for reactive plans
• Get the mitigation capacity in writing (Gbps/Tbps), not just the word "protected"
• Ask specifically about the null-route threshold and policy
• Check whether Layer 7 (application) protection is included or requires a separate CDN/WAF layer
• Review your SLA to see whether DDoS-caused downtime is excluded from uptime guarantees

Frequently Asked Questions

Is DDoS protection included with all dedicated servers?

It varies widely by provider — some include basic mitigation by default, others charge extra or offer it only as an add-on tier. Always confirm explicitly rather than assuming.

Can a small website really be a DDoS target?

Yes — game servers, small e-commerce competitors, and forums are common targets of low-sophistication but still disruptive attacks, often from readily available "booter" services rather than nation-state actors.

Does DDoS protection slow down normal traffic?

Modern always-on scrubbing adds negligible latency (typically single-digit milliseconds); the tradeoff is cost, not performance, in most reputable setups.

What size of attack should I expect to plan for?

Attacks in the 1-20 Gbps range are common against small-to-mid targets; ensure your provider's mitigation capacity comfortably exceeds your uplink's own bandwidth, not just matches it.

Is Cloudflare enough on its own, without provider-level DDoS protection?

Cloudflare (or similar) protects HTTP/HTTPS traffic well but does not protect non-HTTP services (game servers, custom TCP/UDP protocols, mail, direct IP access) — you still need network-level protection at the server itself for those.

How do I know if I am currently under a DDoS attack?

Sudden, sustained spikes in inbound traffic or connection counts on your monitoring dashboard, paired with degraded response times or full unreachability, are the typical signature.

Can I DDoS-protect a game server the same way as a website?

Network-edge, always-on mitigation works for both, but application-layer tools built for HTTP (a typical CDN/WAF) generally do not apply to game server protocols — confirm your provider's mitigation explicitly covers the UDP/TCP ports and protocols your specific game title uses.

Does changing my server's IP address help after an attack?

It can provide temporary relief if the attacker only has your old IP and no easy way to discover the new one, but it is not a durable fix — any service that publicly reveals your new IP again (a misconfigured CDN, a leaked DNS record, or a determined attacker probing your domain) reopens the same exposure.

Should I worry about DDoS attacks if my traffic is very low?

Low-traffic sites and servers are not immune — many attacks are opportunistic or personally motivated (a disgruntled former employee, a gaming rival, a dispute in an online community) rather than scaled to the target's actual traffic volume, so "we are too small to be a target" is not a safe assumption.

What is a reasonable amount to budget for DDoS protection?

Basic always-on protection is frequently included at no extra cost with reputable dedicated server plans; higher-capacity or application-layer add-ons typically range from a modest monthly fee up to significantly more for enterprise-grade, multi-Tbps guaranteed capacity — request specifics rather than assuming a bundled "DDoS protected" label covers your actual risk profile.

WebsNP includes network-level DDoS mitigation on our dedicated server plans as standard, not a pricey add-on. View our dedicated server plans or talk to our team about mitigation capacity for your specific traffic profile.