今天是否合法遇到了带有 RST 但没有 ACK 的 TCP 段?
虽然一些内核会在 SYN 段从它们自己“非法”发送时发出这样的 RST(例如,nmap half-syn、scapy 等),但我认为这种情况是非法的。当然,如果端口被关闭,被扫描的服务器响应一个ACK -RST,如果它有响应。
鉴于仅 FIN 的段从不合法,如今在网络中是否合法地遇到了仅 RST 的段?
鉴于上述链接中的参考资料,我认为答案是否定的,但只是根据上面提到的 RST“警告”进行检查。是否有任何合法的警告?
今天是否合法遇到了带有 RST 但没有 ACK 的 TCP 段?
虽然一些内核会在 SYN 段从它们自己“非法”发送时发出这样的 RST(例如,nmap half-syn、scapy 等),但我认为这种情况是非法的。当然,如果端口被关闭,被扫描的服务器响应一个ACK -RST,如果它有响应。
鉴于仅 FIN 的段从不合法,如今在网络中是否合法地遇到了仅 RST 的段?
鉴于上述链接中的参考资料,我认为答案是否定的,但只是根据上面提到的 RST“警告”进行检查。是否有任何合法的警告?
今天是否合法遇到了带有 RST 但没有 ACK 的 TCP 数据包?
是的,只有当处于 SYN-SENT 状态时,才需要有效 RST 的 ACK。请参阅RFC 793,传输控制协议。特别是,查看重置处理部分:
重置世代
作为一般规则,每当一个显然不适合当前连接的段到达时,就必须发送重置 (RST)。如果不清楚是否属于这种情况,则不得发送复位。
状态分为三组:
如果连接不存在(CLOSED),那么除了另一个重置之外的任何传入段都会发送重置。特别是,通过这种方式拒绝寻址到不存在的连接的 SYN。
如果传入段有 ACK 字段,则重置从段的 ACK 字段中获取其序列号,否则重置的序列号为零,并且 ACK 字段设置为传入段的序列号和段长度之和. 连接保持在 CLOSED 状态。
如果连接处于任何非同步状态(LISTEN、SYN-SENT、SYN-RECEIVED),并且传入段确认尚未发送的内容(该段携带不可接受的 ACK),或者传入段具有安全级别或如果隔间与连接请求的级别和隔间不完全匹配,则会发送重置。
如果我们的 SYN 未被确认并且传入段的优先级高于请求的优先级,则提高本地优先级(如果用户和系统允许)或发送重置;或者,如果传入段的优先级低于请求的优先级,则继续,就好像优先级完全匹配一样(如果远程 TCP 无法提高优先级以匹配我们的优先级,这将在它发送的下一个段中检测到,并且连接将被终止)。如果我们的 SYN 已被确认(可能在这个传入段中),传入段的优先级必须与本地优先级完全匹配,如果没有,则必须发送重置。
如果传入段有 ACK 字段,则重置从段的 ACK 字段中获取其序列号,否则重置的序列号为零,并且 ACK 字段设置为传入段的序列号和段长度之和. 连接保持相同的状态。
如果连接处于同步状态(ESTABLISHED、FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAIT、CLOSING、LAST-ACK、TIME-WAIT),任何不可接受的段(窗外序列号或不可接受的确认) number) 必须只引出一个包含当前发送序列号的空确认段和一个指示预期接收的下一个序列号的确认,并且连接保持相同的状态。
如果传入段的安全级别、隔离区或优先级与连接请求的级别、隔离区和优先级不完全匹配,则发送重置并且连接进入 CLOSED 状态。重置从传入段的 ACK 字段中获取其序列号。
重置处理
在除 SYN-SENT 之外的所有状态中,所有重置 (RST) 段都通过检查它们的 SEQ 字段来验证。如果其序列号在窗口中,则重置有效。在 SYN-SENT 状态(接收到响应初始 SYN 的 RST),如果 ACK 字段确认 SYN,则 RST 是可接受的。
RST 的接收者首先验证它,然后改变状态。如果接收器处于 LISTEN 状态,则忽略它。如果接收器处于 SYN-RECEIVED 状态并且之前一直处于 LISTEN 状态,则接收器返回 LISTEN 状态,否则接收器中止连接并进入 CLOSED 状态。如果接收器处于任何其他状态,它会中止连接并通知用户并进入 CLOSED 状态。
鉴于仅 FIN 的数据包从不合法......
实际上,RFC 中没有任何内容禁止 FIN-only段(不是数据包)。例如,TCP 连接的一端可能已经为所有接收到的段发送了 ACK,但随后它决定发送完成,因此它会发送一个 FIN 段,但由于没有任何 ACK,它不应该发送ACK(这样做可能会导致一个问题,从而获得 RST 作为响应)。
大多数现代安全设备可能会丢弃包含仅 FIN 段的数据包,但这并不意味着它实际上是无效的段,也不意味着每个此类设备都会丢弃这样的数据包。