TCP/IP序列号生成方法 TCP的Initial Sequence Number(ISN)的预测 正常的TCP连接基于一个三次握手(3-way handshake)，一个客户端(Client)向服务器(Server)发送一个初始化序列号ISNc， 随后，服务器相应这个客户端ACK(ISNc),并且发送自己的初始化序列号ISNs，接着，客户端响应这个ISNs（如下图），三次握手完成。 C ---〉S: (ISNc) S ---〉C: ACK(ISNc)+ ISNs C ---〉S: ACK(ISNs) C ---〉S: data and / or S ---〉C: data 下面，我以Windows2000 Advanced Server为例，来说一下两台主机是如何进行三次握手。 我们可以看到： 1) Smartboy首先发送一个seq:32468329的包给服务器202.116.128.6。 2) 然后, 202.116.128.6响应主机Smartboy, 它送给Smartboy自己的 seq:3333416325 而且响应Smartboy的ack:3240689240。 3) Smartboy再响应服务器202.116.128.6, seq:3240689240, ack:3333416326。 三次握手完毕，两台几建立起连接。 可以看出，在三次握手协议中，Clinet一定要监听服务器发送过来的ISNs, TCP使用的sequence number是一个32位的计数器，从0-4294967295。TCP为每一个连接选择一个初始序号ISN，为了防止因为延迟、重传等扰乱三次握手，ISN不能随便选取，不同系统有不同算法。理解TCP如何分配ISN以及ISN随时间变化的规律，对于成功地进行IP欺骗攻击很重要。 在Unix系统里，基于远程过程调用RPC的命令，比如rlogin、rcp、rsh等等，根据/etc/hosts.equiv以及$HOME/.rhosts文件进行安全校验，其实质是仅仅根据源IP地址进行用户身份确认，以便允许或拒绝用户RPC。这就给与了那些攻击者进行IP地址欺骗的机会。 让我们看X是如何冒充T来欺骗S，从而建立一个非法连接 ： X---->S: SYN(ISNx ) , SRC = T S---->T: SYN(ISNs ) , ACK(ISNT) （*） X---->S: ACK(ISNs+1 ) , SRC = T （**） X---->S: ACK(ISNs +1) , SRC = T, 攻击命令（可能是一些特权命令） 但是，T必须要在第（**）中给出ISNs, 问题是ISNs在第（*）步中发给了T(X当然很难截取到)，幸运的是，TCP协议有一个约定: ISN变量每秒增加250,000次，这个增加值在许多版本比较旧的操作系统中都是一个常量，在FreeBSD4.3中是125000次每秒，这就给X一个可乘之机。 看一下X是如何猜出ISNs : a、首先， X发送一个SYN包来获取服务器现在的ISNs X ---〉S: (ISNx) S ---〉X: ACK(ISNx)+ ISNs# (1) b、紧接着，X冒充T向服务器发送SYN包 X ---〉S: SYN(ISNx ) , SRC = T (2) c、于是，服务器发出一个响应包给T(这个包X是收不到的) S ---〉T: SYN(ISNs$) , ACK(ISNT ) (3) d、X计算ISNs$: ISNs$ = ISNs# + RTT×Increment of ISN (4) 其中，RTT(Round Trip Time),是一个包往返X和S所用的时间,可以通过Ping 来得到。 上图显示了round trip times (RTT) 大概是０。 Increment of ISN是协议栈的初始序列号每秒钟增加的值，以Unix为例，当没有外部连接发生时，服务器的ISN每秒增加128,000,有连接的时候，服务器的ISN每秒增加64,000。 e、于是， X ---> S : ACK(ISNs$) （冒充可信主机成功了） X ---> S : 恶意的命令或窃取机密消息的命令 在评价以下的解决方案时有几点要注意： 1.该解决方案是否很好地满足TCP的稳定性和可操作性的要求？ 2.该解决方案是否容易实现? 3.该解决方案对性能的影响如何? 4.该解决方案是否经得起时间的考验？ 以下的几种方案各有各的优点和缺点，它们都是基于增强ISN生成器的目标提出的。 配置和使用密码安全协议 TCP的初始序列号并没有提供防范连接攻击的相应措施。TCP的头部缺少加密选项用于强加密认证，于是，一种叫做IPSec的密码安全协议的技术提出了。IPSec提供了一种加密技术（End to end cryptographic），使系统能验证一个包是否属于一个特定的流。这种加密技术是在网络层实现的。其它的在传输层实现的解决方案（如SSL/TLS和SSH1/SSH2）, 只能防止一个无关的包插入一个会话中，但对连接重置（拒绝服务）却无能为力，原因是因为连接处理是发生在更低的层。IPSec能够同时应付着两种攻击（包攻击和连接攻击）。它直接集成在网络层的安全模型里面。 上面的解决方案并不需要对TCP协议做任何得修改，RFC2385(“基于TCP MD5签名选项的BGP会话保护)和其他的技术提供了增加TCP头部的密码保护，但是，却带来了收到拒绝服务攻击和互操作性和性能方面的潜在威胁。使用加密安全协议有几个优于其它方案的地方。TCP头部加密防止了Hijacking和包扰乱等攻击行为，而TCP层仍然能够提供返回一个简单增加ISN的机制，使方案提供了最大程度的可靠性。但实现IPSec非常复杂，而且它需要客户机支持，考虑到可用性，许多系统都选择使用RFC 1948。 使用RFC1948 在RFC1948中，Bellovin提出了通过使用4-tuples的HASH单向加密函数，能够使远程攻击者无从下手（但不能阻止同一网段的攻击者通过监听网络上的数据来判断ISN）。 Newsham 在他的论文 [ref_newsham]中提到: RFC 1948 [ref1]提出了一种不容易攻击（通过猜测）的TCP ISN的生成方法。此方法通过连接标识符来区分序列号空间。每一个连接标识符由本地地址，本地端口，远程地址，远程端口来组成，并由一个函数计算标识符分的序列号地址空间偏移值（唯一）。此函数不能被攻击者获得，否则，攻击者可以通过计算获得ISN。于是，ISN就在这个偏移值上增加。ISN的值以这种方式产生能够抵受上面提到的对ISN的猜测攻击。 一旦全局ISN空间由上述方法来生成，所有的对TCP ISN的远程攻击都变得不合实际。但是，需要指出的，即使我们依照RFC 1948来实现ISN的生成器，攻击者仍然可以通过特定的条件来获得ISN(这一点在后面叙述). 另外，用加密的强哈希算法(MD5)来实现ISN的生成器会导致TCP的建立时间延长。所以，有些生成器（如Linux kernel ）选择用减少了轮数的MD4函数来提供足够好的安全性同时又把性能下降变得最低。削弱哈希函数的一个地方是每几分钟就需要对生成器做一次re-key 的处理，经过了一次re-key的处理后，安全性提高了，但是，RFC793提到的可靠性却变成另一个问题。 我们已经知道，严格符合RFC1948的ISN生成方法有一个潜在的危机： 一个攻击者如果以前合法拥有过一个IP地址，他通过对ISN进行大量的采样，可以估计到随后的ISN的变化规律。在以后，尽管这个IP地址已经不属于此攻击者，但他仍然可以通过猜测ISN来进行IP欺骗。 以下，我们可以看到RFC 1948的弱点: ISN = M + F(sip, sport, dip, dport, ) 其中 ISN 32位的初始序列号 M 单调增加的计数器 F 单向散列哈希函数 (例如 MD4 or MD5) sip 源IP地址 sport 源端口 dip 目的IP地址 dport 目的端口 哈希函数可选部分，使远程攻击者更难猜到ISN. ISN自身的值是按照一个常数值稳定增加的,所以F()需要保持相对的稳定性。而根据Bellovin 所提出的，是一个系统特定的值（例如机器的启动时间，密码，初始随机数等），这些值并不 会经常变。 但是，如果Hash函数在实现上存在漏洞（我们无法保证一个绝对安全的Hash函数，况且，它的实现又与操作系统密切相关），攻击者就可以通过大量的采样，来分析，其中，源IP地址，源端口，目的IP地址，目的端口都是不变的，这减少了攻击者分析的难度。 Linux TCP的ISN生成器避免了这一点。它每５分钟计算一次值,把泄漏的风险降到了最低。 有一个办法可以做的更好： 取M = M + R(t) ISN = M + F(sip, sport, dip, dport, ) 其中 R(t) 是一个关于时间的随机函数 很有必要这样做，因为它使攻击者猜测ISN的难度更大了（弱点在理论上还是存在的）。