How to stop a DDoS attack
on a Linux server

Back to Blog

Before You Start: Identify What You Are Dealing With

Applying the wrong mitigation for the wrong attack type can make things worse. A SYN flood requires different responses than a UDP amplification attack. A HTTP flood requires application-layer controls that iptables cannot apply. Before running firewall commands, spend 60-120 seconds identifying the attack characteristics.

Check your current packet and connection state with these commands:

# Check overall packet rates (PPS and bandwidth)
sar -n DEV 1 5

# See top connections by count
ss -ntu | awk 'NR>1 {print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

# See established connection count
ss -s

# Check for SYN backlog filling (SYN_RECV state)
ss -ntp state syn-recv | wc -l

# Watch real-time packet rates per protocol
watch -n1 'cat /proc/net/dev'

# Check for UDP flood (high UDP packet counters)
netstat -su | grep -i "receive\|error\|discard"

What you are looking for:

• High SYN_RECV count: SYN flood in progress
• Thousands of connections from few IPs: distributed HTTP/TCP connection flood
• UDP receive errors spiking: UDP flood or amplification attack
• High PPS with small packet sizes: volumetric flood (SYN, UDP, ICMP)
• Normal PPS but high CPU in application: HTTP flood or slowloris

Emergency Response: Drop Attack Traffic Fast

If you have identified the attack source IPs or patterns, the fastest way to stop traffic is with iptables or nftables. For a distributed attack with many source IPs, you need pattern-based rules rather than per-IP blocks.

iptables: Block by source IP (targeted attacks)

# Block a specific attacking IP immediately
iptables -I INPUT -s 203.0.113.42 -j DROP

# Block a subnet
iptables -I INPUT -s 203.0.113.0/24 -j DROP

# Block a source country using ipset (requires ipset installed)
ipset create blocklist hash:net
ipset add blocklist 203.0.113.0/24
iptables -I INPUT -m set --match-set blocklist src -j DROP

# Make rules persistent
iptables-save > /etc/iptables/rules.v4

iptables: Rate limiting for SYN floods

# Limit new SYN connections to 25/second per source IP
iptables -A INPUT -p tcp --syn -m limit --limit 25/s --limit-burst 50 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

# More granular: track per-source SYN rate
iptables -N SYN_FLOOD
iptables -A INPUT -p tcp --syn -j SYN_FLOOD
iptables -A SYN_FLOOD -m limit --limit 2/s --limit-burst 6 -j RETURN
iptables -A SYN_FLOOD -j DROP

iptables: Rate limiting for UDP floods

# Limit UDP traffic to 1000 PPS total (adjust threshold for your baseline)
iptables -A INPUT -p udp -m limit --limit 1000/s --limit-burst 2000 -j ACCEPT
iptables -A INPUT -p udp -j DROP

# Block UDP to specific amplification ports commonly used in reflection attacks
iptables -A INPUT -p udp --dport 53 -m limit --limit 100/s --limit-burst 200 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p udp --dport 123 -j DROP   # NTP
iptables -A INPUT -p udp --dport 389 -j DROP   # LDAP
iptables -A INPUT -p udp --dport 1900 -j DROP  # SSDP/UPnP

nftables: Modern equivalent (kernel 3.13+)

#!/usr/sbin/nft -f
# nftables ruleset for DDoS mitigation

table inet filter {
  set blocklist {
    type ipv4_addr
    flags interval
    elements = { 203.0.113.0/24 }
  }

  chain input {
    type filter hook input priority 0; policy accept;

    # Drop explicitly blocked sources
    ip saddr @blocklist drop

    # SYN flood protection
    tcp flags syn tcp option maxseg size 1-500 drop
    tcp flags & (fin|syn|rst|ack) == syn \
      limit rate over 25/second burst 50 packets drop

    # UDP rate limiting
    ip protocol udp limit rate over 1000/second burst 2000 packets drop

    # ICMP flood protection
    ip protocol icmp limit rate over 50/second burst 100 packets drop
  }
}

Kernel TCP/UDP Hardening with sysctl

These settings should be applied before attacks to reduce your server's exposure. They harden the kernel's TCP stack against common flood attacks and are safe to enable on production servers.

# /etc/sysctl.d/99-ddos-hardening.conf

# SYN cookie protection (defends against SYN floods without dropping valid connections)
net.ipv4.tcp_syncookies = 1

# Reduce SYN backlog hold time
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_synack_retries = 2

# Increase SYN backlog queue size
net.ipv4.tcp_max_syn_backlog = 8192

# Reduce TIME_WAIT sockets (helps during connection floods)
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1

# Disable ICMP redirects (source routing attack prevention)
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.accept_source_route = 0

# Log suspicious packets (martians)
net.ipv4.conf.all.log_martians = 1

# Increase network receive buffer (helps absorb burst traffic)
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.netdev_max_backlog = 5000

# Apply immediately
# sysctl -p /etc/sysctl.d/99-ddos-hardening.conf

