在安全规则中配置并在通信日志中看到的操作不一致

症状

在某些情况下, 可以有一个会话的通信日志项, 其中应用程序被识别为不足的数据, 在匹配 drop 规则时记录为 "允许"。

例如：

从一个区域 "replay_eth2" 到一个区域 "replay_eth3" 进行 FTP 通信。

此 FTP 流量将不完整;在命令会话开始时, 客户端将发送一个 RST 数据包 (dport 21)。

此不完整的 FTP 事务将使会话被识别为不足的数据.

连接到 ftp 应用程序的解码器没有收到足够的数据来实现法规检查和验证 ftp 应用程序。

注意: FTP 不是强制性的, 它可能会发生在所有应用解码器.

在帕洛阿尔托网络防火墙上的安全规则显示在下面的示例中:

在安全规则中, 重要的是要有以下几点:

• 拒绝 "任何" 应用程序的通信的一个规则
• 上面的一个规则允许特定应用程序的通信
  • 用于 FTP 通信的流元组 (sip、szone、dip、dzone) 将必须与此规则匹配。它将允许应用程序 ID 启动。
  • 如果没有这样的规则, 在应用程序 ID 启动之前将丢弃通信量

在这些情况下, 如果从区域 "replay_eth2" 向区域 "replay_eth3" 生成 FTP 通信, 则将使用以下日志项阻止此操作:

原因

此行为可以解释如下:

• 在这个非常具体的情况下, 帕洛阿尔托网络防火墙没有所有的信息需要采取最后的行动配置在 "拒绝所有" 规则 (拒绝)
• 一旦应用程序解码器验证了应用程序 (对事务运行一些法规测试), 就会采取最后的操作
• 最终规则匹配和操作将在验证后延迟

当收到 RST 数据包时, 会话以这些状态结束:

• 不足-数据
  FTP 会话不完整且未经过验证
• 与 "允许" 操作操作相匹配的 "拒绝所有" 规则
  临时设置为 "允许" 实现应用程序 ID (在4数据包或2000字节的有效负载内), 而 "拒绝所有" 规则是最佳的潜在匹配.

所有者： nbilly