在安全評估和應(yīng)急響應(yīng)工作中我最常遇到的現(xiàn)象往往不是某個神秘的0day漏洞而是 Redis 未授權(quán)訪問。很多團隊把 Redis 當(dāng)成單純的緩存中間件覺得它藏在內(nèi)網(wǎng)就是安全的結(jié)果一不留神6379 端口就直接成了攻擊者進入內(nèi)網(wǎng)的“免費門票”。而“Redis提權(quán)”這個詞在紅藍對抗里出現(xiàn)的頻率也越來越高——攻擊者未必需要多高深的技術(shù)只要 Redis 配置稍有松懈就能拿下一臺主機的高權(quán)限再以此作為跳板在內(nèi)網(wǎng)橫向滲透。今天我從防守方的視角出發(fā)把 Redis 提權(quán)的原理、攻擊鏈、檢測方法和加固方案完整拆解一遍。這篇內(nèi)容適合安全工程師、運維同學(xué)也適合做開發(fā)但想了解中間件安全的讀者哪怕你之前完全沒接觸過 Redis也能通過這篇文章看懂它為什么總是“翻車”。1. 為什么 Redis 會成為內(nèi)網(wǎng)提權(quán)的“跳板”1.1 Redis 在內(nèi)網(wǎng)部署太常見暴露面天然就大Redis 本身是一款高性能的鍵值存儲數(shù)據(jù)庫因為讀寫速度快、語義簡單被大量用來做緩存、分布式鎖、排行榜、會話存儲等場景。幾乎每個中大規(guī)模系統(tǒng)的技術(shù)棧里都會出現(xiàn) Redis 的身影而且數(shù)量往往不止一臺業(yè)務(wù)緩存一主多從、集群架構(gòu)幾十個節(jié)點、環(huán)境上還要分 dev、test、prod加起來就是一筆不小的資產(chǎn)。對于攻擊者來說Redis 的“價值”在于它的身份很特殊它通常運行在高權(quán)限用戶下而且默認(rèn)配置并不強制開啟密碼認(rèn)證。很多公司為了管理方便直接把 Redis 部署在 Web/應(yīng)用服務(wù)器上或者用同一個賬號跑多個服務(wù)。這樣一來一旦 Redis 被攻破攻擊者拿到的可能不只是一個數(shù)據(jù)庫控制權(quán)而是整臺服務(wù)器的高權(quán)限執(zhí)行入口。這也是“Redis提權(quán)”這個說法在安全圈里流傳度越來越高的根本原因。1.2 “提權(quán)”的本質(zhì)是權(quán)限邊界被突破先明確一個概念Redis 本身不是一個漏洞軟件它不會主動去攻擊別人。但攻擊者利用 Redis 的配置缺陷、功能特性和運行權(quán)限把自己從“只能操作數(shù)據(jù)庫”提升到“能在操作系統(tǒng)里執(zhí)行命令”這個過程就是提權(quán)。換句話說Redis 的很多功能在正常情況下是為了方便開發(fā)比如持久化到磁盤、加載模塊、復(fù)制數(shù)據(jù)等可一旦落入攻擊者手里這些“正常功能”就全變成了攻擊工具。最核心的一點是Redis 是以操作系統(tǒng)的某個用戶身份運行的而這個用戶往往擁有高權(quán)限。如果 Redis 以 root 啟動攻擊者通過 Redis 獲得代碼執(zhí)行能力后天然就是 root 權(quán)限根本不需要再費勁去提權(quán)。如果 Redis 以 redis 用戶運行攻擊者有了代碼執(zhí)行權(quán)限后還需要借助內(nèi)核漏洞、SUID 文件、sudo 配置錯誤等方式把權(quán)限升到 root。所以我們說的“Redis提權(quán)”實際是兩層含義一層是 Redis 到操作系統(tǒng)命令執(zhí)行的“橫跳”另一層是操作系統(tǒng)普通權(quán)限到 root/system 權(quán)限的“爬升”。1.3 默認(rèn)配置和安全習(xí)慣的雙重缺失Redis 之所以成為內(nèi)網(wǎng)提權(quán)的重災(zāi)區(qū)很大程度上要“歸功”于幾個慣性操作Redis 安裝后bind默認(rèn)可能是 127.0.0.1有人為了局域網(wǎng)訪問改成0.0.0.0或內(nèi)網(wǎng)網(wǎng)段但忘了加防火墻限制。requirepass始終不設(shè)置認(rèn)為內(nèi)網(wǎng)不可信這句老話恰恰就是最大的漏洞來源。protected-mode被改成no或者配置順序有誤導(dǎo)致保護模式?jīng)]生效。運維為了方便直接用 root 用戶啟動 Redis 進程還理直氣壯地說“沒人能連上來”。這些配置單獨看都不致命但疊在一起后Redis 就像一個開著門、站在內(nèi)網(wǎng)廣場上的保險庫誰路過都能翻兩下。而“內(nèi)網(wǎng)提權(quán)”這個場景里Redis 往往是攻擊者發(fā)的第一張牌也是最容易打出的那張牌。2. Redis 未授權(quán)訪問的利用原理與攻擊鏈2.1 未授權(quán)訪問是怎么產(chǎn)生的未授權(quán)訪問簡單說就是任何人都可以連上 Redis 并執(zhí)行命令無需密碼。正常情況下Redis 提供了兩種基本認(rèn)證方式一是通過requirepass設(shè)置管理員密碼二是通過protected-mode限制外部訪問。只要開了其中一個且配置正確攻擊者就不能輕易得手。問題出在Redis 的某些配置需要重啟才能生效而有些命令可以動態(tài)修改。比如攻擊者連上 Redis 后執(zhí)行CONFIG GET requirepass一看是空值就知道可以直接操作了。更麻煩的是Redis 默認(rèn)有CONFIG SET命令允許運行時修改運行參數(shù)這就給攻擊者提供了很大的操作空間。我見過不少實際案例Redis 進程在 root 下運行綁定了內(nèi)網(wǎng) IP并且沒有密碼結(jié)果攻擊者掃描內(nèi)網(wǎng)時發(fā)現(xiàn) 6379端口開放直接從數(shù)據(jù)庫一路打到了主機權(quán)限。整個過程不到五分鐘甚至沒有使用任何公開的漏洞。2.2 四種常見的 Redis 提權(quán)利用方式原理與排查思路站在防守方角度我們需要知道攻擊者通常會走哪幾條路才能去檢查和保護。這里梳理四種最常見的利用方式不涉及具體攻擊載荷只講原理和痕跡特征。方式一利用dir和dbfilename寫文件Redis 持久化默認(rèn)會把數(shù)據(jù)保存到磁盤上的 RDB 文件路徑由dir和dbfilename兩個配置項決定。攻擊者會先把dir切換到目標(biāo)目錄比如 Web 服務(wù)的根目錄或臨時目錄然后把包含惡意內(nèi)容的鍵值寫入 Redis最后執(zhí)行SAVE或BGSAVE觸發(fā)持久化惡意內(nèi)容就被寫進文件。如果寫在 Web 目錄下就可能形成一個 WebShell如果寫進了用戶的 SSH 目錄就可能變成授權(quán)后的公鑰文件如果寫進計劃任務(wù)目錄就可能形成定時執(zhí)行的后門。這個手法的核心在于Redis 進程對目標(biāo)目錄有寫權(quán)限同時攻擊者知道目錄的絕對路徑。方式二寫入 SSH 公鑰實現(xiàn)免密登錄很多 Linux 服務(wù)器開啟了 SSH 服務(wù)允許 root 遠程登錄。如果 Redis 進程權(quán)限足夠高例如 root攻擊者可以在 Redis 中構(gòu)造一條 SSH 公鑰內(nèi)容通過dir和dbfilename把它寫到/root/.ssh/authorized_keys文件里然后直接使用對應(yīng)的私鑰登錄服務(wù)器。這種方式的標(biāo)志性排查點非常明顯/root/.ssh/authorized_keys文件里多了一條不認(rèn)識的公鑰或者文件權(quán)限和屬主變得異常。但在攻防演練中很多防守方并不會去主動檢查這個目錄等到攻擊者已經(jīng)通過 SSH 登錄已經(jīng)太晚了。方式三寫計劃任務(wù)實現(xiàn)命令執(zhí)行對于運行 Linux 的系統(tǒng)攻擊者會嘗試把惡意命令寫進 crontab 目錄比如/var/spool/cron/root或/etc/cron.d/然后定時執(zhí)行。這樣即使在當(dāng)前會話斷開后攻擊者依然能周期性獲得權(quán)限。在 CentOS 等系統(tǒng)中cron 服務(wù)讀取文件時的格式要求和權(quán)限檢查相對寬松因此這種利用方式很常見。防守方要留意/var/spool/cron/下有沒有異常用戶文件以及/etc/cron.d/里有沒有剛剛生成的可疑腳本。方式四主從復(fù)制加載惡意模塊Redis 4.0 引入模塊機制允許神器加載 .so 文件擴展功能。攻擊者可以搭建一個自己的 Redis 實例作為主節(jié)點然后讓目標(biāo) Redis 通過REPLICAOF命令成為自己的從節(jié)點再向主節(jié)點請求加載惡意模塊最終在目標(biāo)系統(tǒng)上實現(xiàn)代碼執(zhí)行。這種方式在 Redis 4.x/5.x 版本中都比較有效而且攻擊鏈更隱蔽因為直接寫文件的方式各有約束而模塊加載可以繞過很多規(guī)則。防守方需要檢查 Redis 日志中是否出現(xiàn)異常的MODULE LOAD或REPLICAOF操作并監(jiān)控 Redis 進程加載的模塊文件。2.3 攻擊鏈的整體視圖把上面幾種利用方式串起來看典型的 Redis 提權(quán)攻擊鏈一般是探測內(nèi)網(wǎng)中未授權(quán)訪問的 Redis 實例常見于掃描 6379 端口。連接 Redis執(zhí)行INFO、CONFIG GET dir、CONFIG GET requirepass等命令探清環(huán)境和權(quán)限。根據(jù) Redis 進程權(quán)限、系統(tǒng)類型、目錄可行性選擇一種或多種利用方式。獲得命令執(zhí)行或文件寫入能力隨后將權(quán)限提升到 root/system。植入持久化后門并以內(nèi)網(wǎng)掃描、密碼抓取、代理轉(zhuǎn)發(fā)等方式進行橫向移動。這個鏈條每一環(huán)都有對應(yīng)的檢測點防守方只要能在其中一環(huán)攔截住就能有效降低風(fēng)險。比如及時升級版本、配置強密碼、限制命令、監(jiān)控持久化文件都會讓攻擊者無路可走。3. 內(nèi)網(wǎng)場景下的提權(quán)路徑與聯(lián)動利用3.1 從 Redis 到主機權(quán)限中間發(fā)生了什么在實際內(nèi)網(wǎng)滲透中攻擊者拿到 Redis 后會先驗證自己能做什么。最基礎(chǔ)的他們可以讀CONFIG GET dir、CONFIG GET dbfilename、CONFIG GET logfile等了解當(dāng)前持久化文件在哪個目錄、Redis 日志在哪個路徑從而判斷 Redis 進程到底屬于哪個用戶、系統(tǒng)上是否存在 Web 服務(wù)、SSH 是否開啟等信息。權(quán)限判斷很關(guān)鍵如果dir指向/var/lib/redis并且文件屬主是 redis 用戶那說明 Redis 是低權(quán)限運行攻擊者寫文件的目標(biāo)就受限如果dir指向/root或/var/www/html且屬主是 root那說明 Redis 很可能以 root 運行攻擊者一旦獲得寫文件能力就相當(dāng)于直接拿到了 root 權(quán)限。這也是為什么“低權(quán)限運行 Redis”會在加固建議里被反復(fù)強調(diào)。3.2 內(nèi)網(wǎng)橫向移動的典型路徑Redis 提權(quán)成功之后攻擊者通常不會只待在這一臺機器上。內(nèi)網(wǎng)里往往有成百上千臺機器他們會把當(dāng)前主機當(dāng)作“根據(jù)地”然后開展橫向移動常見的手段包括掃描內(nèi)網(wǎng)存活 IP 和開放端口尋找更多未授權(quán) Redis、弱口令 SSH、開放數(shù)據(jù)庫等服務(wù)。抓取本機內(nèi)存中的密碼、瀏覽器或登錄工具中的保存口令、配置文件里的數(shù)據(jù)庫賬號嘗試復(fù)用口令。利用 Linux 系統(tǒng)的密碼 hash 或 SSH 密鑰跳到其他運維管理的機器。在內(nèi)網(wǎng)建立代理或端口轉(zhuǎn)發(fā)形成一條穩(wěn)定的隧道方便后續(xù)進出內(nèi)網(wǎng)。這些動作在沒有縱深防御的環(huán)境里很難被阻止。特別是 Redis 大量部署在測試環(huán)境和辦公網(wǎng)內(nèi)一旦一個開發(fā)測試機器被攻破攻擊者就能沿著開發(fā)運維鏈路摸到生產(chǎn)網(wǎng)絡(luò)。3.3 為什么說 Redis 是“內(nèi)網(wǎng)提權(quán)”的高頻入口內(nèi)網(wǎng)提權(quán)這個詞這些年越提越頻繁和攻擊者視角的轉(zhuǎn)變有很大關(guān)系。早期大家關(guān)注的焦點是 Web 漏洞、SQL 注入但隨著 Web 防護體系的增強攻擊者開始尋找邊界沒那么明顯的中間件和基礎(chǔ)組件。Redis 就是這樣一個組件它不像 Web 服務(wù)那樣暴露在公網(wǎng)也常常沒有 WAF 防火墻的保護但它一旦失守卻能直接提供內(nèi)網(wǎng)主機的入口。另外Redis 相關(guān)的攻擊手段大多不需要特別的工具依賴只要能通過 TCP 連接用 Redis 自己的命令就能完成大部分操作。這讓它在攻擊者眼里性價比極高。反過來作為防守方也必須對這類“低頻、高影響”的入口有足夠的感知力。4. 快速自查5 個命令定位 Redis 提權(quán)風(fēng)險與其等出事了再焦慮不如在日常巡檢里就把 Redis 的險情摸清楚。下面這 5 個檢查命令是我在安全評估中經(jīng)常用的不需要太多額外工具一條條跑下來基本能判斷當(dāng)前 Redis 是否處于高風(fēng)險狀態(tài)。檢查項命令示例判斷標(biāo)準(zhǔn)是否可未授權(quán)訪問redis-cli -h IP ping返回 PONG 說明服務(wù)端可連接且無需密碼認(rèn)證配置是否為空CONFIG GET requirepass返回空字符串即為高危監(jiān)聽地址是否過寬CONFIG GET bind若為0.0.0.0或內(nèi)網(wǎng)全段風(fēng)險升高保護模式是否開啟CONFIG GET protected-modeno或注釋掉都算高危進程權(quán)限是否過高ps -ef | grep redis-server進程用戶為 root 或 system 即為高危在實際檢查時還可以追加兩條查看關(guān)鍵目錄的命令確認(rèn)有沒有已經(jīng)被寫入惡意文件ls -la /root/.ssh/authorized_keys ls -la /var/spool/cron/如果一個 Redis 同時滿足不需要密碼、綁定所有地址、保護模式關(guān)閉、進程以 root 運行那基本可以斷定只要這臺機器在內(nèi)網(wǎng)可達攻擊者隨時可以提權(quán)到 root。這時候唯一的處理方式就是立刻切斷網(wǎng)絡(luò)訪問然后按下一節(jié)的加固方案執(zhí)行修復(fù)。5. 企業(yè)級加固方案讓 Redis 無“權(quán)”可利用5.1 配置層面把默認(rèn)的“隨意訪問”關(guān)緊最直接有效的做法是在 Redis 配置文件redis.conf中把認(rèn)證、監(jiān)聽和保護模式三件事一次性做好# 開啟保護模式 protected-mode yes # 僅監(jiān)聽需要的地址建議綁定回環(huán)或內(nèi)網(wǎng)專用網(wǎng)段 bind 127.0.0.1 192.168.10.10 # 設(shè)置強密碼不要用 admin/123456 這類弱口令 requirepass 你的強隨機密碼 # 關(guān)閉所有外部來源的危險命令 rename-command CONFIG 注意rename-command把 CONFIG 禁掉后雖然會影響運維人員動態(tài)調(diào)整配置但對很多內(nèi)部業(yè)務(wù)來說它并不是必須的。如果實在需要保留 CONFIG 命令建議僅允許某個特定受控網(wǎng)絡(luò)地址訪問并配置好密碼認(rèn)證。另外rename-command對已經(jīng)不在內(nèi)存中的配置項不生效需要在配置文件里改好之后再重啟 Redis才能徹底生效。5.2 系統(tǒng)層面弱化 Redis 進程的權(quán)限邊界配置只是第一步進程權(quán)限和文件系統(tǒng)權(quán)限才是關(guān)鍵。建議把 Redis 放到獨立的低權(quán)限用戶下運行比如創(chuàng)建一個專門用于 Redis 的redis用戶并把數(shù)據(jù)目錄、日志目錄、配置文件都設(shè)置為該用戶所有。這樣即使攻擊者利用了 Redis獲得的也只是普通用戶的執(zhí)行權(quán)限后續(xù)要提權(quán)到 root 還需要面對其他門檻。如果你使用 Docker 運行 Redis可以進一步使用只讀文件系統(tǒng)掛載、禁止特權(quán)模式、限制 Linux capabilities 等方式讓容器內(nèi)的 Redis 無法影響宿主機。容器雖不是安全隔離的銀彈但能顯著提高攻擊者利用成本。還需要注意一點即使 Redis 以 redis 用戶運行如果該用戶對 Web 目錄或 SSH 目錄有寫權(quán)限同樣可以被利用。所以還要檢查 Redis 用戶的目錄寫權(quán)限范圍盡量做到最小化授權(quán)。尤其不要把 Redis 的數(shù)據(jù)目錄直接指向/var/www/html或用戶家目錄。5.3 網(wǎng)絡(luò)層面讓 6379 不暴露給無關(guān)主機Redis 不應(yīng)該直接暴露在所有內(nèi)網(wǎng)主機可達的網(wǎng)段里。以下幾條是實踐過比較有效的網(wǎng)絡(luò)策略使用防火墻或安全組限制 6379 端口只能被訪問方 IP 訪問。比如業(yè)務(wù)應(yīng)用 IP、管理機 IP其它全部拒絕。如果業(yè)務(wù)上只需要本機訪問 Redis直接bind 127.0.0.1是最省心的方案其他人連 TCP 包都送不進來。不建議把 Redis 端口映射到公網(wǎng)。如果團隊有遠程開發(fā)需求走 SSH 隧道或堡壘機訪問即可。定期使用端口掃描工具檢查內(nèi)網(wǎng)是否存在異常開放的 6379/6380 端口及時發(fā)現(xiàn)裸奔服務(wù)。5.4 監(jiān)控層面發(fā)現(xiàn)可疑命令要立刻告警Redis 的命令日志通常默認(rèn)不開啟但為了安全最好打開。在配置里設(shè)置loglevel notice并讓日志采集工作收集 Redis 日志再針對幾個高危操作配置告警包括但不限于CONFIG SET dir/CONFIG SET dbfilenameSAVE/BGSAVE在非正常時間段執(zhí)行REPLICAOF或SLAVEOFMODULE LOAD密碼驗證失敗次數(shù)過多如果日志顯示有人在執(zhí)行這些命令大概率是在嘗試?yán)?Redis 提權(quán)。告警只是第一步還要有響應(yīng)流程例如及時斷開該 Redis 的網(wǎng)絡(luò)、備份日志、拉取當(dāng)前進程信息、檢查持久化文件是否被篡改等。安全加固永遠不是改一個配置就結(jié)束而是配置、監(jiān)控、響應(yīng)三者配合。5.5 版本升級別在舊版本上浪費時間Redis 官方持續(xù)修復(fù)安全漏洞比如著名的 Lua 沙盒繞過、模塊加載相關(guān)的代碼執(zhí)行漏洞等。老版本雖然在業(yè)務(wù)上穩(wěn)定但在攻擊者眼里內(nèi)置漏洞可能都是現(xiàn)成的武器。建議把生產(chǎn)環(huán)境的 Redis 升級到官方維護的最新穩(wěn)定版至少也要選擇仍處于安全維護期內(nèi)的版本。升級前要在測試環(huán)境做充分的兼容性驗證尤其是主從復(fù)制、持久化、連接池等核心場景。別把安全修復(fù)和業(yè)務(wù)穩(wěn)定性對立起來現(xiàn)代 Redis 的新版本在高性能方面并不遜色反而帶來了更好的安全特性和可觀測性。6. 常見問題與誤區(qū)排查6.1 設(shè)了 requirepass 就萬事大吉不少團隊初始的加固方案就是加一個密碼而且用的還是項目名年份這類簡單組合?？蓡栴}是內(nèi)網(wǎng)攻擊者如果已經(jīng)拿下一臺機器很可能通過抓包、讀取配置文件、翻歷史命令等方式拿到這個密碼。換句話說密碼只是第一道門檻不是唯一門檻。更穩(wěn)妥的做法是把密碼認(rèn)證、網(wǎng)絡(luò)限制、命令降權(quán)三者結(jié)合起來。另外Redis 的密碼也不是越復(fù)雜越好實用做法是生成一串隨機的長字符串集中保存在密鑰管理系統(tǒng)或配置中心里避免硬編碼在應(yīng)用配置中尤其是不能提交到 Git 倉庫。6.2 protected-mode 開啟后內(nèi)網(wǎng)還是暴露protected-mode yes不是萬金油。它的本質(zhì)是當(dāng) Redis 沒有配置密碼且沒有顯式綁定地址時只允許本機回環(huán)地址訪問。但如果運維已經(jīng)編譯了bind 192.168.x.x即使protected-mode yes從其它內(nèi)網(wǎng)主機依然可以連上來。因為保護模式主要作用于默認(rèn)綁定場景顯式綁定后保護模式的實際約束會弱化。所以你在 Redis 里看到protected-mode yes時別高興太早還要再確認(rèn)bind和requirepass兩個值。這三個配置項必須一起看才能判斷暴露面。6.3 把 CONFIG 命令禁掉就萬無一失了嗎對很多運維來說禁用CONFIG確實能擋住一大波利用手段比如修改dir和dbfilename的經(jīng)典寫 shell 方式。但要注意攻擊者如果拿到了 Redis 連接權(quán)限即使沒有CONFIG命令也可能利用MODULE LOAD、主從復(fù)制、Lua腳本等方式嘗試執(zhí)行代碼。所以rename-command只是補漏不能替代強密碼和低權(quán)限用戶。在實際評估中我會同時檢查 Redis 有沒有加載過異常的模塊文件有沒有成為某個可疑主節(jié)點的從機等。這些痕跡不會出現(xiàn)在 Web 日志里只有長期保留 Redis 日志才能追查到。6.4 Redis 被提權(quán)之后清理 RDB 文件就恢復(fù)了嗎很多應(yīng)急響應(yīng)的“常規(guī)操作”是刪掉 RDB 文件中殘留的惡意鍵值重啟 Redis覺得這樣攻擊者就進不來了。但現(xiàn)實是攻擊者一旦獲得過 root 權(quán)限可能在計劃任務(wù)、SSH 公鑰、系統(tǒng)服務(wù)、定時腳本等多個位置留下了后門甚至替換了系統(tǒng)命令。只清洗 Redis 相關(guān)的痕跡遠遠不夠。正確的應(yīng)急流程應(yīng)當(dāng)是先斷網(wǎng)隔離然后連同系統(tǒng)日志、Redis 日志、進程列表、網(wǎng)絡(luò)連接、文件系統(tǒng)時間戳一起取證排查確認(rèn)所有后門位置再從干凈備份恢復(fù)或重裝系統(tǒng)最后修改所有相關(guān)密碼和密鑰。Redis 本身的數(shù)據(jù)文件往往不是唯一受災(zāi)點。6.5 內(nèi)網(wǎng) Redis 數(shù)量太多如何做批量巡檢如果內(nèi)網(wǎng)設(shè)備數(shù)量比較大可以寫一個簡單的腳本批量探測常見 Redis 端口并對未授權(quán)訪問、綁定地址、requirepass 狀態(tài)、進程權(quán)限等字段進行掃描和匯總。腳本邏輯并不復(fù)雜用 Python 的 socket 庫就能實現(xiàn)import socket ip 目標(biāo)IP port 6379 s socket.socket() s.settimeout(3) try: s.connect((ip, port)) s.send(bPING\r\n) data s.recv(100) if bPONG in data: print(f{ip}:{port} Redis 未授權(quán)訪問) except Exception: pass finally: s.close()這只是最小驗證片段真正的批量巡檢還要結(jié)合 CONFIG GET 命令驗證 requirepass 等配置。建議把巡檢做成周期性任務(wù)并納入企業(yè)安全管理平臺由平臺統(tǒng)一展示風(fēng)險和派發(fā)工單這樣才能避免“巡檢一時爽過后沒人管”的情況。6.6 遇到疑似 Redis 提權(quán)攻擊該報警還是斷網(wǎng)第一時間應(yīng)該“斷網(wǎng)隔離”而不是“繼續(xù)觀察”。只要確認(rèn) Redis 存在未授權(quán)訪問最好的處理方式就是把該主機的網(wǎng)絡(luò)連接先斷掉再用只讀方式備份日志和數(shù)據(jù)避免攻擊者銷毀證據(jù)。等應(yīng)急人員介入后再根據(jù)取證結(jié)果判斷是否擴容攻擊路徑、是否已橫向滲透到其它主機。在實際攻防演練里我發(fā)現(xiàn)很多防守方會想先看攻擊者做了什么再決定怎么處置。但大部分情況下攻擊者保持連接的時間窗口非常短反應(yīng)慢半拍就可能導(dǎo)致整個內(nèi)網(wǎng)被翻個底朝天?？焖贁嗑W(wǎng)保留現(xiàn)場是可控且穩(wěn)妥的。寫在最后我在實際安全運營中有一個很深的體會Redis 安全問題絕大多數(shù)不是技術(shù)門檻造成的而是“配置基線”沒有立起來。只要把密碼認(rèn)證、地址綁定、保護模式、進程權(quán)限、高危命令禁用、日志告警這六件事做扎實絕大部分 Redis 提權(quán)嘗試都會被擋在第一步。日常運維中大家習(xí)慣把大量精力花在業(yè)務(wù)可用性上但安全加固往往只需要幾次版本發(fā)布就能順手完成。如果你負(fù)責(zé)的系統(tǒng)里正好有 Redis 服務(wù)建議今天就去檢查一下requirepass、bind和運行用戶也許一次小小的調(diào)整就能避免一次內(nèi)網(wǎng)失陷。