DoS & DDoS Mitigation

This guide explains how to protect your Linux or Windows server against DoS and DDoS attacks with server-side measures: rate limiting with iptables and nftables, Fail2Ban, Nginx rate limiting and RDP restrictions. It also shows where server-side protection ends.

On This Page

Protection Overview

All measures at a glance — which layer they protect and which operating system they apply to.

Recommended Values

Reference values for web servers, game servers, mail servers, and general-purpose VPS.

iptables Rate Limiting Linux

SSH, HTTP/HTTPS and temporary IP blocking using the limit and recent modules.

nftables Rate Limiting Linux

SSH brute-force, HTTP flood, and SYN flood protection — more modern and readable than iptables.

Fail2Ban Linux

Automatic IP banning after too many failed attempts — ideal for SSH, HTTP, and mail servers.

Nginx Rate Limiting Linux

HTTP-level protection against Slowloris, API abuse, and HTTP floods that bypass the firewall.

Windows Firewall & RDP Windows

Restrict RDP to trusted IPs and configure account lockout policies against brute-force attacks.

Save Rules Persistently Linux

Keep iptables and nftables rules after a reboot by saving them persistently.

External DDoS Protection

When server-side measures are no longer enough — CDN, network protection, and scrubbing services.

DoS vs. DDoS: A simple DoS attack originates from a single source and can be effectively mitigated on the server itself. A distributed DDoS attack involving thousands of source IPs exceeds the capacity of a single server — here, an upstream DDoS protection service is the only effective solution.

Protection Measures at a Glance

Comprehensive DoS protection consists of multiple layers. The table below shows which measures work at which level:

Measure	Operating system	Layer	Protects against
iptables / nftables rate limit	Linux	Network	SYN floods, connection floods
Fail2Ban	Linux	Application	Brute-force, SSH attacks, HTTP scans
Nginx / Apache rate limiting	Linux	HTTP	Slowloris, HTTP floods, API abuse
Harden / relocate SSH	Linux	Service	SSH brute-force, automated scans
Windows Defender Firewall	Windows	Network	RDP brute-force, port scans
Carrier-level mitigation	All	Upstream	Volumetric DDoS attacks

Recommended Values by Server Type

The right rate limit values depend heavily on your server's purpose. The table below provides orientation values — adjust them to match your actual traffic levels:

Server Type	SSH	HTTP/HTTPS	Notes
Web Server / WordPress	3/min, burst 5	20/s, burst 100	Nginx rate limiting additionally recommended
Game Server	3/min, burst 5	—	Protect game ports (e.g. TCP 25565 for Minecraft) separately; use more generous burst values for legitimate players
Mail Server	3/min, burst 5	—	Protect SMTP (25), IMAP (993), POP3 (995) separately with Fail2Ban — brute-force on mail accounts is common
VPS / General	3/min, burst 5	10/s, burst 50	Conservative baseline — adjust per service

Tip: Start with slightly generous values and monitor your logs — limits that are too strict can block legitimate users.

1. Rate Limiting with iptables

Using the limit, hashlimit and recent modules, you can cap the number of new connections in total or per IP and time window. The rules assume the ESTABLISHED,RELATED rule from the iptables guide is already in place.

Protect SSH (port 22)

Allows on average 3 new SSH connections per minute (burst 5, in total across all IPs) — further attempts are dropped:

Terminal

iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m limit --limit 3/m --limit-burst 5 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j DROP

Protect Web Server (ports 80 / 443)

Drops new connections from a single IP that exceed 20 per second (burst 100) — protects against HTTP connection floods. Adjust the value to match your normal traffic level:

Terminal

iptables -A INPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW -m hashlimit --hashlimit-name web --hashlimit-mode srcip --hashlimit-above 20/second --hashlimit-burst 100 -j DROP iptables -A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT

Temporary IP blocking with the recent module

IPs opening more than 15 new connections within 60 seconds are automatically blocked:

Terminal

iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW -m recent --set iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW -m recent --update --seconds 60 --hitcount 15 -j DROP iptables -A INPUT -p tcp --dport 80 -j ACCEPT

2. Rate Limiting with nftables

nftables allows rate limiting to be defined directly in the configuration file — more readable and more performant than iptables:

SSH brute-force protection

Allow a maximum of 5 new SSH connections per minute (in total, not per IP) — further attempts are dropped:

Terminal

tcp dport 22 ct state new limit rate 5/minute accept tcp dport 22 ct state new drop

HTTP flood protection

Limits new HTTP connections to 100 per second — excess requests are dropped:

Terminal

