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 中的“部署”部分。
- 選擇您要重新啟動的部署。
- 在“管理”菜單中，選擇“重啟”。任何類型的重啟都可以：“無停機”重啟就可以了。