我看到来自众多内部端点的流量，这些端点向 Internet 上的主机发送了 RST 或 FIN/ACK。这些连接与透明代理有关，该代理未正确处理这些连接。它没有处理它们，而是将它们转发给 ASA。ASA 之前从未观察到这些连接。
ASA (8.2) 看到此流量并生成 106015 事件（无连接）并拒绝该流量。这正是我所期望的。但是，ASA 还将记录 106100 事件，表明允许该流量。有一个 ACE 表明“允许 ip any any 日志”。
根据流量捕获，确认流量被拒绝且不被允许。
那么，为什么会发生 106100 事件呢？这让我们完全不知所措，因为看起来 ASA 允许了流量，但实际上并没有。如果 ASA 由于缺乏现有连接而丢弃流量，那么为什么它会接近 ACL，更不用说生成允许日志了？
以下是问题中的日志：
: %ASA-6-106015: Deny TCP (no connection) from 10.x.x.x/62938 to 216.x.x.x/80 flags FIN ACK on interface inside
: %ASA-6-106100: access-list inside permitted tcp inside/10.x.x.x(62938) -> outside/216.x.x.x(80) hit-cnt 1 first hit [0x62c4905, 0x0]
两个事件的时间戳相同。
如果您有任何建议我将不胜感激，谢谢。
编辑：
根据思科有关数据包流的文章进行澄清。
http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113396-asa-packet-flow-00.html
“如果数据包流与现有连接不匹配，则验证 TCP 状态。如果是 SYN 数据包或 UDP 数据包，则连接计数器加一，并发送数据包进行 ACL 检查。如果不是 SYN 数据包，则丢弃该数据包并记录事件。”
根据所描述的行为，我仍然不确定为什么会看到 106100 日志表明允许流量。
答案1
在连接跟踪和 NAT 评估之前会评估 ACL（检查packet-tracer模拟此流量的输出），并且由于流量符合该规则，因此它会按照您在 中的指示进行记录permit ip any any log。
答案2
这是预期的行为：
当访问列表行具有日志参数时，预计此消息 ID 可能会因为非同步数据包到达 ASA 并由访问列表评估而触发。例如，如果在 ASA 上收到 ACK 数据包（连接表中不存在该数据包的 TCP 连接），ASA 可能会生成消息 106100，表示允许该数据包；但是，由于没有匹配的连接，该数据包后来被正确丢弃。