tcp dport { 80, 443 } ct state new limit rate 100/second accept tcp dport { 80, 443 } ct state new drop

SYN flood protection

Drops incoming SYN packets (new TCP connection attempts) above 1000 per second (burst 2000) — reduces the impact of SYN floods:

Terminal

tcp flags syn / fin,syn,rst,ack limit rate over 1000/second burst 2000 packets drop

Add rate limiting rules directly inside the input chain of your /etc/nftables.conf — before the final DROP policy. Reload the configuration with nft -f /etc/nftables.conf.

3. Fail2Ban — Automatic IP Blocking

Fail2Ban monitors log files and automatically bans IPs that produce too many failed attempts. It works seamlessly with both iptables and nftables.

Installation

Terminal

apt update && apt install fail2ban python3-systemd # AlmaLinux / Rocky Linux: # dnf install epel-release && dnf install fail2ban

Enable SSH protection

Create a local configuration file that bans an IP for 1 hour after 5 failed SSH logins within 10 minutes. backend = systemd reads the SSH log from the systemd journal, which current Debian releases use instead of /var/log/auth.log:

/etc/fail2ban/jail.local

[sshd] enabled = true port = ssh backend = systemd maxretry = 5 bantime = 3600 findtime = 600

Start service & check status

Terminal

systemctl enable --now fail2ban fail2ban-client status sshd

4. Nginx Rate Limiting

Nginx offers built-in rate limiting at the HTTP layer — ideal against Slowloris, API abuse, and HTTP floods that have already passed the firewall.

Define a rate limit zone

Add the following line to the http block of your Nginx configuration:

nginx.conf — http block

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

Apply the rate limit to a server block

nginx.conf — server block

server { location / { limit_req zone=one burst=20 nodelay; } }

rate=10r/s allows 10 requests per second per IP. burst=20 permits short spikes up to 20 requests — excess requests beyond that are rejected with HTTP 503.

5. Rate Limiting on Windows

On Windows Server (available on Server4You Dedicated Servers), Windows Defender Firewall combined with PowerShell handles protection. Full connection rate limiting is more limited on Windows than Linux, but essential protective measures are available.

Restrict RDP Access (Port 3389)

RDP is the most common attack target on Windows servers. Restrict access to known IP addresses only. Do not add a separate block rule for port 3389 — block rules take precedence over allow rules and would lock you out. The default inbound policy already blocks all other sources:

PowerShell

New-NetFirewallRule -DisplayName "RDP restricted" -Direction Inbound -LocalPort 3389 -Protocol TCP -Action Allow -RemoteAddress 192.0.2.5 # Disable the predefined "Remote Desktop" rules that allow any IP: Disable-NetFirewallRule -Group "@FirewallAPI.dll,-28752"

Recommended Values for Windows Servers

Server Type	RDP	Recommendation
Web Server (IIS)	Admin IP only	Enable IIS Dynamic IP Restrictions module
Game Server	Admin IP only	Explicitly allow game ports, block everything else
Mail Server	Admin IP only	Only open SMTP/IMAP/POP3 ports for necessary sources

Enable Account Lockout Policy

Configure account lockout in Local Security Policy (secpol.msc) after too many failed attempts — acts like Fail2Ban for RDP and local logins:

Setting	Recommended Value
Account lockout threshold	5 failed attempts
Account lockout duration	30 minutes
Observation window	15 minutes

6. Save Rules Persistently

iptables rules are lost after a reboot. Save them persistently:

Debian / Ubuntu

Terminal

apt install iptables-persistent netfilter-persistent save

AlmaLinux / Rocky Linux

Terminal

dnf install iptables-services iptables-save > /etc/sysconfig/iptables systemctl enable --now iptables

nftables (all distributions)

Terminal

nft list ruleset > /etc/nftables.conf systemctl enable --now nftables # AlmaLinux / Rocky Linux: the service loads /etc/sysconfig/nftables.conf

7. External DDoS Protection

For volumetric DDoS attacks (multiple Gbit/s), server-side measures are ineffective — the upstream link is already saturated before packets reach the server. In this case, an upstream protection service is required:

CDN with DDoS Protection

Many CDN providers offer built-in DDoS protection — activated simply by changing your DNS records.

Server4You Network Protection

Volumetric DDoS attacks are mitigated at carrier level, before the traffic reaches our data center and your server. Server-side measures on this page add protection against smaller, targeted attacks.

Dedicated Scrubbing

Specialized DDoS protection services for enterprises with high-availability requirements.

Full Firewall Guides

For complete firewall configurations with a default-deny strategy, see our detailed guides.

iptables Guide

nftables Guide