如果服务器从未收到 RST 数据包会发生什么情况？

Question

最近有人决定向我展示他发明的一种使用 SYN/TCP 的新拒绝服务方法的 POC。我认为这完全是胡说八道，但在向他解释了 SYN-SYN/ACK-RST 之后，我哑口无言。他告诉我“如果你用来诱骗发送 SYN/ACK 数据包的服务器无法接收 RST 数据包怎么办？”

我不知道。他声称服务器将继续尝试发送 SYN/ACK 数据包，并且数据包速率将继续增加。

这是真的吗？有人能解释一下吗？

显然，它的工作方式是这样的：

他将 SYN 数据包的 IP 伪装成目标的 IP。然后，他将 SYN 数据包发送到一些随机服务器。
当然，这些服务器都会向目标 IP 回复 SYN/ACK 数据包。
我们知道，目标会回复 RST
但他以某种方式阻止目标发送 RST 或阻止随机服务器处理它。
这样，服务器显然会继续尝试发送 SYN/ACK 数据包，从而产生某种“滚雪球”效应。

Answer 1

如您所知，“尝试打开端口”数据包流应该像这样工作：

1. 同步->
2. <- SYN/ACK
3. 确认->

“封闭端口”版本很简单：

1. 同步->
2. <- 返回

如果远端没有返回 RST 数据包，这是一种极为常见的防火墙配置：

1. 同步->
2. [时间流逝]
3. 同步->
4. [时间流逝]
5. 同步->
6. [时间流逝]

我说的极其常见是指极为常见。由于这种情况很常见，所以所有 TCP 堆栈都必须处理这种情况。

您的某人提出的变体：

1. [欺骗源] SYN ->
2. <- SYN/ACK
3. [时间流逝]
4. <- SYN/ACK
5. [时间流逝]
6. <- SYN/ACK

他聪明地发现的“攻击”是SYN 洪水攻击攻击，自 20 世纪 90 年代初以来就已为人所知。由于防火墙阻止了 RST 数据包，这些服务器不知道关闭连接，因此它们确实会根据正常的 TCP 重试时间重新传输 SYN/ACK 数据包。但是，所有现代 TCP 堆栈都内置了一些可配置的 SYN 洪水保护措施。

这仍然是一种相当有效的攻击方法，尽管它造成的主要危害是通过跟踪过多的数据包来压垮周边安全设备。没有 SYN 的 SYN/ACK 应该很容易被丢弃，但如果它们的数量足够多，就会压垮防火墙。

Answer 2

同步 Cookie有效地阻止这种攻击。服务器用 SYN/ACK 响应，然后忘记它。如果收到 ACK，它会根据 TCP 序列号重新初始化流。在 Linux 上，通过添加以下内容启用它：

net.ipv4.tcp_syncookies = 1

到 /etc/sysctl.conf

但是当受到 10k+ 台机器的攻击时，我估计服务器仍然会被摧毁。