评论2

• 

  wilton_gao

  楼主 2008/7/24 8:47:33

  TCP状态转移的问题
  
  上述的入侵过程，主机X是如何阻止主机A向主机B发送响应在的，主机调通过发送一系列的SYN包，但不让A向调发送SYN-ACK包而中止主机A的登录端口。如前所述，TCP维持一个连接建立定时器。如果在规定时间内（通常为75秒）不能建立连接，则TCP将重置连接。在前面的例子中，服务器端口是无法在75秒内作出响应的。
  
  下面我们来讨论一下主机X和主机A之间相互发送的包序列。X向A发送一个包，其SYN位和FIN位置位，A向X发送ACK包作为响应：
  
  X→A：SYN FIN（系列号=M）
  
  A→X：ACK（应答序号＝M+1）
  
  从图2的状态转移可以看出，A开始处于监听（LISTEN）状态。当它收到来自X的包后，就开始处理这
  
  个包。值得注意的是，在TCP协议中，关于如何处理SYN和FIN同时置位的包并未作出明确的规定。我们假设它首先处理SYN标志位，转移到SYN-RCVD状态。然后再处理FIN标志位，转移到CLOSE-WAIT状态。如果前一个状态是ESTABLISHED，那么转移到CLOSE-WAIT状态就是正常转
  
  移。但是，TCP协议中并未对从SYN-RCVD状态到CLOSE-WAIT状态的转移作出定义。但在几种TCP应用程序中都有这样的转移，例如开放系统SUN OS4.1.3，SUR4和ULTRX4.3。因此，在这些TCP应用程序中存在一条TCP协议中未作定义的从状态SYN-RCVD到状态CLOSE-WAIT的转移弧，如图2所示。
  
  在上述入侵例子中，由于三次握手没能彻底完成，因此并未真正建立TCP连接，相应的网络应用程序并未从核心内获得连接。但是，主机A的TCP机处于CLOSE-WAIT状态，因此它可以向X发送一个FIN包终止连接。这个半开放连接保留在套接字侦听队列中，而且应用进程不发送任何帮助TCP执行状态转移的消息。因此，主机A的TCP机被锁在了CL0SE-WAIT状态。如果维持活动定时器特征被使用，通常2小时后TCP将会重置连接并转移到CLOSED状态。
  
  当TCP机收到来自对等主机的RST时，就从ESTABLISHED，FINWAIT-1和FIN-WAIT-2状态转移到CLOSED状态。这些转移是很重要的，因为它们重置TCP机且中断网络连接。但是，由于到达的数据段只根据源IP地址和当前队列窗口号来证实。因此入侵者可以假装成已建立了合法连接的一个主机，然后向另一台主机发送一个带有适当序列号的RST段，这样就可以终止连接了！

• 

  wilton_gao

  楼主 2008/7/24 8:47:55

  定时器问题
  
  正如前文所述，一旦进入连接建立过程，则启动连接定时器。如果在规定时间内不能建立连接，则TCP机回到CLOSED状态。
  
  我们来分析一下主机A和主机X的例子。主机A向主机X发送一个SYN包，期待着回应一个SYN-ACK包。假设几乎同时，主机X想与主机A建立连接，向A发送一个SYN包。A和X在收到对方的SYN包后都向对方发送一个SYN-ACK包。
  
  当都收到对方的SYN-ACK包后，就可认为连接已建立。在本文中，假设当主机收到对方的SYN包后，就关闭连接建立定时器。
  
  X→A：SYN（序列号=M）
  
  A→X：SYN（序列号=N）
  
  X→A：SYN（序列号=M），ACK（应答号=N+1）
  
  A→X：SYN（序列号=N），ACK（应答号＝M+1）
  
  ●主机X向主机A发送一个FTP请求。在X和A之间建立起一个TCP连接来传送控制信号。主机A向X发送一个SYN包以启动一个TCP连接用来传输数据，其状态转移到SYN-SENT状态。
  
  ●当X收到来自A的SYN包时，它回送一个SYN包作为响应。
  
  ●主机X收到来自A的SYN-ACK包，但不回送任何包。
  
  ●主机A期待着接收来自X的SYN-ACK。由于X不回送任何包，因此A被锁在SYN-RCVD状态。这样，X就成功地封锁了A的一个端口。