据“互联网”所知，SYN cookie 没有启用特定的攻击媒介。我能想到的最好的解释如下：

首先是关于 SYN cookie 的一些解释（细节很重要）。SYN cookie是一种缓解SYN 洪水攻击的方法。

SYN 洪水的要点是保持打开连接的状态是昂贵的（因为它在某处使用 RAM）。在 SYN 洪水中，攻击者通过不保持状态来“作弊”：他发送了一个 SYN 但忘记了它；另一方面，服务器会记住 SYN。

SYN cookie 是服务器的骗子：它也只是忘记了它们。相反，它会在它发送给 SYN 的响应（一个 ACK​​+SYN 数据包）中对它应该记住的 TCP 序列号进行编码；当普通客户端对此做出响应时，它会发送自己的具有相同序列号的 ACK（实际上正好递增 1），这允许服务器恢复它不想记住的数据。TCP 序列号是 32 位，因此服务器必须在 32 位内适应“状态”。SYN cookie 被定义为使用 5 位作为时间戳，3 位用于 MSS，以及 24 位“密码函数的输出”。这 24 位实际上是通过服务器 IP 地址、客户端 IP 地址、端口号（服务器端和客户端）和时间戳计算得出的MAC 。

结果是，当服务器接收到一个看起来像对 ACK+SYN（带有 cookie）的响应的 ACK 时，服务器必须将其视为 TCP 握手的第三个元素，从而为现在完全分配资源打开连接。当且仅当 cookie 值正确时才会发生这种情况（当服务器重新计算它时，它与 ACK 中发送的值匹配）。攻击者知道当前时间并且可以猜测/观察 MSS 值的三位编码，因此有 24 个未知位。如果正确计算 cookie 值（在这种情况下使用加密哈希或等效的东西），那么攻击者只有 1600 万分之一（准确地说是 16777216）命中正确的 cookie 值。这严重限制了攻击者的可能性。

对 SYN cookie 处理所涉及的 CPU 成本进行了一些讨论。考虑一个基本的 Core2 x86 CPU 将愉快地使用单个内核每秒计算 800 万个 MD5 哈希值。攻击者很难以这种方式进行 DoS（它需要每秒向该服务器发送超过 800 万个数据包......）。

可以做的事情如下：

• 攻击者发送一个正常的 SYN，然后从服务器接收到 ACK+SYN。ACK+SYN 包含攻击者使用的源地址和端口的有效 cookie；cookie 的有效期为一分钟左右（因为时间戳通常每 64 秒更改一次）。
• 攻击者使用相同的源地址和端口重复发送两个数据包：
  • 一个包含 ACK 和上面获得的 cookie 的数据包，以及一些编码有效 HTTP 请求的应用数据（“推送”）；
  • 执行 RST 的第二个数据包。

在接收到第一个数据包后，服务器必须假定它是 TCP 握手的有效第三个数据包；然后它读取数据并处理 HTTP 请求。当 HTTP 服务器软件考虑请求时（这可能涉及大量资源，特别是如果请求是 POST 和/或请求使用 gzip 进行 HTTP 级压缩），目标内核读取 RST 并将套接字视为关闭—— HTTP 服务器在尝试发送 HTTP 响应时会收到一个写入错误（但只有那时，而不是之前）。

由于连接正在关闭，源地址+端口再次被视为“空闲”，因此来自客户端的下一次 ACK+push 将同样受到尊重。

64000 个 IP 地址是攻击者“躲避雷达”的一种方式。来自单个 IP 地址的重复连接很可能会被任何半体面的防火墙注意到，并在早期被阻止（在到达目标 Web 服务器之前）。由于邪恶的管理员“拥有” 64000 个地址，他可以模拟来自 64000 个地址中的任何一个的连接。攻击者会使用第一个 SYN 来获取 cookie，然后从该地址发送大约 100 个 ACK​​+push,RST 对。为了提高效果，他会一次处理一百个地址，并定期获取新地址。他有 64000 个地址可以玩，所以他需要一些时间才能重新使用一个地址。

