Preventing DDoS Attacks on Your Server: A Practical Protection Guide

Overview

A Distributed Denial of Service (DDoS) attack floods your server with fake traffic until it can’t respond to real visitors. DDoS protection isn’t a single switch you flip — it’s a layered approach that combines network-level filtering, server-side rate limiting, and traffic analysis. If your site is going down unexpectedly, or you’re seeing massive spikes in bandwidth with no clear cause, you may already be under attack.

This article covers practical mitigation steps for VPS and dedicated server users running Linux (Ubuntu 20.04/22.04 or CentOS 7/8). Some steps apply equally to managed environments; others require root access. I’ll flag which is which as we go.

It’s worth understanding upfront that no single tool stops every attack. A large volumetric attack — say, 10 Gbps of junk UDP traffic — will saturate your network port before your server even sees the packets. That’s why combining on-server tools with upstream network filtering gives you the best coverage.

Prerequisites

• Root or sudo access to your Linux server
• Ubuntu 20.04/22.04, CentOS 7/8, or AlmaLinux 8/9 (commands may vary slightly)
• Basic familiarity with the Linux command line
• SSH access confirmed and working before making firewall changes
• A backup or snapshot of your server taken before modifying firewall rules
• For managed WordPress hosting customers: contact Host & Tech support — some of these changes are handled at the infrastructure level on your behalf

Step-by-Step: Setting Up DDoS Mitigation

Step 1: Identify the Attack Type

Before you configure anything, figure out what you’re dealing with. Run the following to see active connections and spot unusual volume from specific IPs or ports:

# Count connections by IP
ss -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

# Check for SYN flood indicators
netstat -an | grep SYN_RECV | wc -l

# Watch live traffic by port
tcpdump -i eth0 -nn -c 1000 | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

If the SYN_RECV count is in the hundreds or thousands, you’re likely looking at a SYN flood. If you see a handful of IPs sending thousands of requests, that’s an application-layer (Layer 7) attack — which is actually easier to block than volumetric floods.

Step 2: Rate-Limit Connections with iptables

These rules won’t stop a massive volumetric attack, but they’ll knock out most script-kiddie floods and slow down application-layer attacks significantly.

# Limit new TCP connections to 25 per second per IP
iptables -A INPUT -p tcp --dport 80 -m limit --limit 25/second --limit-burst 100 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP

# Limit HTTPS the same way
iptables -A INPUT -p tcp --dport 443 -m limit --limit 25/second --limit-burst 100 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP

# Block invalid packets (catches some floods)
iptables -A INPUT -m state --state INVALID -j DROP

# SYN flood mitigation
iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

📝 Note: These rules are not persistent by default. On Ubuntu, install iptables-persistent and run netfilter-persistent save to survive reboots. On CentOS/AlmaLinux, use service iptables save.

⚠ Warning: Always confirm your SSH port is explicitly allowed BEFORE applying DROP rules. Locking yourself out of port 22 (or your custom SSH port) requires console access to fix.

Step 3: Install and Configure Fail2Ban

Fail2Ban monitors log files and auto-bans IPs that hit thresholds you define. It’s not just for SSH — you can configure it for Apache, Nginx, and custom applications.

# Ubuntu/Debian
apt install fail2ban -y

# CentOS/AlmaLinux
yum install fail2ban -y
systemctl enable fail2ban --now

Create a local override file — don’t edit /etc/fail2ban/jail.conf directly, because package updates will overwrite it:

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Then edit /etc/fail2ban/jail.local and update the [DEFAULT] section:

[DEFAULT]
bantime  = 3600
findtime = 600
maxretry = 5
banaction = iptables-multiport

For HTTP flood protection, add a custom jail. Create /etc/fail2ban/jail.d/http-flood.conf:

[http-flood]
enabled  = true
port     = http,https
filter   = http-flood
logpath  = /var/log/nginx/access.log
maxretry = 200
findtime = 60
bantime  = 3600

📝 Note: If you’re running Apache, change the logpath to /var/log/apache2/access.log (Ubuntu) or /var/log/httpd/access_log (CentOS).

