链接 搜索 菜单 扩大 文档

Apache Log4j漏洞

Apache Log4j漏洞(CVE-2021-44228)是一个关键漏洞，应该在任何受影响的系统上立即解决，无论您是否有其他缓解或加固措施。

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

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

哪些产品受到影响?

客户管理的Orchestrator和遗留GMS产品会受到此漏洞的影响。这包括运行在公共云服务(如AWS、Azure、谷歌或Oracle cloud)中的本地和客户管理实例。有关如何缓解此漏洞的详细信息，请参阅所需的纠正措施。

哪些产品不受影响?

  • EdgeConnect和遗留的NX、VX、VRX产品不使用Log4j2库，因此不容易受到攻击。

  • Silver Peak托管的云编排器服务(Silver Peak Orchestrator as a Service, Orch-AAS)、Orchestrator- sp和Orchestrator Global Enterprise)不受影响。这些服务使用AWS Shield作为服务前面的WAF防火墙。AWS Shield阻止任何使用代码利用字符串的尝试。

我能等到银峰发布一个补丁吗?

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

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

没有-端口阻塞不会保护Orchestrator免受这个漏洞。攻击者只需要常规的未经身份验证的HTTPS访问就可以获得控制。

如果Orchestrator只能通过受信任的ip访问，我是否仍然受到影响?

如果您可以信任从这些ip访问Orchestrator的用户，则不会受到影响。银色的峰值仍然建议您采取本页和建议中提到的纠正措施。

如果Orchestrator在防火墙之后，它仍然是脆弱的吗?

如果防火墙阻止带有JNDI指令的HTTP头，那么您的Orchestrator应该是安全的。请注意，大多数防火墙在默认情况下并没有启用此功能，您可能需要配置它。银色的峰值仍然建议您采取本页和建议中提到的纠正措施。

手动给系统打补丁的程序是什么?

  1. SSH到Orchestrator虚拟机，并以管理．

  2. 进入“/home/gms/gms”目录。

  3. 打开名为gmsserver进行编辑。

  4. 定位以以下文本开头的行:exec $ JAVA_HOME / bin / java

  5. 在前面添加下面的文本com.silverpeak.gms.server.VistaPointServer

    -Dlog4j.formatMsgNoLookups = true

    例子:

    exec $JAVA_HOME/bin/java——add-open java.base/java。lang= all -未命名-server -Xms256m -Xmx${Xmx}m -classpath "。:$BASE_DIR/properties:$BASE_DIR/metaData:$BASE_DIR/lib/*" -server -XX:ErrorFile=${HOME_DIR}/gms/logs/java_error%p.log -XX:HeapDumpPath=${HOME_DIR}/gms/logs -XX:+HeapDumpOnOutOfMemoryError ${JVM_ARGS} -Djdk.tls。ephemeralDHKeySize = 2048 -Djava.io。tmpdir = $ {TEMP_DIR} -Djavax.net.ssl.trustStore = $ {HOME_DIR} /总经理/属性/ cacerts com.silverpeak.gms.server.VistaPointServer

    例后:

    exec $JAVA_HOME/bin/java——add-open java.base/java。lang= all -未命名-server -Xms256m -Xmx${Xmx}m -classpath "。:$BASE_DIR/properties:$BASE_DIR/metaData:$BASE_DIR/lib/*" -server -XX:ErrorFile=${HOME_DIR}/gms/logs/java_error%p.log -XX:HeapDumpPath=${HOME_DIR}/gms/logs -XX:+HeapDumpOnOutOfMemoryError ${JVM_ARGS} -Djdk.tls。ephemeralDHKeySize = 2048 -Djava.io。tmpdir = $ {TEMP_DIR} -Djavax.net.ssl.trustStore = $ {HOME_DIR} /总经理/属性/ cacerts -Dlog4j。formatMsgNoLookups = true com.silverpeak.gms.server.VistaPointServer

  6. 保存文件并重新引导Orchestrator虚拟机。

  7. 从浏览器中测试Orchestrator状态，以确保Orchestrator已经启动并运行。

    警告:编辑文件时的任何打字错误或错误都可能导致Orchestrator无法启动。如果发生这种情况，重复步骤1到6来纠正错误。

如何验证手动修复是否有效?

按照以下步骤验证上述和建议中详细的纠正措施:

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

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

    b.发出以下命令:Tail -f jetty-request.log | grep "espn.com"

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

    a.切换到root。

    b.发出以下命令:Tcpdump -i any -n port 53

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

    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解析请求。

Baidu