對有效的重複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更有效、更簡單的解決方法。