TCP为何要选择一个随机的初始序列号(ISN)，而不是从0开始?

据我理解，序列号只是要给字节流排个序用， 能表明前后关系就可以了，默认使用0为开始多方便。而且握手阶段还要莫名其妙地消耗1个字节。

先按照题主的意见来，TCP使用ISN = 0，看看会有什么问题？

老王想测试一下自己的TCP攻击脚本是否好使，于是盯上了知乎的服务器，假设为 1.1.1.1：443。

老王使用虚假的IP作为源IP，随机端口，目的IP、端口号 = 1.1.1.1：443，伪造的TCP报文 ISN = 0，发出第一个伪造packet。

知乎服务器的TCP应该怎么回复？

SYN，ISN=0, ACK=1。

如此简单，老王在发出第一个packet之后，等待不到1毫秒，还没有收到知乎服务器的确认回复，就将自己的第二个伪造packet发出。

后果是什么？

知乎服务器TCP连接建立成功，耗费了一块内存。

老王呢？除了两个连续的伪造报文发出，啥事没有！

老王琢磨着，既然2个伪造的报文就可以让服务器耗费一块内存。只要让脚本死循环，通过修改源IP、源端口号，每次发出两个连续的报文（报文之间有一丢丢延迟，用于服务器处理第一个packet），是不是就可以让服务器耗尽内存？

当然可以啦！

还是回到现实中吧！好在TCP协议标准不是使用ISN=0，而是使用一个随着时间增长的动态值（RFC793规定，每4us序列号增加1）。

老王认为：虽然RFC793规定序列号是动态改变的，但是可预测的（毕竟4 us序列号增加1），依然可以尝试攻击，尽管比第一种麻烦一点点。

老王使用正常的TCP连接，与知乎服务器建立连接，并记录建立连接的时间、序列号。

与上文类似老王只要连续发出两个TCP报文：

• 第一个SYN报文
• 第二个ACK报文

而第二个ACK报文要想通过知乎服务器合法性检查，必须满足：ACK = 知乎服务器的ISN + 1。

老王的脚本，需要根据正常TCP连接发现的序列号，再加上执行脚本与上一次TCP连接的时间差，换算成序列号的差（4us =1）。

由于时间精度差，得到的序列号可能不准确，第二个报文可以多伪造几个，应该就可以猜出知乎服务器的真实ISN。只要猜中就可以创建一个合法的TCP连接，一样可以耗尽服务器的内存。

为了应对这种攻击方法，RFC1948诞生了。一句话就可以概括：TCP要使用真正意义上的随机ISN，而不是随着时间而增长的动态ISN。

而产生这个真正意义上的随机ISN，可以使用MD5/SHA哈希函数工具，只要输入参数够复杂，比如：

ISN = MD5（系统开机时间，硬件序列号，当前时间，TCP四元组）

将计算MD5哈希值，截短成4个字节，就变成了ISN。

老王无法获知系统的开机时间、服务器的硬件序列号等关键信息，所以无法计算出当前服务器使用的ISN。

另外MD5/SHA哈希工具有一个特点，差之毫厘，谬以千里。只要以上的输入参数猜错了一点点，那么计算出的ISN就大相径庭了。

TCP的ISN采用随机化，是最大限度提高伪造成本。但是如果攻击者可以偷窥到TCP连接信息，伪造TCP成本 =0 ，可以轻松伪造报文插入、删除、篡改数据。

如果TCP上使用TLS来加密运输数据，那么即使攻击者可以偷窥到TCP连接信息，也无法伪造报文插入、删除、篡改数据，因为任何的操作都无法瞒过接收方的安全校验。

但是攻击者可以偷窥到TCP连接信息，可以伪造TCP报文，比如TCP Reset报文成本依然=0，可以将双方的TCP连接断开。

逻辑推理一下，老王尽管没有偷窥到TCP信息，只要老王猜到了双方任何一方的序列号，就可以发一个伪造报文将合法连接Reset掉。

随机ISN大大提高了TCP的安全性！另外作为一个思考题，运营商使用的BGP路由协议也是使用TCP传输的，照上文的说法，只要猜中了双方当前使用的序列号，就可以使用伪造报文远程Reset掉BGP连接，造成运营商BGP路由撤销，运营商立马断网，太可怕了。读者朋友们，你知道运营商是如何防范伪造攻击BGP的？欢迎在评论区讨论！

作者|车小胖谈网络|公众号