說個(gè)這幾天在安全圈里發(fā)酵的事Nacos 的 Derby 組件被曝出遠(yuǎn)程命令執(zhí)行漏洞。如果你所在公司用了 Nacos 做配置中心和注冊(cè)中心我建議先把手頭的事放一放認(rèn)真看完這篇。Nacos 在微服務(wù)體系里太常用了它管著配置、管著服務(wù)發(fā)現(xiàn)一旦本身出問題影響往往不是單臺(tái)機(jī)器而是一整片業(yè)務(wù)。這個(gè)漏洞的名字也很直白——Nacos Derby 遠(yuǎn)程命令執(zhí)行漏洞攻擊者有機(jī)會(huì)通過 Nacos 內(nèi)嵌的 Derby 數(shù)據(jù)庫(kù)做到在服務(wù)器上執(zhí)行命令。這篇文章不聊花哨的利用技巧重點(diǎn)講清楚它是什么、怎么自查、怎么修復(fù)以及我在實(shí)際排查中踩過哪些坑。讀完你至少能知道自己要不要應(yīng)急。1. 漏洞背后的基礎(chǔ)Nacos 與 Derby 各是什么1.1 Nacos 在微服務(wù)架構(gòu)里的定位Nacos 是很多團(tuán)隊(duì)搭建微服務(wù)時(shí)繞不開的基礎(chǔ)組件核心職能是兩個(gè)配置管理和服務(wù)發(fā)現(xiàn)。配置管理解決的是“配置改一處所有服務(wù)生效”的問題服務(wù)發(fā)現(xiàn)解決的是“哪個(gè)服務(wù)實(shí)例在哪個(gè)地址、健康狀態(tài)如何”的問題。簡(jiǎn)單說Nacos 就像整個(gè)系統(tǒng)里的“信息中樞”各個(gè)服務(wù)啟動(dòng)時(shí)找它拉配置運(yùn)行中找它拿服務(wù)地址。正因?yàn)檫@個(gè)定位Nacos 在安全體系里的重要程度往往被低估。很多人覺得它不過是一個(gè) Java 服務(wù)最多就是配置中心但實(shí)際上一旦 Nacos 被攻破攻擊者能看到所有服務(wù)的配置信息包括數(shù)據(jù)庫(kù)連接串、緩存地址、各類密鑰和接口開關(guān)。這些東西的價(jià)值不亞于直接拿到一臺(tái)跳板機(jī)。這也是為什么當(dāng) Nacos 出現(xiàn)高危漏洞時(shí)安全團(tuán)隊(duì)通常都會(huì)按照最高優(yōu)先級(jí)處理。我在實(shí)際接觸過的一些項(xiàng)目里甚至見過開發(fā)環(huán)境、測(cè)試環(huán)境、生產(chǎn)環(huán)境共用同一套 Nacos 的情況。安全團(tuán)隊(duì)明明只暴露了測(cè)試環(huán)境的入口但因?yàn)槿篆h(huán)境沒隔離生產(chǎn)配置全部可以被讀取。所以理解 Nacos 的定位再看這個(gè)漏洞你會(huì)發(fā)現(xiàn)它真正可怕的不是漏洞本身而是 Nacos 在架構(gòu)中聚集了大量敏感信息。1.2 內(nèi)嵌 Derby默認(rèn)數(shù)據(jù)庫(kù)的角色Derby 是一個(gè)純 Java 編寫的關(guān)系型數(shù)據(jù)庫(kù)體積小、部署簡(jiǎn)單不需要單獨(dú)安裝數(shù)據(jù)庫(kù)服務(wù)。Nacos 之所以默認(rèn)選擇 Derby很大程度是為了降低初次使用門檻單機(jī)模式下載解壓就能啟動(dòng)配置存儲(chǔ)這些事由內(nèi)嵌 Derby 自動(dòng)完成用戶不用管數(shù)據(jù)庫(kù)。簡(jiǎn)單理解一下這兩層關(guān)系Nacos 是一個(gè) Web 服務(wù)它需要一塊地方保存配置數(shù)據(jù)。在單機(jī)模式下這塊地方就是內(nèi)嵌的 Derby 數(shù)據(jù)庫(kù)。Derby 不是一個(gè)獨(dú)立部署的進(jìn)程而是跟著 Nacos 進(jìn)程一起跑數(shù)據(jù)落在本地文件里。所以很多運(yùn)維人員排查時(shí)下意識(shí)會(huì)看 8848 端口、看 Nacos 應(yīng)用本身卻忽略了應(yīng)用內(nèi)部還掛著一個(gè)數(shù)據(jù)庫(kù)引擎。這里要澄清一個(gè)常見誤解內(nèi)嵌數(shù)據(jù)庫(kù)不等于安全。Derby 雖然沒有獨(dú)立的網(wǎng)絡(luò)監(jiān)聽端口但 Nacos 會(huì)通過自己的 HTTP 接口把數(shù)據(jù)庫(kù)操作能力暴露出來。凡是能訪問 Nacos 管理端口的人理論上都有可能觸碰到后面的 Derby 操作入口。端口不獨(dú)立不代表接口不暴露這是很多人栽跟頭的地方。1.3 漏洞為什么會(huì)落在 Derby 身上Derby 本身不是什么“易攻破數(shù)據(jù)庫(kù)”問題出在組合方式上。Nacos 為了管理配置提供了一些和數(shù)據(jù)庫(kù)相關(guān)的操作能力這些能力在正常情況下應(yīng)該被嚴(yán)格鑒權(quán)。但在某些版本和默認(rèn)配置下訪問控制不到位攻擊者只要構(gòu)造特定請(qǐng)求就可能讓 Derby 去執(zhí)行任意的 SQL 語(yǔ)句。更麻煩的是Derby 作為功能完整的數(shù)據(jù)庫(kù)支持一些高級(jí)特性包括動(dòng)態(tài)執(zhí)行 Java 代碼、調(diào)用系統(tǒng)命令等。這些能力本是給數(shù)據(jù)庫(kù)管理員在特定場(chǎng)景下用的可一旦攻擊者能控制輸入它們就變成了從 SQL 注入升級(jí)到遠(yuǎn)程命令執(zhí)行的橋梁。整個(gè)過程像什么呢就像一把多功能的瑞士軍刀正常使用沒問題但如果入口沒人看管任何路過的人都能拿起來用危險(xiǎn)程度自然成倍上升。所以看這個(gè)漏洞時(shí)不要只盯著“Derby”三個(gè)字要看到它背后的三層結(jié)構(gòu)暴露在外的接口、不嚴(yán)格的鑒權(quán)、過強(qiáng)的數(shù)據(jù)庫(kù)能力。后續(xù)修復(fù)和加固也要從這三層分別下手才能做到真正有效。2. 漏洞原理與影響遠(yuǎn)程命令執(zhí)行是如何發(fā)生的2.1 攻擊鏈路拆解不涉及潛在利用代碼雖然官方?jīng)]有公布所有技術(shù)細(xì)節(jié)但從多個(gè)公開分析和漏洞報(bào)告來看攻擊鏈路大致可以拆成四步。第一步攻擊者找到 Nacos 對(duì)外暴露的管理入口。Nacos 默認(rèn)監(jiān)聽 8848 端口如果這個(gè)端口能通過網(wǎng)絡(luò)觸達(dá)攻擊者就有了接觸機(jī)會(huì)。第二步由于鑒權(quán)未開啟或者鑒權(quán)存在繞過攻擊者能夠調(diào)用原本應(yīng)該受保護(hù)的管理接口。第三步攻擊者向這些接口提交惡意的 SQL 語(yǔ)句而該語(yǔ)句會(huì)直接進(jìn)入 Derby 執(zhí)行。第四步攻擊者利用 Derby 允許執(zhí)行 Java 特性的能力進(jìn)一步調(diào)用系統(tǒng)命令。這里特別想強(qiáng)調(diào)很多人在分析漏洞時(shí)只看最后一步的命令執(zhí)行覺得那是核心其實(shí)漏洞成立的前提是前面的訪問控制失效。我們做修復(fù)時(shí)網(wǎng)絡(luò)層面收口、開啟鑒權(quán)、升級(jí)版本每一步都是在切斷攻擊鏈路中的某一環(huán)。如果只升級(jí)不收斂網(wǎng)絡(luò)風(fēng)險(xiǎn)依然存在如果只封網(wǎng)絡(luò)不開鑒權(quán)內(nèi)部橫向風(fēng)險(xiǎn)依然存在。分層防護(hù)的價(jià)值就在這里。2.2 遠(yuǎn)程命令執(zhí)行的危害到底有多大說說“遠(yuǎn)程命令執(zhí)行”這六個(gè)字的真實(shí)含義。攻擊者一旦能在服務(wù)器上執(zhí)行任意命令接下來能做的事簡(jiǎn)直太多了讀取文件、創(chuàng)建賬號(hào)、安裝后門、下載惡意程序或者直接關(guān)閉安全服務(wù)。這些操作不需要多高深的技術(shù)只要權(quán)限允許順手就能做?？紤]到 Nacos 進(jìn)程的運(yùn)行身份如果部署時(shí)用的是 root 或高權(quán)限賬號(hào)那攻擊者拿到的就是 root 權(quán)限整臺(tái)服務(wù)器就徹底淪陷了。就算不是 root攻擊者也能以 Nacos 運(yùn)行用戶的身份讀取配置數(shù)據(jù)、篡改服務(wù)注冊(cè)信息進(jìn)而影響業(yè)務(wù)系統(tǒng)。另一個(gè)容易被忽略的點(diǎn)是內(nèi)網(wǎng)橫向移動(dòng)。很多時(shí)候攻擊者并不是沖著 Nacos 本身來的而是把 Nacos 當(dāng)跳板先拿下一臺(tái)主機(jī)再通過內(nèi)網(wǎng)訪問其他系統(tǒng)。Nacos 這類基礎(chǔ)組件往往部署在網(wǎng)絡(luò)的核心位置周圍連著大量業(yè)務(wù)服務(wù)一旦被突破后面就是一馬平川。所以這類漏洞的影響范圍絕對(duì)不能按一臺(tái)機(jī)器來評(píng)估。2.3 哪些部署形態(tài)最危險(xiǎn)結(jié)合行業(yè)里常見的部署方式和這次漏洞的觸發(fā)條件我把風(fēng)險(xiǎn)等級(jí)分成三類大家可以對(duì)照自查。部署場(chǎng)景風(fēng)險(xiǎn)等級(jí)說明單機(jī)內(nèi)嵌 Derby未開啟鑒權(quán)可公網(wǎng)訪問高攻擊者不需要任何憑據(jù)入口直接暴露單機(jī)內(nèi)嵌 Derby僅內(nèi)網(wǎng)訪問但鑒權(quán)弱或使用默認(rèn)密鑰中外部攻擊難度高但內(nèi)網(wǎng)失陷后橫向移動(dòng)容易集群部署使用外部數(shù)據(jù)庫(kù)已嚴(yán)格鑒權(quán)網(wǎng)絡(luò)有白名單低攻擊面小但還要確認(rèn)接口是否仍然開放這不是一個(gè)絕對(duì)的標(biāo)準(zhǔn)只是基于常見情況的判斷。不同版本、不同配置下實(shí)際暴露面會(huì)有差異。我想表達(dá)的是不要因?yàn)樽约骸霸诠緝?nèi)網(wǎng)”就覺得萬(wàn)事大吉。內(nèi)網(wǎng)橫向滲透是攻擊者的慣用手段一臺(tái)員工電腦被釣魚、一臺(tái)測(cè)試服務(wù)器被攻破都可能成為通向 Nacos 的跳板。3. 自查與排查先判斷自己有沒有踩中3.1 快速確認(rèn)版本和部署模式排查的第一步是搞清楚兩件事Nacos 是什么版本以及存儲(chǔ)模式是不是內(nèi)嵌 Derby。版本信息可以從幾個(gè)地方看部署目錄下的pom.xml、conf/application.properties、啟動(dòng)日志里的版本行或者登錄控制臺(tái)后底部顯示的版本號(hào)。如果是在發(fā)布平臺(tái)部署的看發(fā)布記錄也行。拿到版本號(hào)以后對(duì)照官方安全公告確認(rèn)是否在受影響范圍內(nèi)。存儲(chǔ)模式也要確認(rèn)。在conf/application.properties里找到配置數(shù)據(jù)源相關(guān)的內(nèi)容如果沒有配置db.url、db.user等外部數(shù)據(jù)庫(kù)參數(shù)大概率就是單機(jī)內(nèi)嵌 Derby 模式。如果配置了外部數(shù)據(jù)庫(kù)連接說明存儲(chǔ)已經(jīng)切換但還要看 Derby 相關(guān)接口是否依然對(duì)外開放。這一步很快但不要靠記憶判斷我見過不少團(tuán)隊(duì)負(fù)責(zé)人說“我們用的是 MySQL”結(jié)果一查MySQL 只是用了某個(gè)業(yè)務(wù)模塊Nacos 本身還是 Derby。3.2 觀察網(wǎng)絡(luò)暴露和訪問日志確認(rèn)了版本和部署模式以后再看網(wǎng)絡(luò)暴露面。登錄服務(wù)器檢查 Nacos 進(jìn)程監(jiān)聽的地址和端口。如果監(jiān)聽地址是0.0.0.0:8848說明所有網(wǎng)卡都能訪問能否從公網(wǎng)訪問還要看云安全組和防火墻規(guī)則。如果綁定的是內(nèi)網(wǎng)地址相對(duì)好一些但要繼續(xù)確認(rèn)防火墻是否只對(duì)可信來源放行。接著看訪問日志。Nacos 的日志目錄通常會(huì)有訪問日志和nacos.log檢索一些可疑特征比如包含derby、exec、shell、syscs等關(guān)鍵字的請(qǐng)求。如果發(fā)現(xiàn)來自非業(yè)務(wù)網(wǎng)段的 IP 頻繁訪問管理端口或者請(qǐng)求頻率明顯異常就要立刻警惕。注意在沒有確認(rèn)日志完整性的情況下不要指望日志里一定有攻擊痕跡。日志被清理、日志級(jí)別沒開全都是常見問題。日志排查是輔助手段不是唯一依據(jù)。3.3 判斷有沒有可能已經(jīng)被攻擊這里想提醒所有準(zhǔn)備“直接打補(bǔ)丁”的同學(xué)如果主機(jī)已經(jīng)失陷光升級(jí)版本相當(dāng)于給房子換了把新鎖小偷可能還在屋里。應(yīng)急之前先快速判斷有沒有被入侵的痕跡主要包括幾個(gè)方面。第一檢查最近被修改的可疑文件重點(diǎn)看/tmp、/var/tmp、Nacos 目錄下有沒有來歷不明的腳本、壓縮包、二進(jìn)制文件。第二看系統(tǒng)計(jì)劃任務(wù)有沒有新增條目很多后門是通過定時(shí)任務(wù)維持的。第三檢查進(jìn)程列表看有沒有不認(rèn)識(shí)的 Java 進(jìn)程、搶占 CPU 的挖礦程序、連接外部 IP 的可疑進(jìn)程。第四看系統(tǒng)用戶列表和登錄記錄有沒有新增的陌生賬號(hào)有沒有凌晨時(shí)段的異常登錄。上面這些檢查不需要復(fù)雜工具用幾條命令就能完成。如果發(fā)現(xiàn)異常不要猶豫先把主機(jī)從網(wǎng)絡(luò)上隔離保留現(xiàn)場(chǎng)證據(jù)再進(jìn)入應(yīng)急響應(yīng)流程。安全問題的處置順序很重要先止損再排查最后修復(fù)。4. 修復(fù)與加固從應(yīng)急到常態(tài)化4.1 首要?jiǎng)幼魃?jí)到修復(fù)版本針對(duì)這個(gè)漏洞最徹底的修復(fù)方式還是升級(jí)到包含修復(fù)的 Nacos 版本。升級(jí)時(shí)不要只看版本號(hào)“比較新”而要對(duì)照官方安全公告確認(rèn)該版本確實(shí)修復(fù)了 Derby 相關(guān)的命令執(zhí)行問題。升級(jí)前一定要做配置備份尤其是application.properties和外部數(shù)據(jù)源配置。升級(jí)后先在測(cè)試環(huán)境驗(yàn)證配置推送、服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)這些核心功能再推向生產(chǎn)。Nacos 這類組件一旦升級(jí)出問題影響的是所有依賴它的服務(wù)所以不要圖快按變更流程走。如果暫時(shí)無法升級(jí)可以先把相關(guān)管理接口臨時(shí)禁用比如通過防火墻規(guī)則或反向代理屏蔽可疑路徑作為臨時(shí)緩解措施。但臨時(shí)緩解一定要設(shè)定到期時(shí)間問題拖久了就會(huì)變成常態(tài)這是運(yùn)維上最常見的坑。4.2 網(wǎng)絡(luò)層收斂別讓 Nacos 裸奔無論是否升級(jí)網(wǎng)絡(luò)層面的收斂都建議馬上做。Nacos 是給內(nèi)部服務(wù)用的組件正常情況下不需要對(duì)公網(wǎng)開放。在云安全組和防火墻上把源 IP 限制到運(yùn)維網(wǎng)段、辦公網(wǎng)網(wǎng)段或需要拉取配置的服務(wù)網(wǎng)段其他來源一律拒絕。同時(shí)檢查 Nacos 進(jìn)程的實(shí)際監(jiān)聽地址如果綁定的還是0.0.0.0試著改為具體內(nèi)網(wǎng) IP。這里要提醒一點(diǎn)修改監(jiān)聽地址后要確認(rèn)服務(wù)消費(fèi)者還能正常連接。因?yàn)橛行┛缇W(wǎng)段的服務(wù)如果走公網(wǎng)或特殊路由改了綁定地址可能導(dǎo)致大面積連接失敗。建議在測(cè)試環(huán)境先驗(yàn)證再在生產(chǎn)執(zhí)行。很多漏洞攻擊得手不是攻擊手法多高明而是管理端口真的裸奔在公網(wǎng)上。把網(wǎng)絡(luò)入口收住攻擊者連敲門的機(jī)會(huì)都沒有這是性價(jià)比最高的安全措施。4.3 開啟認(rèn)證與修改默認(rèn)密鑰升級(jí)和封網(wǎng)之后還有一個(gè)容易遺留的問題鑒權(quán)配置。Nacos 支持開啟認(rèn)證但不少團(tuán)隊(duì)因?yàn)闅v史原因一直沒開或者開了認(rèn)證卻沿用默認(rèn)密鑰這樣的鑒權(quán)形同虛設(shè)。開啟認(rèn)證時(shí)需要設(shè)置一個(gè)足夠復(fù)雜的隨機(jī)密鑰并且妥善保存不要提交到 Git 倉(cāng)庫(kù)不要寫在部署文檔里。同時(shí)修改默認(rèn)管理員密碼改成強(qiáng)密碼并且定期輪換。更高安全等級(jí)的環(huán)境可以考慮接入統(tǒng)一的認(rèn)證系統(tǒng)用公司現(xiàn)有的賬戶體系做登錄認(rèn)證。配置完成后實(shí)際測(cè)試一下未登錄狀態(tài)是否真的無法訪問管理接口不要只看配置文件里寫著enabledtrue就覺得萬(wàn)無一失。安全配置以實(shí)際驗(yàn)證結(jié)果為準(zhǔn)不以配置文件為準(zhǔn)。4.4 審計(jì)與監(jiān)控盡量在攻擊過程早期發(fā)現(xiàn)安全加固做得再好也不能保證百分百不被突破所以監(jiān)控和審計(jì)不能少。至少要覆蓋三個(gè)層面。第一Nacos 訪問日志要留存管理端口的登錄嘗試、配置變更記錄、接口調(diào)用記錄至少保留 90 天以上具體留存周期按公司合規(guī)要求來。第二對(duì)異常行為設(shè)置告警比如短期內(nèi)大量登錄失敗、陌生 IP 訪問管理端口、配置批量變更、Nacos 進(jìn)程啟動(dòng)可疑子進(jìn)程等。第三在主機(jī)側(cè)部署安全 Agent 或文件完整性監(jiān)控重點(diǎn)盯 Nacos 安裝目錄、配置文件、臨時(shí)目錄的變化。監(jiān)控的意義在于即使攻擊者真的突破了第一道防線安全團(tuán)隊(duì)也能在較早階段發(fā)現(xiàn)并處置避免攻擊者在內(nèi)網(wǎng)里慢慢打洞、擴(kuò)大戰(zhàn)果。我見過不少安全事件明明日志里九天前就有異常登錄但因?yàn)闆]人監(jiān)控直到數(shù)據(jù)被加密勒索才發(fā)現(xiàn)。監(jiān)控不是成本是保險(xiǎn)。5. 實(shí)操總結(jié)我的排查經(jīng)驗(yàn)與踩坑清單5.1 三個(gè)容易被忽略的坑第一個(gè)坑是以為內(nèi)嵌數(shù)據(jù)庫(kù)沒有獨(dú)立端口就安全。Derby 確實(shí)沒有獨(dú)立監(jiān)聽端口但它的操作入口在 Nacos 的 HTTP 接口上端口不獨(dú)立不等于接口不暴露。很多團(tuán)隊(duì)在應(yīng)急時(shí)只檢查了 8848 端口是否對(duì)外開放卻忽略了那些和 Derby 操作相關(guān)的管理接口排查范圍一開始就窄了。第二個(gè)坑是升級(jí)后配置丟失或服務(wù)注冊(cè)異常。我遇到過不止一次升級(jí)時(shí)圖省事直接拷貝舊版的application.properties覆蓋到新版本目錄結(jié)果舊配置里既有外部數(shù)據(jù)庫(kù)連接又殘留了 Derby 相關(guān)配置啟動(dòng)后行為變得很奇怪。正確的做法是升級(jí)前 diff 配置逐個(gè)參數(shù)核對(duì)保留該保留的去掉該去掉的不要無腦覆蓋。第三個(gè)坑是只給 Nacos 打了補(bǔ)丁沒有盤點(diǎn)相關(guān)組件版本。Nacos 使用的客戶端、內(nèi)置的依賴庫(kù)也可能存在其他已知漏洞。建議建一個(gè)資產(chǎn)臺(tái)賬把 Nacos 服務(wù)端、客戶端、運(yùn)維腳本、依賴組件全部登記在冊(cè)定期對(duì)照漏洞情報(bào)排期修復(fù)。單點(diǎn)修復(fù)只是頭痛醫(yī)頭系統(tǒng)性地治理才能避免下次再被同一個(gè)問題絆倒。5.2 一份可直接執(zhí)行的排查命令清單下面這份命令清單是我在實(shí)際排查時(shí)常用的適合在沒有專業(yè)掃描平臺(tái)的情況下快速摸底。# 查看 Nacos 進(jìn)程信息 ps -ef | grep nacos # 查看 8848 端口監(jiān)聽地址和對(duì)應(yīng)進(jìn)程 ss -lntp | grep 8848 # 查看系統(tǒng)最近登錄記錄 last -n 20 # 查看是否有可疑新增用戶 grep -E nacos|admin|test /etc/passwd # 查看近期計(jì)劃任務(wù) crontab -l crontab -u root -l # 檢查臨時(shí)目錄下的可疑文件 find /tmp /var/tmp -name *.sh -mtime -7 2/dev/null # 搜索 Nacos 日志中的可疑關(guān)鍵字 grep -iE derby|syscs_util|exec|shell|runtime /data/nacos/logs/nacos.log | tail注意這些命令只是輔助排查不能覆蓋所有攻擊痕跡。如果公司有條件建議直接把 Nacos 主機(jī)接入漏洞掃描平臺(tái)和安全審計(jì)系統(tǒng)做一次針對(duì)性的安全檢查。5.3 一個(gè)典型的處置案例某公司安全團(tuán)隊(duì)收到告警說配置中心存在高危漏洞。我協(xié)助排查時(shí)先通過堡壘機(jī)登錄 Nacos 服務(wù)器查看版本確實(shí)在受影響范圍。接著檢查安全組規(guī)則發(fā)現(xiàn)管理端口對(duì)所有內(nèi)網(wǎng) IP 開放雖然還沒發(fā)現(xiàn)公網(wǎng)攻擊但內(nèi)網(wǎng)橫向移動(dòng)風(fēng)險(xiǎn)非常高。當(dāng)天先做了隔離在防火墻加白名單只允許運(yùn)維網(wǎng)段的幾臺(tái)機(jī)器訪問 Nacos。隨后安排升級(jí)版本升級(jí)前備份了application.properties升級(jí)后驗(yàn)證配置推送和服務(wù)注冊(cè)都正常同時(shí)修改了管理員密碼。整個(gè)過程大概花了一個(gè)下午。復(fù)盤時(shí)我們發(fā)現(xiàn)這臺(tái) Nacos 已經(jīng)上線兩年多中間多次提示版本過舊但一直因?yàn)椤熬€上穩(wěn)定不敢動(dòng)”被推遲升級(jí)。這次事件以后團(tuán)隊(duì)才真正把基礎(chǔ)組件的版本維護(hù)提上日程。這個(gè)案例給我的感觸很深技術(shù)漏洞往往不是最可怕的可怕的是長(zhǎng)期無人維護(hù)帶來的“歷史欠賬”。我個(gè)人在處理這類漏洞時(shí)體會(huì)最深的一點(diǎn)是不要只盯著“打補(bǔ)丁”這一步。先把資產(chǎn)摸清楚再按“網(wǎng)絡(luò)收斂、開啟鑒權(quán)、升級(jí)版本、持續(xù)監(jiān)控”這個(gè)順序推進(jìn)。基礎(chǔ)安全配置到位的情況下哪怕漏洞通告晚看到幾天被利用的概率也會(huì)低很多。希望這篇關(guān)于 Nacos Derby 遠(yuǎn)程命令執(zhí)行漏洞的文章能幫你先把應(yīng)急方向理清楚少走一些彎路。