对有效的重复ACK使用SACK信息：
在RFC2018中提出了SACK，它对TCP提供了一种能够对乱序接收到的TCP报文进行确认。对于使用了SACK的连接而言，每个合法的DupACK都包含一个新的SACK信息，这些信息包含在触发该DupACK的乱序数据报文。
RFC3517提出了云中歌基于SACK的TCP丢失恢复算法。然而，该手册中并不推荐在TCP中通过包含新的SACK信息来验证DupACK的有效性。从很多TCP的实现中可以看到：大多数TCP的实现也没有对到来的DupACK包强制使用这种有效性检测。
在协商使用SACK的TCP连接中，需要对收到的ACK报文进行有效性验证来完全的去除9.2.1节和9.2.2中的攻击:”重复的ACK中应包含一个新的SACK信息”。SACK信息中应包含已经被发送但还没有收到被TCP确认的数据信息。
那些没有遵从这种有效性检查的ACK报文不应被视作“重复的ACKs”，因而不应触发丢失重传机制。
当一个数据窗内至少有一个包丢失时，将会触发生成一系列的包含又新SACK信息的重复ACKs。这个SACK信息将指出被TCP接收者收到的一系列的报文。
然而，在被窗外的报文触发的非法的纯ACKs中，将不会包含任何SACK信息。
当DSACK被TCP接收者实现时，如果伪造的TCP报文的序列号（SEG.SEQ）比下一个TCP接收端希望接收的序列号（RECV.NXT）小时，非法触发DupACKs可能包含窗外SACK信息。这种报文应被认为指出了被接收到了的重复数据，而不应认为是丢失的数据，因而也不应触发丢失恢复机制。
TCP端口号随机：
如果想进行9.2.1节和9.2.2节中的攻击，黑客需要知道被攻击对象所使用的端口号。混淆用于外部连接的TCP源端口将增大执行这种攻击的难度。3.1节中讨论了使用端口随机化问题。
必须注意到，由于这种攻击不需要攻击者伪造有效的TCP序列号和TCP确认号，端口随机化不应作为第一层的防御。
出入口过滤：
出入口过滤机制减少了全球因特网中通过伪造源ip地址执行攻击的系统数目。尽管在9.2节中讨论的致盲攻击不应仅仅依赖于出入口过滤，但仍建议部署它来阻止那些依赖伪造源ip地址进行的攻击。RFC3704\2827中提供了对出入口过滤的许多建议。
通用TTL安全机制（GTSM）
RFC5082提出了对一个已知的TCP连接的IP包的TTL字段进行检查，来减少能成功对受保护TCP连接进行攻击的系统的数量。它对本文档讨论的攻击和在[Watson,2004]、RFC4953[Touch,2007]中讨论的攻击提供了相同等级的保护。尽管在很多方案中实现这种机制的防御很有用，但应当清醒的认识到在前一节中讨论的方法提供了一种比GTSM更有效、更简单的解决方法。