伪造源地址发起SYN Flood，本质就是利用TCP三次握手第一步不验证源IP的机制，让服务器把大量半连接队列资源消耗在根本不存在的地址上。
TCP三次握手为什么给伪造源地址留了空子
TCP要建立连接,得先走三次握手。
- 客户端发一个SYN包,告诉服务器“我想连你”。
- 服务器回一个SYN+ACK包，说“我收到了，你确认一下”。
- 客户端再回一个ACK,连接才正式建立。
问题出在第二步,服务器收到SYN后，会立刻创建一个半连接，放进半连接队列，这个动作只看SYN包里的源IP地址，而源IP是发送方自己填的，没有任何机制验证这个地址是不是真的，攻击者把源IP写成一个不存在的地址，服务器照样会回SYN+ACK，然后傻等第三步ACK，这个ACK永远不来。
伪造源地址syn flood和真实源地址攻击有什么区别
真实源地址攻击,服务器至少知道攻击来自哪里，封IP、限制单IP速率、拉黑网段，这些手段还能起到一定作用。
伪造源地址攻击,每个SYN包的源IP都在变，封一个IP，下一个包又换一个，基于IP黑名单的防御基本失效，服务器看到大量来自不同地址的SYN，却没有任何一个会完成握手，防御思路也因此从“封谁”变成“怎么验证源地址是否真实可达”。
伪造源地址发起SYN Flood的具体手法
攻击者不会用普通浏览器发SYN,那会被操作系统自动填上真实IP，他们使用能构造原始IP包的工具。
Linux下用hping3最直接：
hping3 -S --flood -p 80 --rand-source 目标IP--rand-source让每个SYN包的源IP随机变化，也可以使用-a指定某个网段，模拟来自特定区域的访问，用scapy则可以更细粒度地控制：
from scapy.all import send(IP(src=RandIP(), dst="目标IP")/TCP(dport=443, flags="S"), loop=1, verbose=0)
这些命令只需要root权限,在普通云主机上就能发起，门槛低，是SYN Flood长期泛滥的重要原因。
linux syn flood攻击命令为什么能伪造源地址
关键在raw socket，普通socket创建时，内核会自动填上本机真实源IP，但raw socket允许应用自己填写IP头，Linux下打开IP_HDRINCL选项后，源IP字段可以任意写，攻击工具在用户态拼好IP头和TCP头，直接交给网卡发送，不经过内核协议栈，所以目标收到的包源地址可以是任何值。
攻击者本机通常会临时关闭对RST的响应,避免内核收到返回包后自动回RST，以免暴露真实位置。
从半连接队列看SYN Flood卡点
服务器收到SYN后,会分配半连接结构，放入队列，这个队列大小有限，Linux默认值可以这样查看：
sysctl net.ipv4.tcp_max_syn_backlog攻击流量不需要多大带宽,只要新SYN速率超过队列释放速度，半连接队列就会满，队列满后，正常用户的新SYN会被丢弃，服务表现为无法建立新连接。
syn flood攻击原理是什么会让服务器崩在哪个环节
崩在第二个环节之后,第一步客户端发SYN正常，第二步服务器回SYN+ACK并进入SYN_RECV，第三步永远等不来ACK，攻击者只发第一步，服务器却要为每个第一步分配内存。
| 环节 | 正常三次握手 | SYN Flood攻击 |
|---|---|---|
| 客户端发SYN | 真实地址 | 随机伪造地址 |
| 服务器回SYN+ACK | 客户端能收到 | 发往不存在地址 |
| 客户端回ACK | 完成连接 | 永远不回 |
| 资源占用 | 短时间释放 | 挂到超时 |
现场判断命令：
ss -s | head -5 netstat -natp | grep SYN_RECV | wc -l
攻击时第二个命令的数值会快速上涨,多数情况下，SYN_RECV数量异常升高，就说明可能正在遭受SYN Flood。
syn flood怎么防御：从队列到验证源地址
单纯调大半连接队列不能解决伪造源地址攻击,攻击者加一点速率，再大的队列也会满，防御要分三层。
第一层：内核参数加固
sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_synack_retries=1
sysctl -w net.ipv4.tcp_max_syn_backlog=4096SYN Cookie是核心，收到SYN时不分配半连接资源，把源IP、端口、时间戳做哈希编码进SYN+ACK的序列号，只有收到对方ACK且序列号校验通过，才真正创建连接，伪造源地址的ACK不会回来，因此内存不被消耗，行业共识认为，SYN Cookie是小流量SYN Flood下性价比最高的防御手段。
第二层：本机防火墙限速
用iptables限制SYN速率：
iptables -A INPUT -p tcp --syn -m limit --limit 100/s --limit-burst 200 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP这只能限制包速率,对随机伪造地址有一定缓解，但也会误伤正常用户，需要根据业务实际SYN速率调参。
北京机房防御syn flood怎么选
如果业务部署在北京机房,底层带宽通常不是最大问题，优先看机房是否提供流量清洗和源地址认证，很多企业先问北京高防IP价格，再决定要不要上，其实比价格更该看三件事：
- 清洗设备是否支持SYN Cookie代理
- 是否支持TCP源探测,先回一个带特定序列号的包要求客户端确认
- 能否把攻击流量牵引到清洗中心,而不是在服务器上硬扛
北京机房的高防服务多数支持这些能力,但价格差异大，低价线路可能在攻击时绕路，延迟变高，选择时把“能否验证源地址”放在价格前面。
如何验证伪造源地址SYN Flood
运维侧要能判断是不是伪造源地址攻击,抓包看：
tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0' -nn | head -50如果源IP非常分散,大量是不可路由的私网地址或保留地址，且没有后续ACK，基本可以判定为伪造源地址，再看：
netstat -natp | grep SYN_RECVSYN_RECV状态连接数高,源地址五花八门，而正常业务源IP相对集中，这是最直观的现场证据，业内专家指出，伪造源地址的SYN Flood无法通过简单封IP解决，必须以源验证和资源隔离为主。
伪造源地址把SYN Flood从“量”的对抗变成“源”的对抗，服务器不能再默认每个SYN都值得分配资源，SYN Cookie和源地址探测就是重建信任的过程，看不到真实的源，就先不要给真实的队列。
Q&A：伪造源地址SYN Flood的核心问题
伪造源地址syn flood攻击能彻底溯源吗
不能,IP源地址没有全网验证机制，攻击包经过的边界路由器通常不记录每个伪造包，多数情况下只能追溯到离攻击者最近的入口，无法直接定位真实主机，若攻击者使用反射节点，溯源链会断在中转网络。
syn flood攻击原理是什么和CC攻击有什么不同
SYN Flood打的是TCP握手阶段的半连接队列和内存，CC攻击打的是完整连接后的业务资源，比如HTTP连接数和数据库查询，SYN Flood包速率可能不高，但能让服务无法建立新连接；CC攻击需要完成握手，源地址多数真实，但请求内容复杂，消耗CPU更高。
linux下用hping3伪造源地址发syn flood会留下什么痕迹
目标服务器会看到海量SYN_RECV和随机源IP,攻击主机上，命令历史、进程列表、流量监控会记录hping3进程和异常发包量，运营商如果做出口检测，也会看到源地址不符合本机IP的包，这些痕迹足以定位到发起主机。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/637455.html
