Redis安全性

本文檔從以下幾點提供了關于Redis安全主題的介紹：Redis提供的通路控制，代碼安全問題，通過外部的惡意輸入觸發的攻擊和其它類似的主題也包含在内。

Redis被設計成僅有可信環境下的可信使用者才可以通路。這意味着将Redis執行個體直接暴露在網絡上或者讓不可信使用者可以直接通路Redis的tcp端口或Unix套接字，是不安全的。

正常情況下，使用Redis的web應用程式是将Redis作為資料庫，緩存，消息系統，網站的前端使用者将會查詢Redis來生成頁面，或者執行所請求的操作，或者被web應用程式使用者所觸發。

這種情況下，web應用程式需要對不可信的使用者(通路web應用程式的使用者浏覽器)通路Redis進行處理。

這是個特殊的例子，但是，正常情況下，對Redis的非法通路需要通過實作ACLs，驗證使用者輸入和決定Redis執行個體上可以執行哪些操作這些方式來控制。

總而言之，Redis并沒有最大地去優化安全方面，而是盡最大可能去優化高性能和易用性。

僅有可信的網絡使用者才可以通路Redis的端口，是以運作Redis的伺服器應該隻能被用Redis實作的應用程式的計算機直接通路。

一般情況下一台直接暴露在Internet的計算機，例如一個虛拟化Linux執行個體(Linode, EC2,…)，防火牆應該防止外部使用者通路它的redis端口。使用者仍可以通過本地接口來通路Redis。

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

不禁止外部通路redis的話，将會産生非常嚴重的後果。比如，一個FLUSHALL操作就可以當做外部攻擊來删除Redis上的所有資料。

雖然Redis沒有嘗試去實作通路控制，但是提供了一個輕量級的認證方式，可以編輯redis.conf檔案來啟用。

當認證授權方式啟用後，Redis将會拒絕來自沒有認證的使用者的任何查詢。一個用戶端可以通過發送AUTH指令并帶上密碼來給自己授權。

這個密碼由系統管理者在redis.conf檔案裡面用明文設定，它需要足夠長以應對暴力攻擊，這樣子設定有以下兩個原因：

Redis的查詢速度非常快。外部使用者每秒可以嘗試非常多個密碼。

Redis的密碼存儲在redis.conf檔案中和存儲在用戶端的配置中，是以系統管理者沒必要去記住它，是以可以設定得非常長。

認證層的目标是提供多一層的保護。假如防火牆或者其它任何系統防護攻擊失敗的話，外部用戶端如果沒有認證密碼的話将依然無法通路Redis執行個體。

AUTH指令就像其它Redis指令一樣，是通過非加密方式發送的，是以無法防止擁有足夠的通路網絡權限的攻擊者進行竊聽。 資料加密支援

Redis并不支援加密。為了實作在網絡上或者其它非可信網絡通路Redis執行個體，需要實作新增的保護層，例如SSL代理。

在Redis中可以禁用指令或者将它們重命名成難以推測的名稱，這樣子普通使用者就隻能使用部分指令了。

例如，一個虛拟化的伺服器提供商可能提供管理Redis執行個體的服務。在這種情況下，普通使用者可能不被允許調用CONFIG指令去修改執行個體的配置，但是能夠提供删除執行個體的系統需要支援修改配置。

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

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

即便沒有外部通路權限，也有種攻擊可以讓攻擊者從外部觸發。例如一些攻擊者有能力向Redis中插入資料，觸發Redis内部資料結構中最差的算法複雜度，

例如一個攻擊者可以通過送出表單送出大量一樣的字元串到哈希表裡，使得 O(1) 的算法複雜度(平均時間)達到最差的O(N) ，Redis将需要更多的CPU來處理，到最後會導緻無法提供服務

為了防範這類特殊的攻擊，redis的哈希函數使用per-excution的僞随機種子。

Redis用qsort算法來實作SORT指令。目前這個算法還不算随機的，是以通過有意構造輸入可能引發最糟糕情況的算法複雜度。

Redis的協定沒有字元串轉移的概念，是以一般情況下普通用戶端無法實作注入的。該協定采用二進制安全的字首長度字元串。

通過EVAL和EVALSHA指令運作Lua腳本也是安全的。

雖然這是個很奇怪的用法，應用程式應避免使用不明來源的字元串來寫Lua腳本。

在傳統架構的Redis中，用戶端是可以使用全部指令的，但是通路redis執行個體時是沒有能力控制運作着Redis的系統的。

本質上，Redis使用一直的最好的程式設計方法來寫安全的代碼，防止出現緩存溢出，格式錯誤和其他記憶體損壞問題。但是，使用CONFIG指令修改伺服器配置的能力使得使用者可以改變程式的工作目錄和備份檔案的名字。這讓使用者可以将RDB檔案寫在任意路徑，這個安全問題容易引起不受信任的代碼在Redis上運作。

Redis不需要root權限來運作，建議使用僅能運作redis的使用者運作。Redis的作者正在調查給Redis增加一個新參數來防止CONFIG SET/GET dir和其它指令運作時配置指令的可能。這可以防止用戶端強制要求伺服器在任意位置寫檔案。

本文作者：陳群

本文來自雲栖社群合作夥伴rediscn，了解相關資訊可以關注redis.cn網站。