背景

在眾多開源緩存技術中，redis無疑是目前功能最為強大，應用最多的緩存技術之一，參考2018年國外數(shù)據(jù)庫技術權威網(wǎng)站DB-Engines關于key-value數(shù)據(jù)庫流行度排名，Redis暫列第一位，但是原生Redis版本在安全方面非常薄弱，很多地方不滿足安全要求，如果暴露在公網(wǎng)上，極易受到惡意×××，導致數(shù)據(jù)泄露和丟失。

成都創(chuàng)新互聯(lián)堅持“要么做到，要么別承諾”的工作理念，服務領域包括：做網(wǎng)站、網(wǎng)站設計、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務，滿足客戶于互聯(lián)網(wǎng)時代的大埔網(wǎng)站設計、移動媒體設計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡建設合作伙伴！

本文主要是在原生開源軟件Redis3.0基礎上，系統(tǒng)的在安全特性方面進行的增強,很多增強點涉及了開源代碼的修改，后續(xù)章節(jié)闡述的Redis緩存數(shù)據(jù)庫的安全規(guī)范, 理論上適用于所有應用Redis的產(chǎn)品。

本系列共連載三篇，分九個章節(jié)，本文從合法監(jiān)聽接口，未公開接口，訪問通道控制三個章節(jié)闡述了Redis緩存數(shù)據(jù)庫加固措施

1、合法監(jiān)聽接口

1.1 端口使用非默認端口

安全問題：Redis Server監(jiān)聽的端口默認為6379,容易被掃描×××。
解決方案：修改為非默認端口，并在端口矩陣中說明。

1.2 監(jiān)聽地址不允許包括*

安全問題：Redis支持監(jiān)聽0.0.0.0。
解決方案：因為如果有多網(wǎng)卡，應該將監(jiān)聽地址設置為只有數(shù)據(jù)庫客戶端需要連接的網(wǎng)卡地址。如果只允許本機訪問，應該只監(jiān)聽127.0.0.1。

1.3 隱蔽的RedisCluster端口

安全問題：官方RedisCluster方案缺省會增加一個集群端口，且是在客戶端端口偏移10000，這個問題非常隱蔽。
解決方案：在端口矩陣中對額外的這個集群端口有說明。修改源碼,新增一個redis.conf偏移量配置項cluster-port-increment，缺省配置+1，這樣可以做到端口范圍可控，避免沖突。

2、未公開接口

2.1 賬號管理(重要)

安全問題：Redis只有一個超戶，權限過大。
解決方案：權限最小化原則，增加配置項，角色區(qū)分超戶，普通用戶和只讀用戶三種。

普通用戶不能進行的操作有：

2.2 Redis-cli隱藏密碼

安全問題：通過在redis-cli指定-a參數(shù)，密碼會被ps出來，屬于敏感信息。
解決方案：修改Redis源碼,在main進入后，立即隱藏掉密碼，避免被ps出來。(可參考開源MySQL代碼)

2.3 Redis-cli工具使用說明

對于需在現(xiàn)網(wǎng)維護階段使用的命令/參數(shù)、端口等接入方式（包括但不限于產(chǎn)品的生產(chǎn)、調(diào)測、維護用途），需通過產(chǎn)品資料等向客戶或監(jiān)管機構公開或受限公開。

2.4 禁止在腳本中通過sudo方式切換用戶執(zhí)行redis-cli

安全問題： redis-cli訪問參數(shù)帶密碼敏感信息,會被ps出來,也容易被系統(tǒng)記錄操作日志。
解決方案：改為通過API方式(Python可以使用redis-py)來安全訪問,禁止通過sudo方式切換到dbuser賬號使用redis-cli。
重現(xiàn)條件：可以通過iptables禁掉redis端口來模擬重現(xiàn)。

3、訪問通道控制

3.1 預共享秘鑰認證(重要)

安全問題：Redis原生認證存在重放×××:只是簡單的交互一次auth xxx
解決方案：采用預共享秘鑰(對稱加密算法+隨機數(shù)的雙向認證)，同時在方案設計上做到最大限度兼容，讓客戶端改造成本最小，目前平臺配套目前支持客戶端有:Java，Python，C，Lua。

