TCP 序列预测是 2001 年左右的热门话题，但大多数供应商在那个时候都很快修补了他们的操作系统。请参阅2001 年 9 月的这份 CERT 公告，其中包括来自不同供应商的声明。基本上，如果 TCP 序列预测攻击对系统有效，那么该系统十多年来没有更新安全修复程序，这几乎可以肯定意味着它存在更大的安全问题。

为了生成不可预测的序列号，鼓励实现遵循RFC 6528（它取代旧的RFC 1948）中描述的技术。这是一个带有 MD5 的自定义 PRNG。从密码学上讲，这个 PRNG 有点糟糕：除了使用稳健性有问题的散列函数外，它还“错误”地使用了它（这是Merkle-Damgård结构；在简单地将密钥与某些已知输入连接时应该小心；HMAC应该是而是用作建筑元素）；并且整体方案不是很快（一个好的流密码会更好）。然而，速度在这里并不是一个重要的问题（低端系统仍然能够计算数百万的算法每秒的次数；处理传入的 SYN 请求将成为瓶颈，而不是散列）并且我们不需要非常高的加密强度，因为攻击者无论如何都可以以2 ^-32的概率“幸运” ，所以 PRNG 不需要比这更好（密码算法的典型目标是2 ^-80或更少）。

总结： TCP序列预测攻击已成为过去；很高兴知道，但不适用于过去十年左右维护的系统。

就我个人而言，我还没有找到具有此漏洞的现代系统。

许多（如果不是全部）现代操作系统已被修复为使用RFC 1948提出的不可预测的初始序列号。RFC 1948 专门用于防御您定义的序列号攻击。这最初是 2000 年代初期的一个问题，因此，大多数新开发在发布之前都已修补。

Nmap 将为您提供 TCP 序列信息，并对系统对 TCP 序列预测的难度做出有根据的猜测。

迄今为止，我亲自测试过的所有实时系统（不是 Windows 95 或 NT 机器）都被 Nmap 定义为“祝你好运”（“不可能”）。

除了D3C4FF的回答，第二种情况当然是：

如果我与端点之一在同一个子网中，我可以通过预测序列号将数据包注入现有的 TCP 流。

这当然取决于攻击者可以看到现有 TCP 流使用的序列号这一事实——这与预测初始序列号无关。

在他拒绝调低音量后，我个人曾以这种方式使用 TCP RST 注入来关闭室友的网络收音机。

至于这种方法在野外有多普遍，我想说这只是恶意软件作者可以使用的另一种攻击。如果我正在编写一个 rootkit，并且我想对您的内部网络造成严重破坏，那么 TCP 序列预测只是我可能会考虑的一长串工具中的一个。