Restart Fail2Ban to apply changes:

systemctl restart fail2ban
fail2ban-client status

Step 4: Enable SYN Cookies at the Kernel Level

This one’s non-obvious and a lot of guides skip it. SYN cookies let your kernel handle TCP handshakes without allocating memory for each half-open connection — which is exactly what a SYN flood tries to exhaust.

# Enable immediately
sysctl -w net.ipv4.tcp_syncookies=1

# Also tune the connection queue
sysctl -w net.ipv4.tcp_max_syn_backlog=2048
sysctl -w net.ipv4.tcp_synack_retries=2
sysctl -w net.ipv4.tcp_syn_retries=5

To make these persistent across reboots, add them to /etc/sysctl.conf:

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 5

Apply without rebooting:

sysctl -p

Step 5: Add a Web Application Firewall (WAF) for Layer 7 Attacks

For HTTP/HTTPS floods targeting your application, ModSecurity is the standard open-source WAF. On cPanel/WHM servers, you can enable ModSecurity directly from WHM under Security Center > ModSecurity™ Tools. Use the OWASP Core Rule Set (CRS) as a starting point.

On a standalone Nginx server, install the ModSecurity-Nginx connector:

apt install libmodsecurity3 libnginx-mod-security2 -y

Then enable it in your Nginx config by adding to the http block in /etc/nginx/nginx.conf:

modsecurity on;
modsecurity_rules_file /etc/nginx/modsecurity/modsecurity.conf;

Step 6: Use Upstream Network-Level DDoS Protection

Here’s the honest reality: if you’re getting hit with 5+ Gbps of traffic, your server’s CPU and iptables rules are already overwhelmed. The traffic is filling your uplink before your firewall can inspect it. The only solution at that scale is upstream filtering — where traffic gets scrubbed before it reaches your server.

Host & Tech’s Dedicated Servers include upstream DDoS mitigation at the network layer, which handles volumetric attacks that on-server tools simply can’t. If you’re on a VPS and getting targeted frequently, it’s worth evaluating whether a dedicated server with network-level protection better fits your requirements.

For Cloudflare users, enabling “Under Attack” mode in your Cloudflare dashboard adds a JavaScript challenge to all visitors, which eliminates most bot-based HTTP floods immediately — it’s crude but effective in an emergency.

Common Issues & Troubleshooting

iptables rules drop legitimate traffic after applying rate limits

This is common when the --limit-burst value is too low. A real user loading a page triggers multiple simultaneous connections, and aggressive limits catch them. Raise --limit-burst to 200 or higher and monitor. Also check whether a CDN or load balancer is sending all traffic from a single IP — if so, whitelist that IP before applying rate limits.

Fail2Ban is not banning IPs despite high traffic

The most common cause is a mismatched log path or a filter that doesn’t match your log format. Run fail2ban-client status http-flood and check the “Currently banned” count. Then test your filter manually:

fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/http-flood.conf

If it shows 0 matches, your regex doesn’t match your log format. Nginx and Apache log formats vary between distros and custom configs.

Server is still getting flooded even with iptables rules active

If traffic is saturating your network interface, iptables rules run too late in the stack — the packets have already consumed bandwidth. Check your interface saturation with iftop -i eth0. If you’re seeing consistent 100% utilization, this requires upstream mitigation, not on-server rules. Contact your host to engage network-level filtering.

SSH locked out after applying firewall rules

If you can no longer SSH in, you’ll need to access your server via the VPS console in the Host & Tech control panel, or request KVM/IPMI access for dedicated servers. Once in, flush all iptables rules with iptables -F and rebuild them carefully, confirming your SSH port is explicitly permitted before any DROP rules.

ModSecurity is blocking legitimate requests (false positives)

This is annoyingly common after enabling the OWASP CRS in blocking mode. I’d recommend starting in detection-only mode — set SecRuleEngine DetectionOnly in /etc/nginx/modsecurity/modsecurity.conf — then review /var/log/modsec_audit.log for false positives before switching to enforcement. Wholesale enabling blocking mode on a live site without testing first causes real outages.

FAQ