如何处理 "未知" 应用程序?
什么是未知的 tcp 或未知的 udp, 有时出现在交通日志?在应用程序 id 方面, 这些连接没有足够的数据, 或者与已知应用程序的行为不匹配的数据被传输, 并且应用程序 id 无法识别已知的应用程序。当这种类型的应用程序看到里面的组织时,具有很好的机会这是良性的交通: 也许自制程序备份或脚本的维护任务。如果这些在外出,或来自互联网的各届会议上出现,他们应该有理由感到关切。
作为一个经验法则, 最好的做法是阻止所有未知的 udp/未知 tcp, 因为您不知道这些是什么类型的会话, 而且它们可能是恶意的.
然而, 盲目地拦截所有未知的通信量可能有点剧烈, 因为其中一些可能是合法的, 可能需要进行操作。最好的解决方案是通过创建自定义应用程序来开始识别通信量, 因此可以创建安全策略以更好地控制允许哪些流, 哪些应被阻止。
最快捷的方法是创建一个简单的自定义应用程序并设置一个应用程序重写. 当源和目标是内部和静态的, 就像从一个服务器到下一个受控环境中的脚本连接一样, 这一点很有帮助:
- 创建一个没有高级属性或签名的简化自定义应用程序。
我将风险因素设置为 5, 因为此方法在不进行进一步检查的情况下对会话应用 AppID.
- 创建应用程序重写策略以精确匹配预期的流 (应用程序重写只应用于标识管理员已知的流)。
- 现在将标识这些会话, 因为可以创建自定义应用程序和安全策略, 以根据应用程序控制会话。
识别应用程序的最佳方法是建立一个 packetcapture, 以便了解应用程序在防火墙中的外观, 然后创建一个与预期内容匹配的签名. 这样, 您可以确保会话是合法的。
- 在收集完整个会话后, 设置数据包捕获并收集 pcap 文件。有关数据包捕获的更多信息, 请查看他的文章:入门: 数据包
捕获 - 分析数据包捕获以获得适当的签名。在
下面的示例中, 我将使用 "2f69 6e66 6f3f 7478 7441 6972 506c 6179 2674 7874 5241 4f50" 的十六进制值, 这是我的 txtRAOP 中的 "/信息 txtAirPlay 和 packetcapture" 的明文等价.
- 创建一个与要识别的会话参数相匹配的新自定义应用程序: 在我的示例中, 我捕获了一个自定义 AirPlay 协议, 我已经分配了一个1的风险因子, 因为它在组织内部被认为是安全的。
它将使用 TCP 端口7000作为目标端口, 从客户端到服务器。
在签名中, 您可以使用 pcap 中的十六进制值, 如下面的示例所示: (对于十六进制模式, 请确保添加前导和尾随 '\ x', 让引擎知道它需要匹配十六进制, 而不是转换的明文),
或在 t 中看到的 regex 字符串。他的示例: (对于明文字符串, 请确保使用正斜线 "\" 来注释任何特殊字符, 以指示这是字符的文本匹配, 否则它可以被标识为通配符).
为了进一步限制字符串的位置, 我为 http 方法获取设置了一个限定符, 因为这是字符串应该被找到而不是在正文中进一步的位置。此签名的上下文是 http 请求参数, 因为自定义 AirPlay 协议使用 http 命令与服务器通信, 因此上下文选项将需要设置为在客户端之间的通信中使用的适当协议 (如果有), 并且服务器。
有关更多示例, 请查看视频教程: 自定义应用程序和入门 : 自定义应用程序和应用程序重写. 常见的上下文包括 "未知的-必需的-tcp 负载", 未知的-可粒子-tcp 负载 ', ' http-要求-主机头 ' 和其他一些地方-要求-代表客户端请求, 和-悬浮粒子-是服务器应答, 允许您选择拦截和识别的一方。
- 创建自定义应用程序并提交配置后, 未知 tcp 会话应由日志中的新自定义应用程序替换:
- 这意味着现在可以创建安全策略来对这个特定的应用程序有更多的控制权, 允许您在不干扰业务关键型应用程序的情况下阻止未知通信量:
我希望你发现这篇文章信息丰富, 请随时留下评论。
收割者
有关自定义应用程序的更多想法和示例, 请访问帕洛阿尔托网络自定义签名讨论板 .
另见-
入门教程: 网络数据包捕获
视频教程: 自定义应用程序
入门教程︰ 自定义应用程序和应用程序重写