Cisco ASA 上出现大量“pkts 重放失败”

网络工程 思科 虚拟专用网 网络安全
2021-07-26 00:35:46

我们正在调查通过 IPSec 隧道连接的两个站点之间的一些通信问题,该隧道一侧运行 Cisco ASA,另一侧运行 Microtik。

在 Cisco ASA 上,我们看到数量惊人的“pkts 重放失败”错误。您将看到下面的统计数据显示了这些失败的 257141 个。

我曾尝试使用 Google 和 Cisco 搜索为这个计数器找到解释,但没有找到任何有用的东西。任何人都可以对这个错误有所了解吗?

#pkts encaps: 18726388, #pkts encrypt: 18726388, #pkts digest: 18726388
#pkts decaps: 35568901, #pkts decrypt: 35568864, #pkts verify: 35568864
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 18726388, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#pkts no sa (send): 0, #pkts invalid sa (rcv): 0
#pkts encaps failed (send): 0, #pkts decaps failed (rcv): 0
#pkts invalid prot (rcv): 0, #pkts verify failed: 0
#pkts invalid identity (rcv): 0, #pkts invalid len (rcv): 0
#pkts invalid pad (rcv): 0,
#pkts invalid ip version (rcv): 0,
#pkts replay rollover (send): 0, #pkts replay rollover (rcv): 0
#pkts replay failed (rcv): 257141
#pkts min mtu frag failed (send): 0, #pkts bad frag offset (rcv): 0
#pkts internal err (send): 0, #pkts internal err (rcv): 04

使用软件版本 9.1(2) 运行 Cisco ASA 5545

2个回答

当您的 VPN 隧道非常繁忙(每秒超过 200 个数据包)时,这种情况偶尔会发生。要了解原因,您必须首先了解Anti-Replay正在做什么。

防重放

Anti-Replay 的目标是防止恶意用户重放捕获的 VPN 数据包。即使数据包受加密和消息完整性保护,稍后有人“重新发送”受保护的数据包也是不可取的。

例如,如果我在我当地分行的银行账户中存入 100 美元现金,在某个时间点,我的银行分行会向我的分行总部发送数据包,实际上是“将我的余额增加 100 美元”。如果我是恶意的,即使我无法读取数据包(由于加密),即使我无法将数量更改为 1,000 或 10,000(由于消息完整性),如果我只是简单地复制数据包) 并通过电汇重新发送它们,理论上我可以不断地将我的银行余额增加 100 美元。

这就是 Anti-Replay 试图保护您免受的攻击。

它通过在每个数据包中嵌入所谓的序列号来实现这一点。然后每一端简单地跟踪以查看收到的最后一个序列号,如果接收到的下一个数据包不是下一个预期的序列号,则丢弃该数据包。

这是Anti-Replay 的基本(并且有些简化)的前提。但是让我们来看看 IPsec 具体是如何做到的。

IPsec 内的防重放

安全通信中的每一方都维护一个反重放窗口,而不是只查看收到的最后一个数字默认情况下,在 Cico ASA 上,Anti-Replay 窗口是 64 个数据包

参与 IPsec 隧道的各方然后只跟踪收到的最后 64 个数据包。让我们来说明如何在 ASA 中使用反重播窗口(尽管该示例适用于任何 IPsec 扬声器)。

如果数据包的序列号为 #200,则 ASA 会将 #200 标记为“收到的最后一个数据包”,并跟踪之前的 64 个数据包——即数据包 #137-#200。

  • 如果收到的下一个数据包是 #150,则 ASA 接受数据包并注明收到了 #150。
  • 如果接收到的下一个数据包是 #130,则 ASA 会丢弃此数据包,因为它超出了反重放窗口。
  • 如果收到的下一个数据包再次是#150,ASA 会丢弃该数据包,因为它在接收到最后一个数据包 (#200) 之前跟踪了 64 个数据包,并且知道已经收到了序列号为 #150 的数据包。

现在假设收到的下一个数据包是#210。这会导致 64 个数据包窗口向前滑动,这意味着 ASA 现在将只接受和跟踪数据包 #147-#210。

  • 如果再次收到数据包 #150,它会被丢弃,因为它仍在跟踪并在窗口内。
  • 如果收到数据包#131,它现在被丢弃,因为它现在在反重放窗口之外。
  • 如果接收到数据包#151,则该数据包被接受,因为它既在反重放窗口内,又没有被接收到。

现在,假设数据包 #220 到达。这使窗口前进,现在正在跟踪序列号为 #157-#220 的数据包。

  • 如果再次收到数据包 #150,ASA 将停止跟踪是否已收到 #150,但它仍然会被丢弃,因为它现在落在反重播窗口之外。
  • 如果数据包#160 到达,它会被接受,因为它都在最新的反重放窗口内,并且之前没有被接收到。

这个过程一直持续到序列号达到最大值并重置为零。值得注意的是,Sequence Number 并不是一个无限的字段,它确实有一个先天的最大值。在 IPsec 的情况下,该字段是 32 位,因此序列号最大约为 42 亿。

当达到最大值时,必须轮换保护数据包的密钥以避免循环序列号漏洞

您的问题的解决方案

在您的情况下发生的具体情况是窗口正在快速前进,并且应该接受的合法数据包正在被丢弃,因为它们到达另一端,就像反重放窗口移出范围一样。

解决办法:增加Anti-Replay窗口。但棘手的部分是你将它增加到什么程度?

一个好的经验法则是,您的反重放窗口是平均每秒数据包数的 0.5 倍到 1 倍我建议开始保守(0.5 倍)并缓慢增加,直到您的性能错误落在可接受的水平内。

不要过于激进地增加反重放窗口,因为这会让您无意中接受重放的数据包。慢慢增加它,直到你对结果感到满意。

在 ASA 上,命令是:

crypto ipsec security-association replay window-size <new size>

您应该在 VPN 隧道的两端执行此操作。

重放检查的目的是防止数据包的恶意重复。此计数器显示 IPSEC 已丢弃的重复次数。有关更多信息,请查看 Cisco 的这份文档。

http://www.cisco.com/c/en/us/support/docs/ip/internet-key-exchange-ike/116858-problem-replay-00.html

您将不得不在双方进行网络跟踪,以查看哪些数据包被丢弃。如果数据包是合法的,并且作为误报被丢弃 - 您需要增加 IPsec Anti-Replay Window