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