TCP SYN Flood攻击防御实战：内核参数与防火墙配置

作者

SYN Flood 是最经典的 DDoS 攻击之一：攻击者大量发送伪造源地址的 SYN 包却不完成三次握手，耗尽服务器半连接队列导致服务拒绝。本篇给出 Linux 内核参数、iptables、Nginx 与上游高防四层的 SYN Flood 防御配置。

适用场景

  • 服务器出现大量 SYN_RECV 状态连接、业务卡顿或端口无响应
  • 公网服务器遭受协议型 DDoS 攻击初期的自救
  • 新服务器上线前的防护基线配置

前置条件

  • Linux 内核 3.10+（本文参数通用适用于 CentOS/Debian/Ubuntu）
  • root 权限
  • Nginx 1.12+（应用层部分可选）
  • 云服务器需确认厂商提供的基础 DDoS 防护与高防能力

SYN Flood 攻击原理

TCP 三次握手中，服务器收到 SYN 后分配半连接资源并回复 SYN-ACK，等待第三次 ACK。攻击者伪造源地址发送海量 SYN 且永不回复，半连接队列被占满后新连接无法建立。核心防御思路：缩短半连接超时、开启 SYN Cookie 改为无状态应答、入口层过滤伪造流量。

操作步骤

第一步：内核参数加固（关键防线）

# /etc/sysctl.d/99-anti-synflood.conf
# 开启 SYN Cookie：不占半连接队列，无状态应答
net.ipv4.tcp_syncookies = 1
# 半连接队列长度调大（默认 128 远不够）
net.ipv4.tcp_max_syn_backlog = 65536
# SYN-ACK 重试次数从 5 降到 1，快速释放伪造连接
net.ipv4.tcp_synack_retries = 1
# 开启 TIME_WAIT 复用
net.ipv4.tcp_tw_reuse = 1
# 全连接队列与本地端口范围
net.core.somaxconn = 65536
net.ipv4.ip_local_port_range = 1024 65000
# 连接状态追踪表上限
net.netfilter.nf_conntrack_max = 1048576

sysctl -p /etc/sysctl.d/99-anti-synflood.conf
sysctl net.ipv4.tcp_syncookies   # 输出 = 1 即生效

第二步：iptables 限制新建连接速率

# 单 IP 并发连接超 50 直接丢弃
iptables -A INPUT -p tcp --syn --dport 443 -m connlimit --connlimit-above 50 -j DROP
# 单 IP 每秒新建连接超 10 限速丢弃
iptables -A INPUT -p tcp --syn --dport 443 -m hashlimit \
  --hashlimit-name syn_flood --hashlimit-above 10/sec \
  --hashlimit-burst 20 --hashlimit-mode srcip -j DROP

# 丢弃无 SYN 标志组合的非法 TCP 包（伪造流量特征）
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP

iptables-save > /etc/iptables/rules.v4

第三步：Nginx 层收敛握手压力

# nginx.conf 关键参数
worker_rlimit_nofile 100000;
events {
    worker_connections 50000;   # 单进程连接上限
}
http {
    # 缩短无效连接占用时间
    client_header_timeout 10s;
    keepalive_timeout 30s;
}

nginx -t && systemctl reload nginx
# 文件描述符上限（永久生效写入 /etc/security/limits.conf）
ulimit -n 100000

第四步：上游高防兜底

单机防护对 10Gbps 以上的攻击无能为力，需在上游接入高防：

  • 云厂商开启 DDoS 基础防护，视业务重要性购买弹性高防
  • 域名解析切换到高防 CNAME，源站安全组只放行高防回源 IP
  • 攻击期间通过高防控制台清洗报表确认拦截效果

配置验证

# 观察半连接状态：攻击时不再持续堆积到队列上限
ss -ant state syn-recv | wc -l

# 查看协议栈统计
netstat -s | grep -iE 'SYNCookie|SYNs to LISTEN'
# 触发防护后 passive cookie 计数增长说明 syncookies 已工作

cat /proc/sys/net/ipv4/tcp_syncookies   # 输出 1
  • 正常业务压测连接成功率应保持在 99% 以上
  • 攻击复现时服务器应能维持 SSH 登录与核心服务响应

常见问题

FAQ1：开启 tcp_syncookies 后为什么还是服务不可用？

SYN Cookie 解决的是半连接队列耗尽问题，但攻击流量打满带宽或 CPU 时服务仍会不可用。通过云监控确认入方向流量是否达到带宽上限；超过 1Gbps 的纯流量攻击必须走上游清洗，主机层参数只能延缓崩溃时间，无法根治带宽耗尽。

FAQ2：connlimit/hashlimit 会不会误伤 NAT 后的正常用户？

会。同一出口 IP 的公司或校园网用户共享源地址，可能触发限速。处理方法：对已知大客户出口 IP 建立白名单放行规则，并确保其位于限速规则之前；将 hashlimit-above 调高到业务高峰单 IP 新建连接峰值的 2 倍后再观察。

总结

SYN Flood 防御是分层工程：内核参数让服务器从有状态等待变为无状态应答，iptables 在入口过滤伪造与超频连接，Nginx 参数缩短握手资源占用，上游高防承接大流量攻击。四层配合可将攻击对业务的影响降到最低。