Securing Linux servers against volumetric and application-layer threats requires precise firewall rule implementation. The following configurations demonstrate how to deploy lightweight SYN flood prtoection, concurrent connection caps, and rate-based filtering to neutralize DDoS and Challenge Collapsar (CC) attacks.

1. DDoS Mitigation Strategies

The primary objective is to throttle excessive SYN requests and cap the number of simultaneous connections originating from a single source. Creating a dedicated chain isolates flood traffic from normal processing pipelines.

# Create a custom chain for SYN flood control
iptables -N tcp_syn_guard
iptables -A INPUT -p tcp --syn -j tcp_syn_guard

# Permit a baseline rate of SYN packets, dropping the rest
iptables -I tcp_syn_guard -p tcp -m limit --limit 5/s --limit-burst 10 -j RETURN
iptables -A tcp_syn_guard -j DROP

# Restrict initial TCP handshakes per source IP on the public interface
iptables -A INPUT -i ens33 -p tcp --syn -m connlimit --connlimit-above 20 --connlimit-mask 32 -j DROP

# Maintain stateful tracking for ongoing sessions
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

2. CC Attack Prevention

CC attacks typically target web applications by exhausting server resources with rapid, high-volume HTTP requests. Mitigation involves capping concurrent connections and enfrocing strict rate limits for new connections per IP address.

Prerequisites: Ensure the kernel supports connection tracking (connlimit and recent modules). Modern distributions include these by default, but custom or legacy kernels may require compiling xt\_connlimit and xt\_recent.

Implementing Per-IP Limits

By combining connection counting with temporal tracking, administrators can differentiate between legitimate traffic spikes and malicious flooding.

# Cap simultaneous HTTP connections per IP
iptables -I INPUT -p tcp --dport 80 -m connlimit --connlimit-above 40 --connlimit-mask 32 -j REJECT

# Track and limit new connection attempts per IP over a 60-second window
# Block IPs attempting more than 25 new connections within the tracking window
iptables -A INPUT -p tcp --dport 80 -m recent --name http_abuse_tracker --update --seconds 60 --hitcount 25 -j DROP
iptables -A INPUT -p tcp --dport 80 -m recent --name http_abuse_tracker --set -j ACCEPT

3. Verification and Monitoring

Testing these rules requires simulating connection floods using benchmarking utilities or custom scripts. To monitor the effectiveness of the rules in real-time, administrators can track active sockets and inspect packet counters:

# Track active connections from a specific source IP
watch -n 2 'ss -tn state established | grep <attacker_ip> | wc -l'

# Inspect dropped packets attributed to the offending IP
watch -n 2 'iptables -L INPUT -n -v | grep <attacker_ip>'</attacker_ip></attacker_ip>

4. Optimizing Kernel Modules

The xt\_recent module maintains an internal list of tracked IP addresses and packet counts. Default limits may be too low for busy servers, causing premature eviction of legitimate entries. Adjust the module parameters to expand tracking capacity:

# Configure module options via modprobe.d
echo "options xt_recent ip_list_tot=1000 ip_pkt_list_tot=60" | tee /etc/modprobe.d/iptables_recent.conf
# Apply changes by reloading the module
modprobe -r xt_recent && modprobe xt_recent

Increasing ip\_list\_tot allows tracking more unique IPs simultaneously, while ip\_pkt\_list\_tot defines how many packets per IP are recorded within the tracking window. These adjustments ensure the firewall maintains accurate state during high-traffic events without dropping valid connections due to internal buffer limits.