DDoS Protection Basics for a VPS

"DDoS" gets thrown around a lot, and a lot of advice is either magical thinking or fear-mongering. This primer explains what a distributed denial-of-service attack really is, what you can genuinely mitigate yourself on a VPS, and where you need help from upstream. No hype — just what works.

What a DDoS attack is

A denial-of-service attack tries to make your server unavailable by overwhelming it. "Distributed" means the traffic comes from many machines at once — often a botnet — so you can't just block one IP. Attacks fall into rough categories:

• Volumetric: flooding your network link with more traffic than it can carry (e.g. UDP floods, amplification).
• Protocol: exhausting connection tables (e.g. SYN floods).
• Application-layer: hammering expensive endpoints (e.g. HTTP floods against a search page).

The honest truth about scale

Large volumetric attacks saturate your network link *before traffic reaches your server*. No firewall rule on the VPS can help once the pipe is full — that has to be filtered upstream by your provider's network. What you *can* handle well are smaller floods and application-layer attacks. Set expectations accordingly.

What you can do on the server

Rate-limit at the web server

Nginx can cap requests per IP. In your http block:

limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;

Then in a location:

limit_req zone=req_limit burst=20 nodelay;

This absorbs bursts and slows abusive clients without dropping legitimate ones.

Limit concurrent connections

limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
limit_conn conn_limit 20;

Harden the kernel against SYN floods

sudo sysctl -w net.ipv4.tcp_syncookies=1
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=2048

Persist these in /etc/sysctl.d/99-hardening.conf. Our tune Linux performance guide covers more sysctl tuning.

{{SCREENSHOT}}

Put a CDN or proxy in front

The single most effective step for a website is fronting it with a CDN/reverse proxy (Cloudflare, etc.). Your origin IP hides behind theirs, and their network absorbs and filters attack traffic before it reaches you. This handles the volumetric problem you can't solve on the VPS. Keep your origin firewall locked to the proxy's IP ranges — see UFW.

Firewall the obvious noise

A default-deny firewall means only your intended ports are reachable, shrinking the attack surface. Drop invalid packets and close everything you don't serve. For game servers specifically, tighten to the exact game ports as in firewall for a game server and read DDoS protection for game servers.

Know when it's the network, not you

If your server is idle but unreachable, and your provider reports inbound flood traffic, that's a network-level attack only upstream filtering can stop. Choose a host with DDoS mitigation on their network for anything internet-facing and valuable.

Blackholing and rate-limiting at the edge

When an attack is underway and you've identified offending sources, you can drop them cheaply at the kernel before they cost you any application work. A single abusive IP:

sudo ufw deny from 203.0.113.66

For application-layer floods spread across many IPs, blocking individual addresses is a losing game — that's what rate limiting and a CDN are for. But for a handful of aggressive sources, a firewall drop is instant and free. At the network level, providers use "blackhole" routing to null-route traffic to a targeted IP during a large attack; it protects the rest of the network but takes the target offline, which is why upstream *scrubbing* (filtering bad traffic while passing good) is preferable for anything you can't afford to have down.

fail2ban for application-layer floods

fail2ban isn't just for SSH. You can point it at your web server logs to ban IPs generating abnormal request volumes or hammering expensive endpoints. A jail watching for repeated 4xx/5xx responses or excessive requests per minute can shed a surprising amount of application-layer abuse automatically, complementing Nginx's own rate limiting. See install and configure fail2ban for the jail syntax.

Design your app to degrade gracefully

The best-defended sites assume load will sometimes exceed capacity and fail gently rather than falling over. Cache aggressively so most requests never touch your database. Serve static assets from a CDN. Put expensive operations behind a queue. Set sensible timeouts so a slow flood can't tie up every worker indefinitely. These architectural choices mean that even when mitigation is imperfect, a burst of malicious traffic degrades performance instead of causing a total outage — and legitimate users mostly stay served. Load-test your setup so you know where it breaks before an attacker finds out for you.

FAQ

Can a firewall stop a DDoS?

It stops small floods and unwanted ports, but a large volumetric attack saturates your uplink before the firewall sees it. That requires upstream/network filtering.

Is a CDN really necessary?

For a public website, it's the most effective single measure — it hides your origin and absorbs attack traffic. For non-web services, rely on your provider's network protection.

Does more RAM/CPU help against DDoS?

Marginally, for application-layer floods. It won't help against volumetric attacks that fill your network link. Mitigation matters more than raw specs.

How do I tell a DDoS from a traffic spike?

Legitimate spikes usually correlate with a launch or campaign and come from diverse, real user agents. Attacks show abnormal patterns — repeated identical requests, odd geographies, or malformed packets. Good monitoring makes the difference obvious.

What you can and can't do, at a glance

It helps to be honest about where each layer stops, so you invest effort where it actually pays off:

• On the VPS (you control): web-server rate limiting, connection limits, SYN-cookie kernel settings, a default-deny firewall, fail2ban for application-layer abuse, and graceful degradation through caching and timeouts. These handle small floods and application-layer attacks well.
• At the edge (a CDN/proxy): hides your origin IP and absorbs volumetric traffic before it reaches you. This is the most effective single step for a public website.
• At the network (your host): upstream scrubbing or blackholing for large volumetric attacks that would otherwise saturate your uplink. Only your provider can do this.

The mistake to avoid is expecting server-side rules to stop an attack that fills your network link — by the time that traffic reaches your firewall, the damage is done. Match the defence to the layer: tune what you control, front public sites with a CDN, and choose a host whose network can absorb the rest.

Realistic DDoS defence is layered: server-side rate limits, a locked-down firewall, and upstream network protection. Host on infrastructure built for it — explore Nxeon VPS hosting and our security page.