链接 搜索 菜单 扩大 文档

Apache Log4j漏洞

Apache Log4j漏洞-CVE 2021 - 44228,CVE 2021 - 45046-是在任何受影响的系统上都应立即解决的关键漏洞，无论您可能有任何其他缓解或加固实践。

CVE 2021 - 45105另一个相关的脆弱性，但是没有银峰产品受CVE 2021-45105影响。

这种脆弱性的潜在影响是什么?

任意代码执行意味着未经身份验证的攻击者可以在Orchestrator上执行任何代码。这意味着攻击者可以完全、完全地控制SD-WAN网络。

哪些产品会受到影响?

所有Orchestrator和遗留GMS产品均受CVE 2021-44228和CVE 2021-45046影响，包括:

  • 自我管理的内部编排器(执行现在这个过程，然后在可用时升级)
  • 在公有云服务中运行的自管理的Orchestrator(执行现在这个过程，然后在可用时升级)
  • 从市场映像(AWS、Azure、GCP)安装的自管理云实例(执行现在这个过程，然后在可用时升级)
  • Silver Peak Orchestrator as a Service (Orch-AAS)(使用Support打开一个案例，在可用时升级托管实例)
  • Orchestrator- sp和Orchestrator全局企业租户(当有升级时，服务提供商必须对Orchestrator租户进行升级)

我能等到Silver Peak发布补丁吗?

没有-这是一个严重的漏洞，你必须立即采取行动，手动修补你的系统。当Silver Peak发布经过补丁的Orchestrator版本时，必须将该补丁应用到所有受影响的系统。

哪些版本将被银峰打补丁?

以下版本的Orchestrator已经发布了补丁:

影响释放 打补丁的版本
8.9.16 8.9.17_40006
8.10.19 8.10.20_40008
9.0.6 9.0.6_40144
9.1.0 9.1.0_40524

如果您没有在将要修补的发布系列中运行Orchestrator版本，则应该尽快手动修补系统。此外，强烈建议您尽快升级到经过修补的Orchestrator版本。

如果您正在从旧版本的Orchestrator升级，请确保查看发行说明，以理解要遵循的升级路径。

自管理的Orchestrator实例的手动补丁

您可以观看手动补丁程序的视频演练在这里．

下面的过程从已安装的Log4j库更新易受攻击的类。

  1. SSH到Orchestrator虚拟机，并以管理用户。

  2. 改变/home/gms/gms/lib:cd /home/gms/gms/lib

  3. 为受影响的文件创建备份目录:mkdir /home/gms/log4jbackup

  4. 复制受影响的库:cp log4j * /home/gms/log4jbackup

  5. 切换到根:苏

  6. 停止Orchestrator服务:systemctl停止gms

  7. 退出根:退出

  8. 改变/home/gms/gms/lib:cd /home/gms/gms/lib

  9. 执行以下命令删除受影响的类:

    org/apache/logging/log4j/core/lookup/JndiLookup.class . zip -q -d log4j-core-*.jar

  10. 立刻根:苏

  11. 启动Orchestrator服务:systemctl开始gms

  12. 退出root，退出SSH会话。

执行手动补丁有什么影响?

手动补丁程序只是对漏洞进行补丁。对Orchestrator没有影响，因为受影响的类没有被Orchestrator使用。

补丁是否会影响Orchestrator中的任何功能，比如搜索日志?

一切都会像以前一样正常运转。任何与Orchestrator相关的日志都不会受到影响。

日志功能是否仍然像预期的那样工作?

是的

升级到已打补丁的Silver Peak Orchestrator版本是否会纠正已实现的工作并纠正漏洞?

是的

如何确认手动补丁是否正常工作?

您可以观看验证程序的视频演练在这里．

请按照以下步骤验证上面的手动补丁程序:

在下面的例子中，我们使用了“espn.com”。您可以使用任何URL，只要您确定它不存在于DNS缓存中。

  1. 打开一个到Orchestrator的SSH会话并以管理．

    a.修改目录为“/home/gms/gms/logs”

    b.执行如下命令:Tail -f jetty-request.log | grep "espn.com"

  2. 打开另一个到Orchestrator的SSH会话并以管理．

    a.切换至“root”。

    b.执行如下命令:Tcpdump -i any -n port 53

  3. 打开另一个到Orchestrator的SSH会话并以管理．

    a.执行如下命令:curl -k -H 'User-Agent: ${jndi:ldap://www.espn.com/a}' https://< Orchestrator的外部IP >/gms/rest/gmsserver/ping

  4. 如果Orchestrator容易受到攻击，您将在tcpdump SSH会话中看到一个针对“espn.com”的DNS解析请求。

我如何知道我的Orchestrator被攻破了?

以下指导仅适用于内部或自托管的Orchestrator实例。

警告:Silver Peak不保证任何开放源代码的有效性，包括下面引用的代码，并且Silver Peak不会为任何此类代码提供支持。虽然这些工具可能是有效的，但Silver Peak的客户使用这些工具的风险由他们自己承担。

通过搜索服务器上的所有日志文件，寻找与jndi相关的利用字符串，可以检测利用尝试。虽然可以执行直接搜索，但攻击字符串很容易被混淆。以下脚本在搜索时考虑了混淆问题:

  • Log4Shell-detector-针对Log4Shell使用尝试的检测器
  • 注意:需要搜索的日志目录除系统日志目录外，还包括“/home/gms/gms/log .”

可以执行以下手动搜索，但这些搜索不考虑任何模糊利用企图的尝试:

$ sudo找到/var/log类型f -print0 | xargs 0 zgrep - e -我\ \{美元jndi: (ldap [s] ? | rmi | dns): / [^ \ n] + '

$ sudo find /home/gms/gms/logs -type f -print0 | xargs -0 zgrep -E -i '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+'

$ sudo找到/var/log/ - name " * . gz "型f - sh - c”zcat {} | sed - e ' s / \ ${低:/ / ' g | tr - d '} ' | egrep -我的jndi: (ldap [s] ? | rmi | dns):’“\;

$ sudo找到/home/gms/gms/logs/ - name " * . gz "型f - sh - c”zcat {} | sed - e ' s / \ ${低:/ / ' g | tr - d '} ' | egrep -我的jndi: (ldap [s] ? | rmi | dns):’“\;

关于其他安全措施的其他问题

一些客户询问额外的安全措施或加固过程是否有助于防止此漏洞。虽然下列一些措施可能提供某种程度的保护，但建议的行动方针是手动补丁然后提升自我管理的协调器或打开一个案例来升级您的Silver Peak托管实例在可能的情况下。

如果我阻塞端口，我的Orchestrator安全吗?

没有-端口阻塞将不能保护Orchestrator免受此漏洞。攻击者只需要常规的未经身份验证的HTTPS访问就可以进行控制。

如果Orchestrator只能通过受信任的ip访问，我还会受到影响吗?

如果可以信任从这些ip访问Orchestrator的用户，则不会受到影响。

如果Orchestrator位于防火墙之后，它是否仍然脆弱?

如果防火墙用JNDI指令阻止HTTP报头，那么您的Orchestrator应该是安全的。请注意，大多数防火墙默认情况下都没有启用此功能，您可能需要对其进行配置。

Baidu