tcp_syncookies = 1 is the single most important sysctl setting for SYN flood resilience. It allows the kernel to handle SYN floods without maintaining per-connection state until the handshake completes. Enable this on every server.

Automated IP Blocking with fail2ban

fail2ban monitors log files and automatically applies iptables rules when patterns matching abuse are detected. It is most effective against HTTP floods and repeated connection abuse rather than volumetric UDP floods.

# Install fail2ban
apt install fail2ban  # Debian/Ubuntu
yum install fail2ban  # RHEL/CentOS

# /etc/fail2ban/jail.d/ddos.conf
[nginx-req-limit]
enabled = true
filter = nginx-req-limit
logpath = /var/log/nginx/error.log
maxretry = 10
findtime = 60
bantime = 600
action = iptables-multiport[name=ReqLimit, port="http,https", protocol=tcp]

[ssh-ddos]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
findtime = 30
bantime = 3600

# Check currently banned IPs
fail2ban-client status nginx-req-limit

The Detection Problem: Why Reactive Mitigation Has Limits

Every manual command above assumes you already know an attack is happening. The hard part is not writing firewall rules: it is knowing you need to write them within the first 2-5 seconds of an attack, before your service degrades and your users disconnect.

Consider a UDP flood at 80,000 PPS. From the time the flood starts:

• Second 0: Attack begins. Your server's UDP receive buffers start filling.
• Second 2-5: Application processes start experiencing packet loss. Game clients begin disconnecting. HTTP responses start timing out.
• Second 15-30: Your monitoring system fires an alert (if you have one). You receive a page.
• Second 60-120: You log into the server, run diagnostic commands, identify the attack type, and apply iptables rules.

By the time you manually apply a firewall rule, the damage is largely done. The attack has already caused 1-2 minutes of degradation or downtime. For a game server, that is 60+ player disconnections. For an API endpoint, that is failed transactions and SLA violations.

This is what per-second automatic detection solves. Flowtriq monitors your server's network interface continuously and fires alerts within 1-2 seconds of attack onset. More importantly, it can automatically apply pre-configured firewall rules at the moment of detection: the same iptables or nftables commands you would run manually, but applied before you even receive the alert.

Automated Detection and Response with Flowtriq

Flowtriq installs as a lightweight agent on your Linux server. It monitors traffic at the network interface level, builds per-second baselines of normal traffic patterns, and applies automatic mitigation rules when attack signatures are detected.

# Install Flowtriq agent (single command)
curl -fsSL https://pkg.flowtriq.com/install.sh | sudo bash

# The agent starts automatically and begins baseline formation
# Check agent status
systemctl status ftagent

# View current traffic baselines (after 24-72 hours of baseline formation)
ftagent status

Flowtriq's automatic mitigation actions for Linux servers include:

• iptables DROP rules: Applied per-source IP or per-source subnet automatically when attack traffic is classified
• nftables rules: Same capability via nftables if preferred
• Rate limiting insertion: Automatic rate limit rules targeting the specific protocol and port under attack
• BGP webhook trigger: Fires a webhook to your BGP automation toolchain (ExaBGP, GoBGP) for upstream RTBH or FlowSpec if the attack exceeds server-level mitigation thresholds
• Custom script execution: Run any shell command when an attack is detected (call your CDN API, page your on-call team, update your DNS)

The key difference from manual mitigation: these rules are applied automatically within 1-2 seconds of attack detection, based on the attack classification. Flowtriq knows it is a UDP flood versus a SYN flood versus a HTTP flood and applies the appropriate rule, not a generic block. When the attack ends, the rules are automatically removed.

When Server-Level Mitigation Is Not Enough

There are attack scenarios where server-side iptables rules are insufficient regardless of how quickly they are applied:

• Attacks that saturate your network uplink before reaching your server: If a 20 Gbps attack fills your datacenter's 10 Gbps transit link, the saturation occurs upstream of your server. iptables rules on the server cannot help because the packets are being dropped at the network level before they reach your network interface. You need upstream scrubbing capacity or BGP-based RTBH to address this.
• High-PPS attacks that overwhelm kernel interrupt handling: Very high packet-rate attacks (1M+ PPS) can pin CPU cores to interrupt handling before any firewall rule can be applied. Kernel bypass solutions (DPDK, XDP/eBPF) or hardware offload may be required at this scale.
• Reflection and amplification at massive scale: DNS, NTP, and CLDAP amplification attacks can generate multi-hundred-gigabit floods. These require upstream scrubbing that operates before traffic reaches your transit provider.

For attacks within the server's ability to process (typically sub-1M PPS for modern hardware), the combination of sysctl hardening + iptables/nftables rules + automated detection and mitigation via Flowtriq is highly effective. For attacks that exceed your uplink or overwhelm your interrupt handling, upstream mitigation is required and Flowtriq's BGP webhook integration provides the detection signal to trigger it.

Frequently Asked Questions

Back to Blog

Related Articles