Mirantis (Docker, K8s) – 判斷是否受 Log4j 漏洞影響及官方建議處置
內容目錄
歐立威科技整理 Mirantis 官方針對本次 Log4j 漏洞的影響與建議的處置,更多關於本次漏洞訊息及其他產品處置請參考 Apache Log4j 漏洞事件說明與建議處置。
2021年12月9日,Apache Log4j 被揭漏有重大風險漏洞 Log4Shell,漏洞編號 CVE-2021-44228。駭客可以利用該漏洞發動遠端程式碼執行攻擊,最嚴重可以接管整台系統,影響範圍擴及 Apache Log4j 2 中 logging library 的多個版本,資安專家稱為近 10 年來最嚴重漏洞,研究人員也發現已經有針對該漏洞的攻擊行動。
Mirantis 已經確認大部分產品都沒有受到該漏洞的影響,少數有問題的部分嚴重程度也較低。想要評估工作負載軟體是否受到影響的用戶可以使用 Mirantis Secure Registry (MSR)。Mirantis 已更新 MSR 中的漏洞資料庫以掃描 Log4j 漏洞 CVE-2021-44228。
Mirantis 的大多數產品都沒有受到該漏洞的影響,詳細的資訊可以在 GitHub security update 上找到。
有兩個受影響的產品,漏洞嚴重性較低,並且組件不易受到遠程執行代碼 (Remote Code Execution) 的影響。
• Lens Spaces – 已應用補丁且未觀察到任何駭客攻擊 (Compromise) 跡象。用戶無需採取任何行動。
• Mirantis Cloud Platform (MCP) (2019 年 2 月 16 日以前(含)) – MCP StackLight ElasticSearch 組件可能會透過 DNS 洩漏資訊,該組件不容易受到遠端代碼執行的影響,由於可以洩露的數據有限,Mirantis PSIRT 將漏洞嚴重性評分為 LOW (CVSSv3.1 評分 3.6)。
在 MCP StackLight 節點上,將 -Dlog4j2.formatMsgNoLookups=true 附加到文件 /etc/elasticsearch/jvm.options 並執行 systemctl restart elasticsearch 以重新啟動 elasticsearch 進程。建議在可用時升級到 MCP 2019.2.17。
Mirantis Secure Registry 更新後已經可以掃描 CVE-2021-4428,用戶應檢查 MSR 中的漏洞資料庫更新、安裝最新的更新並執行掃描。 MSR 將檢測 Log4j 並回報漏洞。
由於 Log4j 在深植在眾多技術中,識別、緩解、解決 Log4Shell 漏洞將是一個漫長的過程。這個過程從找出可能受影響的組件開始,強烈建議所有企業盡快掃描資料庫,並聯繫相關廠商尋求幫助。
本文章為歐立威科技整理原廠官方文件與網路資源,並非即時更新,僅供使用者參考,使用者應自行審慎評估自身環境及官方最新建議以採取最佳行動,若需要任何技術支援歡迎聯絡我們。
參考資料:
從 Openshift/Kubernetes 和其他應用程式/系統收集日誌/指標,擁有端到端、從上層到底層的全面可觀測性,加快對問題的定位和排除,保障業務的可連續性;AIOps 為 IT 和應用程式效能管理,可以大大增加整體維運的效率,以及預判可能發生的故障同時提高整體 ROI。
當前支援的 Pentaho 版本中不存在此漏洞,因為預設情況下沒有使用易受攻擊的類別(Classes)。但是為了響應最近發布的 CVE-2021-44228 漏洞,Hitachi Vantara 的資訊團隊對已發布的軟體 (包括 Pentaho) 進行了測試。
K8s 是一種容器資源調度平台,能將部署流程自動化、擴展並管理不同容器間的工作負載。它的微服務管理叢集,能夠啟動容器,管理網路和容器間的通訊。此外,它還能將多個 Container 分派到多台主機上,並監控每個 Container 的運行狀態。這些功能讓開發者能夠專注於軟體開發任務。
ECK 是 Elastic Cloud on Kubernetes 的縮寫,有了它,就能在 Kubernetes 環境快速完成下列的常見工作:管理和監控多個群集、安全地執行設定調整以完成滾動升級、橫向延展群集的資源和空間、設定群集的 TLS 憑證、設定「熱-暖-冷」資料節點的架構
本次活動邀請到在金融業服務的社群講師-張哲嘉,他將分享企業如何在雲端與地端部署與應用 HashiCorp Vault。
透過 Elastic Stack 產品的高度整合,能提供 Elastic Observability 完整的服務。包含,Observability 三本柱,Metrics、Logs、Traces,為不良行為進行檢測,與提供維運人員提供詳細的資訊,快速有效的調整問題。
本次研討會將從企業導入開源方案的角度,著重 CI/CD 流程裡的建置、驗測、部署階段,介紹架構評估和工具測試的思路歷程,透過最小可行產品的範例情境,快速展示流程裡可能遭遇的議題,包括程式碼版本管控、Pipeline Stage 建置、應用服務部署等。
ASAPP 在 Kubernetes 上使用 Operator 模式運行 Vault,讓客戶能夠與 Vault 整合並管理機密,而無需被任何 SRE 干擾。此篇文章,我們將討論在 VM 到 Kubernetes 上運行 Vault 的歷程,並討論在 Kubernetes 上運行的優勢。
Mirantis 已經確認大部分產品都沒有受到該漏洞的影響,少數有問題的部分嚴重程度也較低。想要評估工作負載軟體是否受到影響的用戶可以使用 Mirantis Secure Registry (MSR)。Mirantis 已更新 MSR 中的漏洞資料庫以掃描 Log4j 漏洞 CVE-2021-44228。
Elasticsearch、Fluentd 和 Kibana 的日誌監控解決方案稱為 EFK Stack。Prometheus 是眾所皆知的開源工具,特別是在最近 Kubernetes 環境的指標監測方面有主導地位。Fluentd 是開源日誌收集工具,類似 Elastic Stack 中的 Logstash
如果您使用上圖「CDH、HDP、HDF」或「CDP Private Cloud」中列出的任何版本產品,請參閱 Resolution for TSB-545 – Private Cloud 如果您使用上圖「CDP Public Cloud」中列出的任何版本產品,請參閱 Resolution for TSB-545 – Public Cloud 如果您使用的是受影響的 Cloudera 驅動程式 (driver) 版本,請參閱 Resolution for TSB-545 – Cloudera Drivers 如果您使用的是 Cloudera Streaming Analytics (CSA) 1.4.x 或 1.5.x,您可以選擇應用修補程序來修復漏洞,或升級到 CSA-1.6.0,該版本將於 12/20 前發布。
本次研討會除了介紹 K8s 基本架構和組件外,也會分享基本操作指令,以及實際使用中遇到的問題與解決方法,希望能協助大家少踩一點雷!
VMware 已經發布了 PXF 6.2.1 和 GPText 3.8.1,它們在最新的 VMware Tanzu Greenplum 版本 (5.29.2 和 6.19.0) 中已經可以使用。這兩個版本將 Apache Log4J 組件更新到 2.16.0,解決 CVE-2021-44228 和 CVE-2021-45046。如果您無法升級到 PXF 6.2.1 或 GPText 3.8.1,請參考原廠建議的解決方法來降低此漏洞的風險。
本次研討會將協助企業 IT 人員,認識容器技術與雲原生架構的生態系現況,CI/CD 的應用流程 Demo;以及評估導入方案時,值得留意的考慮面向如安裝環境支援度,上手易用度,安全策略規範…等。
Apache 基金會建議使用者應立即升級到 Log4j v2.15.0。使用 2.10 以前版本者,則應從 classpath 移除 JndiLookup class。我們整理 EDB、Cloudera、Elastic 原廠針對此次漏洞的建議處置與相關資源,不同產品的影響程度與處置相差極大,詳情請閱讀針對該產品的文章或聯絡我們以得到顧問諮詢和技術支援。