方案設計如下：
Redis認證協(xié)議變更,其中auth命令區(qū)分兩種功能,通過首字母區(qū)分：

預共享秘鑰認證時序圖

說明：Redis為文本協(xié)議, 安全隨機數(shù)長度固定為32字節(jié)的可顯示字符串，連接2個隨機數(shù)的分隔符為”@”。

主要認證流程：
1.客戶端向服務端執(zhí)行命令: authRAND_C
1)首字母<表示是認證第一階段。(便于服務端從協(xié)議層區(qū)分)
2)RAND_C表示客戶端生成安全隨機數(shù)。

2.服務端產(chǎn)生響應錯誤回復1)獲取RAND_C,并生成RAND_S
2)產(chǎn)生TokenBA=AES128(RAND_S@RAND_C)
br/>1)獲取RAND_C,并生成RAND_S
2)產(chǎn)生TokenBA=AES128(RAND_S@RAND_C)
TokenBA
說明:錯誤描述為服務端生成的安全隨機數(shù)。

3.客戶端驗證1)驗證TokenBA是否合法
解密出RAND_S@RAND_C，看看RAND_C是否是自己生成的隨機數(shù)
br/>1)驗證TokenBA是否合法
解密出RAND_S@RAND_C，看看RAND_C是否是自己生成的隨機數(shù)
3)調(diào)用認證接口: auth >TokenAB

4.服務端認證
1) 驗證TokenAB是否合解密出RAND_C@RAND_S，看看RAND_S是否是自己生成的隨機數(shù)
br/>解密出RAND_C@RAND_S，看看RAND_S是否是自己生成的隨機數(shù)

3.2 認證時加上庫名

安全問題：Redis沒有庫名,系統(tǒng)如果只通過用戶名+密碼，容易猜測和×××。
解決方案：通過認證時帶上庫名, 因為每個服務的庫名都配置不同，增加×××復雜度, 認證格式以dbname@dbuser@pwd區(qū)分。

3.3 端口矩陣

安全問題：Redis也是一種數(shù)據(jù)庫服務，一般一個進程占用一個端口，集群還會額外多占用一個端口。
解決方案：在端口矩陣寫明系統(tǒng)申請的Redis端口范圍。

3.4 客戶端認證超時時間

安全問題：原生Redis沒有限制客戶端認證超時時間,存在慢×××。
解決方案：修改源碼,限制在60秒內(nèi)認證成功，否則服務器將主動斷開連接。
說明: 控制完成客戶端認證的時間上限。這可以防止無效客戶端長時間占用連接通道。

3.5 支持SSL通信

安全問題：增加SSL通信可以提高數(shù)據(jù)傳輸?shù)陌踩?br/>解決方案：
1．不改動官方源碼,通過在客戶端和服務端部署SSL Proxy，類似stunnel。
2．支持SSL可配置,涉及開源代碼修改。
說明:因為Redis屬于交互密集型,每秒處理幾萬次請求,支持SSL后性能會有比較大損失。

3.6 支持ACL控制

安全問題：目前Redis沒有ACL控制。
解決方案：
1． 目前基于平臺共享秘鑰，其中秘鑰是隨機生成，每套系統(tǒng)不一樣，間接也做到了IP范圍控制。
2． 通過iptables控制進一步限制接入IP范圍。
3． 如果要具體控制到用戶+IP級別，類似Mysql認證。作者antirez已經(jīng)意識到這個問題，有望在未來版本提供，鏈接如下：Multi users AUTH and ACLs for Redis

3.7 Jedis客戶端相關

安全問題：官方推薦Java客戶端Jedis集群最新版還不支持認證。
解決方案：增加認證參數(shù)，與服務端共享秘鑰認證保持一致。
安全問題：Jedis認證接口密碼為參數(shù)string。
解決方案：Jedis客戶端認證新增一套char[]接口。

3.8 集群認證相關

1. RedisCluster多主多從,內(nèi)部高度自制，因此Redis的認證masterauth需要加密保存到配置文件。
   2.配置集群關系時,基于Gossip協(xié)議，Cluster meet需要有認證保護。