scapy 工具

SYN flood 攻击

SYN Flood 是一种广为人知的 DoS（拒绝服务攻击） 想象一个场景：客户端大量伪造 IP 发送 SYN 包，服务端回复的 ACK+SYN 去到了一个「未知」的 IP 地址，势必会造成服务端大量的连接处于 SYN_RCVD 状态，而服务器的半连接队列大小也是有限的，如果半连接队列满，也会出现无法处理正常请求的情况。

可以看到短时间内，服务端收到了很多虚假 IP 的 SYN 包，马上回复了 SYN+ACK 给这些虚假 IP 的服务器。这些虚假的 IP 当然一脸懵逼，我都没发 SYN，你给我发 SYN+ACK 干嘛，于是马上回了 RST。

SYN+ACK 去到的不知道是哪里的主机，是否回复 RST 完全取决于它自己，万一它不直接忽略掉 SYN，不回复 RST，问题就更严重了。服务端以为自己的 SYN+ACK 丢失了，会进行重传。

如何应对 SYN Flood 攻击

• 增加 SYN 连接数：tcp_max_syn_backlog. 调大net.ipv4.tcp_max_syn_backlog的值, 不过这只是一个心理安慰，真有攻击的时候，这个再大也不够用。
• 减少SYN+ACK重试次数：tcp_synack_retries. 重试次数由 /proc/sys/net/ipv4/tcp_synack_retries控制，默认情况下是 5 次，当收到SYN+ACK故意不回 ACK 或者回复的很慢的时候，调小这个值很有必要。

SYN Cookie 机制

SYN Cookie 技术最早是在 1996 年提出的，最早就是用来解决 SYN Flood 攻击的，现在服务器上的 tcp_syncookies 都是默认等于 1，表示连接队列满时启用，等于 0 表示禁用，等于 2 表示始终启用。由/proc/sys/net/ipv4/tcp_syncookies控制。

SYN Cookie 机制其实原理比较简单，就是在三次握手的最后阶段才分配连接资源，如下图所示。

SYN Cookie 的原理是基于「无状态」的机制，服务端收到 SYN 包以后不马上分配为 Inbound SYN分配内存资源，而是根据这个 SYN 包计算出一个 Cookie 值，作为握手第二步的序列号回复 SYN+ACK，等对方回应 ACK 包时校验回复的 ACK 值是否合法，如果合法才三次握手成功，分配连接资源。

SYN Cookie 看起来比较完美，但是也有不少的问题:

• 第一，这里的 MSS 值只能是少数的几种，由数组 msstab 值决定
• 第二，因为 syn-cookie 是一个无状态的机制，服务端不保存状态，不能使用其它所有 TCP 选项，比如 WScale，SACK 这些。因此要想变相支持这些选项就得想想其它的偏门，如果启用了 Timestamp 选项，可以把这些值放在 Timestamp 选项值里面。