DoS & DDoS Mitigation
Denial-of-Service attacks overwhelm your server with requests until it becomes unreachable. This guide covers what protective measures you can implement directly on your server.
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 | Layer | Protects against |
|---|---|---|
| iptables / nftables Rate Limit | Network | SYN floods, connection floods |
| Fail2Ban | Application | Brute-force, SSH attacks, HTTP scans |
| Nginx / Apache Rate Limiting | HTTP | Slowloris, HTTP floods, API abuse |
| Harden / relocate SSH | Service | SSH brute-force, automated scans |
| External DDoS protection | 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. UDP 25565) 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 |
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 and recent modules, you can cap the number of new connections per IP and time window.
Protect SSH (port 22)
Allow a maximum of 3 new connections per minute — further attempts are dropped for 1 minute once the limit is reached:
Protect Web Server (ports 80 / 443)
Limits established connections to 20 per second per IP — protects against Slowloris and HTTP floods. Adjust the value to match your normal traffic level:
Temporary IP blocking with the recent module
IPs sending more than 15 new packets within 60 seconds are automatically blocked:
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 per IP — further attempts are dropped:
HTTP flood protection
Limits new HTTP connections to 100 per second — excess requests are dropped:
SYN flood protection
Drops TCP packets without a valid connection state — significantly reduces SYN flood attacks:
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
Enable SSH protection
Create a local configuration file that bans SSH addresses for 1 hour after 5 failed attempts:
Start service & check status
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:
Apply the rate limit to a server block
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 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:
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
CentOS / RHEL
nftables (all distributions)
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:
Full Firewall Guides
For complete firewall configurations with a default-deny strategy, see our detailed guides.