已解密的 ssl 会话标记为应用程序 ssl
Resolution
问题
我们知道, SSL 解密应该给我们的可见性的流量, 否则将被加密。因此, 我们希望将解密的通信标识为底层应用程序, 如 web 浏览、facebook 或其他, 但不作为 SSL。但是, 在某些情况下, 将应用程序 SSL 视作解密是预期的行为。本文介绍了一个这样的场景, 并解释了为什么被识别为应用程序 ssl 的解密 ssl 会话在这种情况下被认为是 OK 的。
在下面的示例中, 我们试图访问以下网站:
https://my.vmware.com/web/vmware/login
在会话表中, 我们可以看到会话被标记为已解密 (*)
admin@Faith-PFW-X1> 显示会话所有筛选 ssl-解密是
--------------------------------------------------------------------------------
ID 应用程序状态类型标志 Src [体育]/区域/原始 (已翻译的 ip [端口])
Vsys Dst [Dport]/区域 (已翻译的 ip [端口])
--------------------------------------------------------------------------------
25472 ssl 活动流*NS 192.168.16.48 [60668]/区域-Trust2016/6 (10.193.90.32 [61785])
vsys1 216.58.212.163 [443]/区域-不信任 (216.58.212.163 [443])
25475 ssl 活动流量*ns 192.168.16.48 [60670]/区域-Trust2016/6 (10.193.90.32 [37349])
vsys1 216.58.212.163 [443]/区域-不信任 (216.58.212.163 [443])
25478 ssl 活动流*NS 192.168.16.48 [60674]/区域-Trust2016/6 (10.193.90.32 [43548])
vsys1 216.58.212.163 [443]/区域-不信任 (216.58.212.163 [443])
25474 ssl 活动流 * NS 192.168.16.48 [60671]/区域-Trust2016/6 (10.193.90.32 [31994])
vsys1 216.58.212.163 [443]/区域-不信任 (216.58.212.163 [443])
25479 google 基主动流 * NS 192.168.16.48 [60675]/区域-Trust2016/6 (10.193.90.32 [15527])
vsys1 216.58.212.163 [443]/区域-不信任 (216.58.212.163 [443])
25538 网络浏览活动流 * NS 192.168.16.48 [60710]/区域-Trust2016/6 (10.193.90.32 [17185])
vsys1 68.232.35.180 [443]/区域-不信任 (68.232.35.180 [443])
25473 ssl 活动流*NS 192.168.16.48 [60669]/区域-Trust2016/6 (10.193.90.32 [35255])
vsys1 216.58.212.163 [443]/区域-不信任 (216.58.212.163 [443])
对该会话的深入研究表明, 我们已将应用程序类型标识为 SSL。
admin@Faith-PFW-X1> 显示会话 id 25473
会话25473
c2s 流量:
来源: 192.168.16.48 [Zone-Trust2016]
dst: 216.58.212.163
原: 6
体育: 60669 dport: 443
状态: INIT 类型: 流
src 用户: 未知的
dst 用户: 未知
s2c 流量:
来源: 216.58.212.163 [区-不信任]
dst: 10.193.90.32
原: 6
体育: 443 dport: 35255
状态: INIT 类型: 流
src 用户: 未知的
dst 用户: 未知
开始时间: 星期二 6月21日 11:37:52 2016
超时:15 秒
总字节计数 (c2s): 796 个
总字节计数 (s2c): 4759
layer7 数据包计数 (c2s): 8
layer7 数据包计数 (s2c): 8
vsys: vsys1
应用: ssl
规则: 信任2016到要记录的 Internet
会话最后:
会话中的真实会话:
HA 对等方更新的错误会话: 错误
地址/端口转换: 源
nat 规则: nat 信任2016到 Internet (vsys1)
layer7 处理: 已启用已完成的
URL 筛选: 错误
会话通过 syn cookie: 错误会话
在主机上终止: 假
会话遍历隧道: 假的
捕获门户会话: 错误的
入口接口: ethernet1/3
出口接口: ethernet1/6
会话 QoS 规则: N/A (类 4)
跟踪阶段防火墙: tcp 鳍
跟踪器阶段 l7proc: 代理定时器过期
结束原因: tcp 鳍
说明
解密会话时, 将在解密的流上触发应用程序 ID 查找, 以帮助标识会话应用程序。防火墙需要读取足够的数据包才能识别应用程序。在 SSL 握手完成后, 我们需要读取最多2000年字节的数据, 以确定应用程序是否未知。当检测到解码器 (如 web 浏览) 时, 可能需要5个以上的数据包来确定实际的应用程序。 在大多数情况下, 在接收到该数据量之前, 应用程序将被识别。
查看下面的数据包捕获输出, 我们看到通信在应用程序数据交换之前结束, 这将使防火墙能够识别应用程序。
如果定期的 tls/ssl 被包装在一些自定义应用程序上, 这也适用: 底层应用程序将是 "未知 tcp", 如果它没有加密, 但由于加密, app ID 已经确定了 ssl, 并将保留该应用程序。
我们希望您能发现这些信息是有用的。请在下面的部分留下大拇指或评论。
请参见