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 的 JndiLoo.class 漏洞類，重新jar打包，把新的log4j-core-2.12.1.jar拷貝到原來的目錄裡面覆蓋老的jar。

rm -rf  org/apache/logging/log4j/core/lookup/JndiLoo.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 或資訊洩漏的影響，因為這些版本已經在 J​​DK 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 日釋出的Elasticsearch7.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 日釋出的Logstash6.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 或資訊洩露的影響，因為這些版本已經在 J​​DK 11 或更高版本上執行。

解決方案和緩解措施：
託管在 Elastic Cloud 中的部署已更新以利用 JVM 選項 -Dlog4j2.formatMsgNoLookups=true這將在部署重新啟動以及對 Elasticsearch 部署進行任何配置更改時生效。

對於在低於 7.2 的次要版本上執行叢集的使用者，我們建議重新啟動。

重新啟動部署的最簡單方法是執行以下操作：

1. 登入雲使用者介面。導航到 Elasticsearch Service 中的“部署”部分。
2. 選擇您要重新啟動的部署。
3. 在“管理”選單中，選擇“重啟”。任何型別的重啟都可以：“無停機”重啟就可以了。