限制 SYN 扫描与 SYN Flood 攻击防护

🔍 什么是 SYN-RECV？

• SYN-RECV 状态表示服务器收到了 TCP SYN 请求，但尚未完成握手。 • 常见原因：

正常的 TCP 连接（短暂的 SYN-RECV 是正常现象）。
SYN Flood 攻击（大量 SYN-RECV，但连接未完成）。
端口扫描（黑客或爬虫在探测你的服务器）。

如果 SYN-RECV 持续数量过多，可能会导致服务器资源耗尽，甚至被拒绝服务攻击（DDoS）。

⸻

🛠 1. 使用 iptables 限制 SYN 请求

你可以限制每秒最大 SYN 连接数，防止 SYN Flood 攻击：

sudo iptables -A INPUT -p tcp --syn -m limit --limit 10/s --limit-burst 20 -j ACCEPT

–limit 10/s：限制每秒最多 10 个新 SYN 请求
–limit-burst 20：允许最大突发 20 个 SYN 请求

如果发现 SYN 攻击流量很高，可以继续适当降低：

sudo iptables -A INPUT -p tcp --syn -m limit --limit 5/s --limit-burst 10 -j ACCEPT

⸻

🛑 可能的不利影响

合法用户的高并发连接可能受限
如果你的服务器处理大量并发请求（如 API、网站、数据库），此规则可能会限制正常流量，导致用户访问变慢或请求失败。
解决方案：
对 Web 服务器（如 Nginx、Apache）增加 keepalive 连接，减少 SYN 请求：

keepalive_timeout 75;

适当提高 iptables 允许的 SYN 速率，比如：

sudo iptables -A INPUT -p tcp --syn -m limit --limit 50/s --limit-burst 100 -j ACCEPT

🛠 2. 使用 iptables 丢弃长期 SYN-RECV 连接

如果某些 SYN-RECV 状态的连接持续过久，可以丢弃这些连接：

sudo iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 10 -j DROP

• 这个规则限制每个 IP 最大 SYN 连接数为 10，超出则丢弃。

⸻

🔴 影响：

影响 NAT 用户（同一 IP 访问受限）
如果多个用户通过同一 NAT 路由访问，他们可能会因为共享 IP 达到连接上限，导致部分用户访问失败。
解决方案：
提高 connlimit-above 值，例如：

sudo iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 50 -j DROP

• 仅对特定端口（如 SSH）限制：


sudo iptables -A INPUT -p tcp --syn --dport 22 -m connlimit --connlimit-above 5 -j DROP

🛠 3. 使用 sysctl 调整 TCP SYN 队列

提高 SYN 处理能力，减少服务器因 SYN-RECV 被耗尽：

sudo sysctl -w net.ipv4.tcp_max_syn_backlog=4096
sudo sysctl -w net.ipv4.tcp_synack_retries=2
sudo sysctl -w net.ipv4.tcp_syncookies=1

tcp_max_syn_backlog=4096：增加 TCP 半连接队列，减少丢失。
tcp_synack_retries=2：减少重试次数，缩短 SYN-RECV 状态。
tcp_syncookies=1：开启 SYN Cookies，防止 SYN Flood 攻击。

永久生效

echo "net.ipv4.tcp_max_syn_backlog=4096" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.tcp_synack_retries=2" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.tcp_syncookies=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

⸻

🔴 影响：

可能影响 TCP 连接稳定性
tcp_synack_retries=2 可能会导致网络波动时连接超时，因为服务器在 2 次 SYN-ACK 失败后就放弃连接。
解决方案：
增加重试次数（但不过高）：

sudo sysctl -w net.ipv4.tcp_synack_retries=3

SYN Cookies 可能影响性能
tcp_syncookies=1 开启 SYN Cookies 后：
无法使用 TCP Fast Open（TFO）
影响某些负载均衡策略
解决方案：
仅在检测到 SYN Flood 时开启：

sudo sysctl -w net.ipv4.tcp_syncookies=0

🛠 4. 使用 fail2ban 自动封锁 SYN 扫描

如果攻击者不断发送 SYN 请求，你可以使用 fail2ban 来自动封锁可疑 IP：

sudo apt install fail2ban -y

创建规则 /etc/fail2ban/jail.local：

[syn-flood]
enabled = true
port = http,https,ssh
filter = syn-flood
logpath = /var/log/syslog
maxretry = 10
findtime = 60
bantime = 3600

然后重启 fail2ban：

sudo systemctl restart fail2ban

这会在 60 秒内检测到 10 次 SYN 连接失败时封锁 IP 1 小时。

⸻

🔴 影响：

可能误封合法用户
如果某个用户短时间内发起多个 TCP 连接，但并非恶意访问，仍可能被误封。
解决方案：
增加 maxretry 值（如 maxretry = 20）。
允许信任的 IP 访问：

sudo fail2ban-client set syn-flood ignoreip 192.168.1.0/24

📌 总结

✅ 防止 SYN Flood：iptables 限制 SYN 速率
✅ 丢弃恶意 SYN-RECV：iptables 限制并丢弃多余连接
✅ 优化服务器 TCP 参数：sysctl 增强 TCP 处理能力
✅ 自动封禁可疑 IP：fail2ban 自动屏蔽 SYN 攻击

如果你的服务器长期 SYN-RECV 过多，建议先检查是否为正常流量，再进行上述防护措施！🚀

⸻

🔎 什么时候需要谨慎使用这些限制？

✅ 适用场景

适用情况	适合的防护策略
服务器遭遇 SYN Flood 攻击	iptables 限制 SYN 速率 & 开启 SYN Cookies
大量未知 IP 扫描 80/443 端口	fail2ban 自动封锁
大量 SYN-RECV 堆积，服务器资源被耗尽	调整 tcp_max_syn_backlog 并限制 connlimit-above

🚫 不适用场景

场景	可能的影响
API 服务器需要高并发连接	iptables 限制 SYN 可能导致连接失败
NAT 用户共享 IP 访问	connlimit 可能阻止正常访问
部分客户端网络不稳定	降低 tcp_synack_retries 可能导致掉线

📌 结论

⚠ 不要盲目阻止所有 SYN-RECV，建议逐步优化

如果服务器确实遭遇 SYN Flood 攻击，再使用 iptables 限制 SYN 速率。
如果 SYN-RECV 仅是正常网络延迟导致的，不要过度限制，避免影响正常流量。
调整 TCP 参数时要谨慎，部分设置可能影响连接稳定性。
结合 fail2ban 使用自动封锁策略，避免手动维护 IP 黑名单。

🚀 建议先分析 netstat -s | grep SYN，确定是否有真正的 SYN Flood 攻击，再决定是否进行限制！

关注我获取更多资讯

📢 公众号

💬 个人号