2021年12月，Log4j驚爆“核彈級”漏洞（Log4Shell），之后很快像癌癥一樣在互聯網上迅猛擴散，短時間內就讓全球超過40%的企業網絡遭遇襲擊，于是全世界的企業安全人員瞬間沒了周末。該漏洞利用成本極低，可以直接任意代碼執行，并接管目標服務器，其潛在危害嚴重性、影響面堪稱2021年之最。

Log4Shell攻擊面巨大，一些專家認為，此次漏洞與2014年Shellshock系列安全漏洞不相上下，后者在最初披露的數小時內就被受損計算機的僵尸網絡利用，發動了分布式拒絕服務(DDoS)攻擊和漏洞掃描。

Log4j漏洞并不罕見，因而應當予以持續關注，以充分識別和修復問題。以下為大家分享一些基本方法。

對Log4j 的擔憂主要由于 Java 日志庫的使用頗具普遍性，以及未經身份驗證的攻擊者能如此輕松就利用該漏洞實現遠程代碼執行 (RCE)。我們對配置更新，好像做好了Log4j攻擊套件的應對準備，但這一切只是臨時抱佛腳。與此同時，此種漏洞已出現變種 ，但在組織內部，涵蓋核心基礎設施全面升級的長期解決方案還遙遙無期。

由于隨后出現的通用漏洞披露 (CVE) ，加之許多團隊在更改配置、掃描資產排查易受攻擊軟件時過于草率，Log4j要被完全控制還需數月時間。許多組織要么長期停留在排查階段，試圖完全找出系統使用 Java 或 Log4j的地方，要么就一直在修復當中，因為運營或系統限制束縛了他們推出完整補丁的能力。

因為初始配置更改不夠充分，漏洞不斷變化，或需做好執行全面修復的準備。以下提到的最佳實踐及重要論點將幫助安全團隊在這方面做好籌謀。

大規模使用資產管理

在Log4j漏洞出現后，安全團隊抓緊尋找并優先考慮擁有大量資產的群體。人們共同企盼能有快速、可擴展的方法來查找 Java 和 Log4j 實例。可用檢測工具很多，但許多安全組織卻忘了一項基本內容：最新的軟件資產清單。

資產采集和處理非常關鍵，安全團隊需要如下問題的及時回答：哪些 Linux 服務器正在運行Log4j？哪些虛擬機使用Java？ 

強大的資產管理可加快修補周期，每當出現新的 Log4j 時，便立即需要新的補丁。資產管理能力更強的團隊對 Log4j 的響應更高效，他們能夠更快識別出易受攻擊的 Java 實例，同時監控修復對運營的影響。

最佳防御：加快修復周期 

安裝補丁是應對新興威脅的最佳方式，但攻擊者亦會迅速把新的 CVE 納入攻擊套件。要緩解攻擊和保護系統，升級到最新版本是最為可靠的辦法。隨著時間推移，依靠手動配置更改會導致系統出現漏洞，因為Log4j 等漏洞也在不斷演化，僅僅改變一個真/假旗標是不夠的。

檢查配置

加強資產管理實踐，要實施配置檢查。當新的 CVE 出現時，資產需要進一步更新和配置更改，確保可以從Log4j追蹤到它。在該漏洞管理計劃中，首要一點是安全團隊發現未知威脅的監控渠道。尋找高優先級威脅需要有穩妥的流程安排，不要靠聽小道消息或偏信推特內容，而要建立一個積極主動的流程。

解決遺留系統問題

如果組織還在使用與 Java 更新版本不兼容的遺留軟件，那么是時候采取行動，促使領導層（和供應商）建立強大的軟件資產清單和循環修復周期。處理技術負債(包括未修復的遺留軟件)會消耗過多的資源和帶寬，同時需要增加監控和補償性控制。當Log4j出現，安全團隊也就更有話語權，而這也是計劃升級遺留系統的好時機。

內網和氣隙（Air-Gapped）系統不容忽視

人們通常認為氣隙系統和內部設備是安全的，因為如果攻擊者接觸不到，自然也就無法利用。但這種假設對Log4j來說極為危險，因為未經身份驗證的請求，即使通過其他應用程序仍然可能導致遠程代碼執行(RCE)漏洞。對待氣隙系統和內網資產應如面向互聯網的資產一樣，隨時準備全面升級并展開配置跟蹤。

安全的自動擴展和部署

識別云環境中可能使用自動部署或自動擴展方案運行的資產。要確保這些配置是安全的，并且任何未來部署都不會使用過時的Java版本或Log4j庫。這需要與開發團隊合作，確保這些安全配置納入未來的構建當中。

參考鏈接：https://www.darkreading.com/attacks-breaches/log4j-getting-from-stopgap-remedies-to-long-term-solutions