概述
在眾多開源緩存技術(shù)中，redis無疑是目前功能最為強大，應(yīng)用最多的緩存技術(shù)之一，參考2019年6月國外數(shù)據(jù)庫技術(shù)權(quán)威網(wǎng)站DB-Engines關(guān)于key-value數(shù)據(jù)庫流行度排名，Redis暫列第一位，但是原生Redis版本在安全方面非常薄弱，很多地方不滿足安全要求，如果暴露在公網(wǎng)上，極易受到惡意攻擊，導致數(shù)據(jù)泄露和丟失。
所以今天主要從redis的合法監(jiān)聽接口，未公開接口，訪問通道控制來介紹Redis緩存數(shù)據(jù)庫加固措施。
01
合法監(jiān)聽接口
1、端口使用非默認端口
安全問題：Redis Server監(jiān)聽的端口默認為6379,容易被掃描攻擊。
解決方案：修改為非默認端口，并在端口矩陣中說明。
2、監(jiān)聽地址不允許包括*
安全問題：Redis支持監(jiān)聽0.0.0.0。
解決方案：因為如果有多網(wǎng)卡，應(yīng)該將監(jiān)聽地址設(shè)置為只有數(shù)據(jù)庫客戶端需要連接的網(wǎng)卡地址。如果只允許本機訪問，應(yīng)該只監(jiān)聽127.0.0.1。
3、隱蔽的RedisCluster端口
安全問題：官方RedisCluster方案缺省會增加一個集群端口，且是在客戶端端口偏移10000，這個問題非常隱蔽。
解決方案：在端口矩陣中對額外的這個集群端口有說明。修改源碼,新增一個redis.conf偏移量配置項cluster-port-increment，缺省配置+1，這樣可以做到端口范圍可控，避免沖突。
02
未公開接口
1、賬號管理(重要)
安全問題：Redis只有一個超戶，權(quán)限過大。
解決方案：權(quán)限最小化原則，增加配置項，角色區(qū)分超戶，普通用戶和只讀用戶三種。
普通用戶不能進行的操作有：
2、Redis-cli隱藏密碼
安全問題：通過在redis-cli指定-a參數(shù)，密碼會被ps出來，屬于敏感信息。
解決方案：修改Redis源碼,在main進入后，立即隱藏掉密碼，避免被ps出來。
3、禁止在腳本中通過sudo方式切換用戶執(zhí)行redis-cli
安全問題： redis-cli訪問參數(shù)帶密碼敏感信息,會被ps出來,也容易被系統(tǒng)記錄操作日志。
解決方案：改為通過API方式(Python可以使用redis-py)來安全訪問,禁止通過sudo方式切換到dbuser賬號使用redis-cli。
重現(xiàn)條件：可以通過iptables禁掉redis端口來模擬重現(xiàn)。
03
訪問通道控制
1、預共享秘鑰認證(重要)
安全問題：Redis原生認證存在重放攻擊:只是簡單的交互一次auth xxx
解決方案：采用預共享秘鑰(對稱加密算法+隨機數(shù)的雙向認證)，同時在方案設(shè)計上做到最大限度兼容，讓客戶端改造成本最小，目前平臺配套目前支持客戶端有:JAVA，Python，C，Lua。
方案設(shè)計如下:
Redis認證協(xié)議變更,其中auth命令區(qū)分兩種功能,通過首字母區(qū)分：
預共享秘鑰認證時序圖
說明：Redis為文本協(xié)議, 安全隨機數(shù)長度固定為32字節(jié)的可顯示字符串，連接2個隨機數(shù)的分隔符為”@”。
主要認證流程：
1.客戶端向服務(wù)端執(zhí)行命令: auth <RAND_C
1) 首字母<表示是認證第一階段。(便于服務(wù)端從協(xié)議層區(qū)分)
2) RAND_C表示客戶端生成安全隨機數(shù)。
2.服務(wù)端產(chǎn)生響應(yīng)錯誤回復
1) 獲取RAND_C,并生成RAND_S
2) 產(chǎn)生TokenBA=AES128(RAND_S@RAND_C)
3) 響應(yīng)錯誤回復:-ERR >TokenBA
說明:錯誤描述為服務(wù)端生成的安全隨機數(shù)。
3.客戶端驗證
1) 驗證TokenBA是否合法
解密出RAND_S@RAND_C，看看RAND_C是否是自己生成的隨機數(shù)
2) 客戶端產(chǎn)生TokenAB=AES128(RAND_C@RAND_S@dbname@ossdbuser@pwd)
3) 調(diào)用認證接口: auth >TokenAB
4.服務(wù)端認證
1) 驗證TokenAB是否合法
解密出RAND_C@RAND_S，看看RAND_S是否是自己生成的隨機數(shù)
2) 驗證用戶和密碼合法性: dbname@ossdbuser@pwd
2、認證時加上庫名
安全問題：Redis沒有庫名,系統(tǒng)如果只通過用戶名+密碼，容易猜測和攻擊。
解決方案：通過認證時帶上庫名, 因為每個服務(wù)的庫名都配置不同，增加攻擊復雜度, 認證格式以dbname@dbuser@pwd區(qū)分。
3、端口矩陣
安全問題：Redis也是一種數(shù)據(jù)庫服務(wù)，一般一個進程占用一個端口，集群還會額外多占用一個端口。
解決方案：在端口矩陣寫明系統(tǒng)申請的Redis端口范圍。
4、支持SSL通信
安全問題：增加SSL通信可以提高數(shù)據(jù)傳輸?shù)陌踩?/p>
解決方案：
1．不改動官方源碼,通過在客戶端和服務(wù)端部署SSL Proxy，類似stunnel。
2．支持SSL可配置,涉及開源代碼修改。
說明:因為Redis屬于交互密集型,每秒處理幾萬次請求,支持SSL后性能會有比較大損失。
5、支持ACL控制
安全問題：目前Redis沒有ACL控制。
解決方案：
1． 目前基于平臺共享秘鑰，其中秘鑰是隨機生成，每套系統(tǒng)不一樣，間接也做到了IP范圍控制。
2． 通過iptables控制進一步限制接入IP范圍。
3． 如果要具體控制到用戶+IP級別，類似MySQL認證。redis開發(fā)作者antirez已經(jīng)意識到這個問題，有望在未來版本提供。
