Redis常規(guī)安全模式

Redis 被設計成僅有可信環(huán)境下的可信用戶才可以訪問。這意味著將 Redis 實例直接暴露在網(wǎng)絡上或者讓不可信用戶可以直接訪問 Redi s的 tcp 端口或 Unix 套接字，是不安全的。 

正常情況下，使用Redis的web應用程序是將Redis作為數(shù)據(jù)庫，緩存，消息系統(tǒng)，網(wǎng)站的前端用戶將會查詢Redis來生成頁面，或者執(zhí)行所請求的操作，或者被web應用程序用戶所觸發(fā)。這種情況下，web應用程序需要對不可信的用戶(訪問web應用程序的用戶瀏覽器)訪問Redis進行處理。這是個特殊的例子，但是，正常情況下，對 Redis 的非法訪問需要通過實現(xiàn) ACLs，驗證用戶輸入和決定 Redis 實例上可以執(zhí)行哪些操作這些方式來控制。

[[270298]]

總而言之，Redis 并沒有極力去優(yōu)化安全方面，而是盡可能去優(yōu)化高性能和易用性。

網(wǎng)絡安全

僅有可信的網(wǎng)絡用戶才可以訪問 Redis 的端口，因此運行 Redis 的服務器應該只能被用 Redis 實現(xiàn)的應用程序的計算機直接訪問。

一般情況下一臺直接暴露在 Internet 的計算機，例如一個虛擬化 Linux 實例(Linode, EC2,…)，防火墻應該防止外部用戶訪問它的redis端口。用戶仍可以通過本地接口來訪問 Redis。

記住在redis.conf 文件中增加下面這一行配置就可以把 Redis 綁定在單個接口上。

bind 127.0.0.1 

不禁止外部訪問 Redis 的話，將會產(chǎn)生非常嚴重的后果。比如，一個 FLUSHALL 操作就可以當做外部攻擊來刪除 Redis 上的所有數(shù)據(jù)。

認證的特性

雖然 Redis 沒有嘗試去實現(xiàn)訪問控制，但是提供了一個輕量級的認證方式，可以編輯redis.conf 文件來啟用。當認證授權(quán)方式啟用后，Redis 將會拒絕來自沒有認證的用戶的任何查詢。一個客戶端可以通過發(fā)送 AUTH 命令并帶上密碼來給自己授權(quán)。

這個密碼由系統(tǒng)管理員在redis.conf 文件里面用明文設置，它需要足夠長以應對暴力攻擊，這樣子設置有以下兩個原因：

redis.conf 

但同時密碼控制也會影響到從庫復制，從庫必須在配置文件里使用masterauth 指令配置相應的密碼才可以進行復制操作。

masterauth yoursecurepasswordhereplease 

認證層的目標是提供多一層的保護。假如防火墻或者其它任何系統(tǒng)防護攻擊失敗的話，外部客戶端如果沒有認證密碼的話將依然無法訪問 Redis 實例。AUTH 命令就像其它Redis命令一樣，是通過非加密方式發(fā)送的，因此無法防止擁有足夠的訪問網(wǎng)絡權(quán)限的攻擊者進行竊聽。

數(shù)據(jù)加密支持

Redis并不支持加密。為了實現(xiàn)在網(wǎng)絡上或者其它非可信網(wǎng)絡訪問 Redis 實例，需要實現(xiàn)新增的保護層，例如 SSL 代理。

官方推薦的SSL 代理：spiped

禁用的特殊命令

在 Redis 中可以禁用命令或者將它們重命名成難以推測的名稱，這樣子普通用戶就只能使用部分命令了。例如，一個虛擬化的服務器提供商可能提供管理Redis實例的服務。在這種情況下，普通用戶可能不被允許調(diào)用 CONFIG 命令去修改實例的配置，但是能夠提供刪除實例的系統(tǒng)需要支持修改配置。

在這種情況下，你可以從命令表中重命名命令或者禁用命令。這個特性可以在redis.conf 文件中進行配置。例如：

rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52 

在上面這個例子中，CONFIG 命令被重命名成一個不好猜測的名稱。把命令重命名成一個空字符串可以禁用掉該命令，例如下面這個例子：

rename-command CONFIG "" 

外部客戶端通過仔細構(gòu)造的輸入觸發(fā)的攻擊

即便沒有外部訪問權(quán)限，也有種攻擊可以讓攻擊者從外部觸發(fā)。例如一些攻擊者有能力向 Redis 中插入數(shù)據(jù)，觸發(fā) Redis 內(nèi)部數(shù)據(jù)結(jié)構(gòu)中最差的算法復雜度，例如一個攻擊者可以通過提交表單提交大量一樣的字符串到哈希表里，使得 O(1) 的算法復雜度(平均時間)達到最差的O(N) ，Redis 將需要更多的CPU來處理，到最后會導致無法提供服務為了防范這類特殊的攻擊，Redis 的哈希函數(shù)使用per-excution 的偽隨機種子。 

Redis 用qsort 算法來實現(xiàn) SORT 命令。當前這個算法還不算隨機的，所以通過有意構(gòu)造輸入可能引發(fā)最糟糕情況的算法復雜度。

字符串轉(zhuǎn)義和NoSQL注入

Redis 的協(xié)議沒有字符串轉(zhuǎn)移的概念，因此一般情況下普通客戶端無法實現(xiàn)注入的。該協(xié)議采用二進制安全的前綴長度字符串。通過 EVAL 和 EVALSHA 命令運行 Lua 腳本也是安全的。雖然這是個很奇怪的用法，應用程序應避免使用不明來源的字符串來寫Lua 腳本。

代碼安全

在傳統(tǒng)架構(gòu)的 Redis 中，客戶端是可以使用全部命令的，但是訪問 Redis 實例時是沒有能力控制運行著 Redis 的系統(tǒng)的。本質(zhì)上，Redis 使用好的編程方法來寫安全的代碼，防止出現(xiàn)緩存溢出，格式錯誤和其他內(nèi)存損壞問題。但是，使用 CONFIG 命令修改服務器配置的能力使得用戶可以改變程序的工作目錄和備份文件的名字。這讓用戶可以將 RDB 文件寫在任意路徑，這個安全問題容易引起不受信任的代碼在 Redis 上運行。

Redis 不需要 root 權(quán)限來運行，建議使用僅能運行 Redis 的用戶運行。Redis 的作者正在調(diào)查給 Redis 增加一個新參數(shù)來防止 CONFIG SET/GET dir 和其它命令運行時配置指令的可能。這可以防止客戶端強制要求服務器在任意位置寫文件。