在这种情况下，与没有 SYN cookie 的相同设置相比，SYN cookie 具有以下加重效果：它们允许攻击者在大多数情况下无需等待 ACK+SYN。这禁用了针对 DoS 的经典对策之一，即在响应 SYN 时增加一点延迟。

这仍然没有说服力。在这里，SYN cookie 不会使攻击者的能力大大增加。使用 64000 个地址，攻击者可以维持一百万个打开的连接（或者至少从服务器的角度来看似乎是打开的），无论有没有 SYN cookie，并且没有任何 Web 服务器能够抗拒。

SYN cookie 是内存和 CPU 之间的权衡。由于您在使用它们时使用的内存更少，因此您现在使用更多的 CPU 来计算要在序列号中使用的值。我希望任何 DOS 都会专注于这一点，除非在某个地方存在可以利用的实现错误。

提到网络的规模表明他希望您利用 SYNCookies 的一些基本限制。65,536 个 IP 地址（一个 /16 IP 范围）将匹配可用 TCP 端口的数量，但我对 SYNCookies 的详细信息不够熟悉，无法知道那里是否有可利用的东西。

附带说明一下，SYN 泛洪通常是使用欺骗的源地址完成的，因为您不关心并且实际上不想要响应。因此，您无需实际控制 /16 即可在 DDoS 尝试中使用 65,536 个或更多 IP 地址。/16 也很容易被防火墙阻止，并且很容易识别它是否与 DDoS 尝试有关。

您必须克服的第一个挑战是让目标进入 syn-cookie 模式。即使打开了 syn-cookies（并且至少在某些发行版中默认是关闭的），您也必须超过 TCP 队列长度。如果不是 syn-cookies ，这就是您将导致 DoS 的点。这将涉及发送大量的 SYN 流量开始。

查看来自 Wikipedia 的解释，服务器必须通过 IP 地址和端口计算加密函数，并且该函数的返回值必须为 24 位长度。由于 IP 地址是 32 位，端口是 16 位，所以肯定有冲突。（即两个不同的 IP 地址和端口组合返回相同的值。）如果您控制 16 位的 IP 地址空间（前 16 位相同）并且您可以使用 16 位源端口，那么您应该能够生成所有可能的加密函数值进入序列号。如果您可以在一秒钟内完成此操作，则意味着服务器已为该时间戳发送了所有可能的同步 cookie。

即使发生碰撞，我认为这不会导致 DoS。合法连接在其最终 ACK 中仍然具有有效的序列号，即使它与作为 DoS 尝试的一部分的不同连接发生冲突。

我可以看到的唯一可以利用的其他部分是最大段大小。为此只留出了三个位，这意味着服务器只能选择 8 个不同的值。如果您可以强制服务器选择超过 8 个不同的值，则可能会导致删除需要不在现有列表中的 MSS 值的新连接。这将取决于实现，而不是关于 syn-cookies 如何工作的任何基本内容。

最后，我唯一能看到的是由于必须执行所有这些加密操作而导致的额外 CPU。

传统上，SYN DOS 是通过发送 SYN.​​..SYN...SYN...SYN...来执行
的，常见的 TCP 使用模式是发送 SYN，等待 SYN/ACK，然后发送 ACK。所以当服务器收到 SYN 时，它会发送 SYN/ACK 并等待 ACK。但是被攻击者丢弃了 SYN/ACK 并发送了更多的 SYN。服务器尽职尽责地回复 SYN/ACK，但它的缓冲区逐渐被打开的等待连接填满。最后，缓冲区已满，不再接受任何连接。服务器变得不可用。

更好的是，攻击者伪造了它的源地址，因此每个 SYN 似乎来自不同的地址。SYN/ACK 也被发送到该随机地址（服务器丢弃未经授权的 SYN/ACK 数据包）。

通过更广泛的搜索，我发现了这个：https ://www.rfc-editor.org/rfc/rfc4987 - SYN Floods 的描述，这似乎是你被问到的问题。