1. elasticsearch7.6.2 修补log4j漏洞
找到安装配置目录：/usr/local/elasticsearch-7.6.2/config的 jvm.options文件 添加
-Dlog4j2.formatMsgNoLookups=true
并重新启动集群的每个节点。
2. logstash7.6.2 修补log4j漏洞
cd /usr/share/logstash/logstash-core/lib/jars
备份log4j-core-2.12.1.jar 包,把jar 移动到log4j文件夹里面，jar命令解压log4j-core-2.12.1.jar ,并删除log4j-core-2.12.1.jar文件。
cp log4j-core-2.12.1.jar log4j-core-2.12.1-back.jar mkdir log4j mv log4j-core-2.12.1.jar ./log4j jar -xvf log4j-core-2.12.1.jar rm -rf log4j-core-2.12.1.jar
删除log4j-core-2.12.1.jar 的 JndiLookup.class 漏洞类，重新jar打包，把新的log4j-core-2.12.1.jar拷贝到原来的目录里面覆盖老的jar。
rm -rf org/apache/logging/log4j/core/lookup/JndiLookup.class jar -cvf log4j-core-2.12.1.jar ./ cp log4j-core-2.12.1.jar ../
重新启动logstash即可。
摘要文： 2021 年 12 月 9 日，该项目的GitHub公开披露
了一个影响Apache Log4j 2实用程序多个版本的高严重性漏洞 (CVE-2021-44228)。该漏洞影响 Apache Log4j 2 版本 2.0 至 2.14.1。
本公告总结了目前已知的对 Elastic 产品的潜在影响以及缓解该问题的相关公告。弹性工程和安全团队继续积极开展分析和我们的用户应执行的任何操作，同时识别可用于识别漏洞潜在利用的检测签名。
Elasticsearch
与最新版本的 JDK (JDK9+) 一起使用的受支持的 Elasticsearch 版本（6.8.9+、7.8+）不易受到远程代码执行或信息泄漏的影响。这是由于 Elasticsearch 使用了 Java 安全管理器。大多数其他版本（5.6.11+、6.4.0+ 和 7.0.0+）可以通过简单的 JVM 属性更改来保护。该信息泄露漏洞不允许访问 Elasticsearch 集群内的数据。我们已经发布了 Elasticsearch 7.16.1 和 6.8.21，它们默认包含 JVM 属性，并出于谨慎考虑删除了 Log4j 的某些组件。下面的其他详细信息。
弹性云
我们的安全测试未发现任何针对任何弹性云产品的可利用 RCE。我们的调查仍在继续，我们将提供任何新发现的更新。作为正常做法，我们将在可用时使用最新版本的 Log4j 更新组件。
我们建议使用7.2之前的Elastic Cloud 版本的用户尽快重新启动他们的部署以获取更新的设置。 下面的其他详细信息。
APM Java 代理
APM Java 代理只有在配置了代理log_level=trace并同时使用PLAIN_TEXT日志格式时才可利用。下面的其他详细信息。
Elastic Cloud Enterprise
我们的安全测试未发现任何与此问题相关的可利用漏洞。我们将继续分析该问题，并会提供任何更新建议。作为正常做法，我们将在下一个版本中更新任何包含易受攻击的 Log4j 版本的组件。由 ECE 管理的 Elasticsearch 集群的缓解详细信息如下。
Elastic Cloud on Kubernetes
虽然 ECK Operator 不受此漏洞的影响，但由 ECK 管理的 Elasticsearch 集群的缓解细节如下。
Logstash
对远程代码执行的暴露存在于 8u191 之前的 JDK 上。在较新版本的 JDK 上，存在拒绝服务和信息泄漏的风险，但没有已知的远程代码执行风险。缓解措施需要删除 JndiLookup 类或更新到已于 12 月 13 日发布的 Logstash 版本 6.8.21 或 7.16.1。下面的其他详细信息。
Swiftype
我们的安全测试没有发现任何针对 Swiftype 产品的可利用 RCE。我们的调查仍在继续，我们将提供任何新发现的更新。我们采取了缓解措施作为预防措施，并将在可用时使用最新版本的 Log4j 更新组件。
未受影响我们已验证以下 Elastic 产品中不存在此漏洞：
- APM服务器
- 节拍
- 命令
- 弹力剂
- Kubernetes 上的弹性云
- 弹性残局
- 弹性地图服务
- 端点安全
- 企业搜索
- 车队服务器
- 基巴纳
- 机器学习
APM Java 代理代码执行问题 (ESA-2021-31)
在 1.17.0-1.28.0 版本中，唯一已知的 Log4j 漏洞可能被利用的方式是使用log_level =trace配置 APM Java Agent ，同时使用 PLAIN_TEXT 日志格式 ( log_format_stdout / log_format_file =PLAIN_TEXT)。
受影响的版本：
版本 1.17.0-1.28.0
解决方案和缓解措施：
运行 1.28.1 之前版本的用户应升级到最新版本（1.28.1 或更高版本）。
在 1.17.0-1.28.0 版本中，可以通过设置系统属性 - 手动缓解该问题Dlog4j2.formatMsgNoLookups=true。
Elasticsearch 公告 (ESA-2021-31)
由于我们使用了 Java 安全管理器，Elasticsearch 6 和 7 不易受此漏洞的远程代码执行影响。在 JDK8 或更低版本上运行的 Elasticsearch 容易受到 DNS 信息泄漏的影响，这可以通过下面标识的 JVM 选项进行修复。此选项对 Elasticsearch 版本 5.6.11+、6.4+ 和 7.0+ 有效。
截至 2021 年 12 月 13 日，我们已经发布了 Elasticsearch 6.8.21 和 7.16.1，它们设置了下面标识的 JVM 选项，并出于谨慎考虑从 Log4j 中删除了易受攻击的 JndiLookup 类。
Elasticsearch 5 容易受到远程代码执行和 DNS 信息泄漏的影响。对于 5.6.11 - 5.6.16 版本，这可以通过设置 JVM 选项来缓解。建议使用 5.x 早期版本的用户升级到 5.6.16。 对于无法升级的情况，我们正在探索其他选项。请注意，虽然我们提供了这些补救措施，但 Elasticsearch 5 不是受支持的版本，我们始终建议更新到最新版本。
Elasticsearch 2 及更早版本使用了不易受新发现缺陷影响的 Log4j 版本。请注意，Elasticsearch 2 不是受支持的版本，我们始终建议更新到最新版本。
对于在 Elastic Cloud 上运行的用户，7.2+ 版本从来不会受到 RCE 或信息泄漏的影响，因为这些版本已经在 JDK 11 或更高版本上运行。我们建议运行早于 7.2 的任何版本的 Elasticsearch 的用户尽快重启他们的集群 - 下面标识的 JVM 选项将自动应用并在重启时完全保护集群。任何新集群都将在部署时包含 JVM 选项。有关更多详细信息，请参阅 Elastic Cloud 公告
受影响的版本：
Elasticsearch 5.0.0+ 版本包含一个易受攻击的 Log4j 版本。Elasticsearch 5 容易受到远程代码执行和 DNS 信息泄漏的影响。我们已经确认安全管理器减轻了 Elasticsearch 6 和 7 中的远程代码执行攻击。
解决方案和缓解措施：
最简单的补救措施是设置JVM 选项 -Dlog4j2.formatMsgNoLookups=true并重新启动集群的每个节点。
对于 Elasticsearch 5.6.11+、6.4+ 和 7.0+，这提供了针对 RCE 和信息泄漏攻击的全面保护。
用户可以升级到2021 年 12 月 13 日发布的Elasticsearch 7.16.1或6.8.21。这些版本不会升级 Log4j 包，而是通过设置JVM 选项来 缓解漏洞-Dlog4j2.formatMsgNoLookups=true并从 Log4j 包中删除易受攻击的 JndiLookup 类.
注意：在这两种情况下，一些漏洞扫描器可能会继续仅基于 Log4j 版本来标记与此漏洞相关联的 Elasticsearch。但是，上述任何缓解措施都足以保护远程代码执行和信息泄漏。
如果 Elasticsearch 由ECK管理，请在 Elasticsearch 自定义资源podTemplate 规范中设置 JVM 选项。
如果 Elasticsearch 由ECE管理，对于 6.x 和 <7.2 版本，我们建议重新安装堆栈包，该堆栈包已打补丁以包含 JVM 选项缓解。重新安装相关堆栈包后，我们建议重新启动部署。对于 5.x 系列，我们建议覆盖 JVM 选项以添加可缓解漏洞的属性，并重新启动集群以获取更改：有关详细信息和指导，请联系 Elastic 支持。
Elasticsearch 信息泄露细节
Log4j 中的信息泄露漏洞使攻击者能够通过 DNS 泄露某些环境数据——它不允许访问 Elasticsearch 集群内的数据。可以泄漏的数据仅限于通过 Log4j“查找”可用的数据，其中包括系统环境变量和来自其他来源的一组有限的环境数据。有关完整列表，请参阅Log4j 查找文档。
关于将 RCE 扩展到最新 Java 版本的概念证明 (PoC) 的说明
我们正在积极监控安全社区的发展，例如这个寻求扩展 JDK 和应用此漏洞利用的场景。我们在 Elasticsearch 6 和 7 中实现的 Java 安全管理器，结合 JDK9 或更高版本，继续防止所有已知的 PoC。尽管这些努力寻求提供可行的 RCE，即使 com.sun.jndi.ldap.object.trustURLCodebase=false（如最近的 JDK），我们的安全管理器在此过程中更早地切断了攻击，防止远程和本地（在类路径）攻击的变体。
Logstash 公告 (ESA-2021-31)
在早于 8u191 和 11.0.1 的 JDK 上运行时，攻击者能够注入和执行远程 Java 类。在最近的 JDK 上，攻击仅限于 DoS - 导致数据摄取暂时停止 - 和信息泄漏，但没有已知的远程代码执行攻击向量。
受影响的版本：
Logstash 5.0.0+ 版本（包括 7.16.0）包含一个易受攻击的 Log4j 版本。
Logstash 版本 6.8.x 和 7.x 直到并包括 7.16.0，当配置为在低于 8u191 和 11.0.1 的 JDK 上运行时，允许远程加载 Java 类。
低于 6.4.3 版本的 Docker 镜像包含一个早于 8u191 的 JDK，这意味着它们对远程代码执行开放。图像 6.4.3+ 没有已知的 RCE 攻击，但仍然容易受到拒绝服务和信息泄漏的影响。
解决方案和缓解措施：
用户应升级到2021 年 12 月 13 日发布的Logstash 6.8.21或7.16.1。这些版本将 Log4j 的易受攻击版本替换为 Log4j 2.15.0。
-Dlog4j2.formatMsgNoLookups=true在所有情况下，广泛使用的标志不足以缓解 Logstash 中的漏洞，因为 Logstash 以一种标志无效的方式使用 Log4j。因此有必要使用以下命令从 log4j2 核心 jar 中删除 JndiLookup 类：
zip -q -d <LOGSTASH_HOME>/logstash-core/lib/jars/log4j-core-2.* org/apache/logging/log4j/core/lookup/JndiLookup.class
请注意，要使更改生效，必须重新启动 Logstash 进程。
弹性云公告 (ESA-2021-31)
我们的安全测试未发现任何针对任何弹性云产品的可利用 RCE。我们的调查仍在继续，我们将提供任何新发现的更新。作为正常做法，我们将在可用时使用最新版本的 Log4j 更新组件。
运行 Elastic Cloud 7.2+ 版本的用户从来不会受到 RCE 或信息泄露的影响，因为这些版本已经在 JDK 11 或更高版本上运行。
解决方案和缓解措施：
托管在 Elastic Cloud 中的部署已更新以利用 JVM 选项 -Dlog4j2.formatMsgNoLookups=true这将在部署重新启动以及对 Elasticsearch 部署进行任何配置更改时生效。
对于在低于 7.2 的次要版本上运行集群的用户，我们建议重新启动。
重新启动部署的最简单方法是执行以下操作：
- 登录云用户界面。导航到 Elasticsearch Service 中的“部署”部分。
- 选择您要重新启动的部署。
- 在“管理”菜单中，选择“重启”。任何类型的重启都可以：“无停机”重启就可以了。