启用 net.ipv4.tcp_syncookies=1 是缓解超大规模 syn-flood 最有效的内核级手段,需同步调高 somaxconn 至 65535、将 tcp_synack_retries 设为 2,并配合 iptables 首条限速规则防御。

直接启用 net.ipv4.tcp_syncookies = 1 是缓解超大规模 SYN-Flood 的最有效内核级手段,它不分配内存、不维护状态,只在半连接队列真正溢出时启动无状态验证机制。但单设这一项远远不够——它必须在“队列先撑得住、重试快释放、应用能接住”的前提下才能持续生效。
必须设为 1,且确认已激活
该参数取值为 0(关闭)、1(自动启用)、2(强制启用)。超大规模场景下推荐固定设为 1:
- 临时启用:
sysctl -w net.ipv4.tcp_syncookies=1 - 永久生效:在
/etc/sysctl.conf中添加net.ipv4.tcp_syncookies = 1,再执行sysctl -p - 验证是否写入:
sysctl net.ipv4.tcp_syncookies应返回= 1 - 验证是否触发:攻击期间运行
netstat -s | grep -i "syncookies",观察 Syncookies sent 计数是否增长
同步调高 somaxconn 至 65535,否则 syncookies 压根不会启动
tcp_syncookies 是兜底机制,只在 net.core.somaxconn 或 tcp_max_syn_backlog 队列溢出时才介入。若两者仍为默认 128 或 1024,攻击流量几秒就打满队列并被静默丢弃,根本触不到 cookie 逻辑。
Linux系统管理专家,覆盖12大模块:用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词:useradd、sudo、sshd_config、chmod、SEL...
- 设为
net.core.somaxconn = 65535(同时约束全连接队列,也提升 accept 效率) - 该值必须 ≥ 应用层
listen()调用的 backlog 参数,否则会被截断 - Nginx 需配
listen 80 backlog=65535;Tomcat 在server.xml中设acceptCount="65535";Node.js 启动时传入backlog=65535 - 改完需重载服务(如
systemctl reload nginx),否则监听套接字仍用旧值
把 tcp_synack_retries 降到 2,让无效连接秒级释放
默认值 5 意味着服务器最多等待约 63 秒才放弃一个伪造连接(重试间隔:1s, 3s, 7s, 15s, 31s)。攻击者正是靠这个“长等待”卡死队列。设为 2 后,总等待压缩至约 1–3 秒,显著降低 ss -s 中 synrecv 的峰值。
- 配置
net.ipv4.tcp_synack_retries = 2 - 切勿设为 0:首次 SYN+ACK 发送失败即丢弃,会误伤云厂商 LB、NAT 网关后的真实用户
- 该参数仅影响服务端行为,
tcp_syn_retries是客户端参数,服务器上修改无效
配套 iptables 限速,减轻内核协议栈压力
syncookies 是内核层兜底,iptables 是网络层第一道过滤网。规则必须放在 INPUT 链最前,否则大量伪造包会穿透到 TCP 栈,白白消耗 CPU。
- 插入首条规则:
iptables -I INPUT -p tcp --syn -m limit --limit 50/s --limit-burst 10 -j ACCEPT - 后续丢弃所有未匹配的 SYN:
iptables -A INPUT -p tcp --syn -j DROP -
--limit-burst 10是信用池,允许突发;50/s需按业务正常峰值微调(API 服务可压至 20/s) - 避免使用
recent模块封 IP:高并发下性能差,且 NAT 后易误伤










