Survive DDoS Attacks: Server Defenses Every E‑Commerce Site Needs

Running an e‑commerce site means your business depends on a web server that stays online even when attackers try to overwhelm it. Distributed Denial‑of‑Service (DDoS) attacks are common, and while no single technique guarantees 100 % protection, a layered, server‑level defense can significantly reduce their impact. This guide shows practical steps you can apply on a typical Linux VPS or dedicated server—whether you use Debian/Ubuntu (apt) or AlmaLinux/Rocky Linux 8 (dnf). The focus is on configurations you control directly, without relying on external CDNs or third‑party mitigation services.

1. Harden the Network Stack

The kernel processes every incoming packet before any application logic runs. Tweaking sysctl parameters helps the server handle sudden traffic spikes and drop malformed packets that attackers often use.

Debian / Ubuntu (apt)

# Edit /etc/sysctl.conf and add:
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_fin_timeout = 15
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_rmem = 4096 87380 6291456
net.ipv4.tcp_wmem = 4096 16384 4194304
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 5000
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Apply changes immediately
sudo sysctl -p

AlmaLinux / Rocky / RHEL (dnf)

# Edit /etc/sysctl.conf with the same lines
sudo vi /etc/sysctl.conf
sudo sysctl -p

What each setting does:

• tcp_syncookies – protects against SYN floods by generating cookies instead of allocating a full connection slot.
• tcp_max_syn_backlog – expands the queue for half‑open connections.
• tcp_tw_reuse – allows TIME_WAIT sockets to be reused, freeing resources faster.
• somaxconn – raises the limit for pending connections that a listening socket can accept.

2. Deploy Rate Limiting with iptables or nftables

Blocking traffic purely by IP is ineffective against large botnets, but limiting the rate of new connections per source can stop many volumetric attacks.

Using iptables (both families)

# Limit new TCP connections to 10 per minute per IP on port 80/443
sudo iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW \
    -m recent --set --name HTTP
sudo iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW \
    -m recent --update --seconds 60 --hitcount 10 --rttl --name HTTP -j DROP

sudo iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW \
    -m recent --set --name HTTPS
sudo iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW \
    -m recent --update --seconds 60 --hitcount 10 --rttl --name HTTPS -j DROP

# Save rules
# Debian/Ubuntu
sudo netfilter-persistent save
# AlmaLinux/Rocky
sudo service iptables save

Using nftables (modern alternative)

# Create a table and chain for HTTP/HTTPS
sudo nft add table inet filter
sudo nft add chain inet filter input { type filter hook input priority 0; }

# Rate limit rule (10 connections per minute per IP)
sudo nft add rule inet filter input ip protocol tcp ip dport {80,443} ct state new \
    limit rate 10/minute burst 20 reject

# Persist the configuration
sudo sh -c 'nft list ruleset > /etc/nftables.conf'

These rules allow legitimate users to connect while silently dropping bursts that exceed normal browsing patterns.

3. Enable Application‑Level Throttling

Web servers and application frameworks often provide modules to limit request rates per client. Configuring them adds another barrier before traffic reaches your code.

NGINX (common on both OS families)

# /etc/nginx/conf.d/limit_req.conf
limit_req_zone $binary_remote_addr zone=perip:10m rate=5r/s;

server {
    listen 80;
    server_name example.com;

    location / {
        limit_req zone=perip burst=10 nodelay;
        proxy_pass http://backend;
    }
}

The limit_req_zone directive creates a shared memory zone that tracks requests per IP. The example caps each client at five requests per second, with a short burst allowance.

Apache (mod_ratelimit)

# Enable the module (Debian/Ubuntu)
sudo a2enmod ratelimit
sudo systemctl restart apache2

# /etc/apache2/conf-available/ratelimit.conf
<IfModule mod_ratelimit.c>
    SetOutputFilter RATE_LIMIT
    SetEnv rate-limit 400
</IfModule>

Apache’s mod_ratelimit controls bandwidth rather than connection count, helping prevent a single client from exhausting outbound capacity.

4. Protect Critical Services with Fail2Ban

Fail2Ban watches log files for abuse patterns (e.g., repeated 404s, login failures) and automatically adds temporary iptables bans.

Installation

# Debian / Ubuntu
sudo apt update
sudo apt install fail2ban

# AlmaLinux / Rocky
sudo dnf install epel-release
sudo dnf install fail2ban

Basic Jails for HTTP

# /etc/fail2ban/jail.local
[http-get-dos]
enabled = true
filter = http-get-dos
action = iptables[name=HTTP, port=http, protocol=tcp]
logpath = /var/log/nginx/access.log
maxretry = 100
findtime = 60
bantime = 600

The http-get-dos filter (included with Fail2Ban) triggers when a single IP makes more than 100 requests within a minute, temporarily blocking it for ten minutes.

5. Optional Advanced Step: SYN‑Proxy and Connection Queueing

For sites that experience large‑scale SYN floods, enabling SYN‑proxy offloads the handshake to the kernel, discarding bogus SYN packets before they consume resources.

Enable SYN‑proxy (both families)

# Add to /etc/sysctl.conf
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_synack_retries = 5
net.ipv4.tcp_syn_retries = 5
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_fastopen = 3

sudo sysctl -p

These settings increase the backlog and allow the kernel to handle more half‑open connections without allocating full socket structures.

6. Monitor and Respond in Real Time

Even with strong defenses, visibility is essential. Set up lightweight monitoring that alerts you when traffic patterns deviate.

• netstat / ss – watch for unusually high counts of SYN_RECV sockets.
• vnStat or iftop – track bandwidth spikes.
• Prometheus + Grafana – collect node_exporter metrics and create alerts for CPU, memory, and network thresholds.

Example command to list SYN‑RECV sockets:

ss -s | grep SYN‑RECV

If you notice a sustained rise, consider temporarily increasing tcp_max_syn_backlog or scaling out to additional servers behind a load balancer.

Conclusion

Protecting an e‑commerce platform from DDoS attacks starts with a hardened network stack, layered rate limiting, and application‑level throttling. Tools such as iptables, nftables, Fail2Ban, and web‑server modules give you concrete controls that work directly on your VPS or dedicated server, regardless of whether you run Debian/Ubuntu or AlmaLinux/Rocky. Combined with real‑time monitoring, these measures help you absorb most volumetric attacks, keep checkout pages responsive, and maintain customer trust.