高性能Redis數(shù)據(jù)庫安全手冊

■曾金燕

高性能Redis數(shù)據(jù)庫安全手冊

■曾金燕

Redis是一個高性能的key-value數(shù)據(jù)庫，這兩年可謂火的不行。而Redis的流行也帶來一系列安全問題，不少攻擊者都通過Redis發(fā)起攻擊。本文將講解這方面的內(nèi)容，包括Redis提供的訪問控制和代碼安全問題，以及可以由惡意輸入和其他類似的手段觸發(fā)的攻擊。

Redis通用安全模塊

Redis被設(shè)計成只能由可信環(huán)境的可信機(jī)器訪問。這意味著將它直接暴露在互聯(lián)網(wǎng)或者其他可以由不可信機(jī)器通過TCP或者UNIX SCOKET直接連接的環(huán)境中。

例如，在通常的WEB應(yīng)用程序使用Redis作為數(shù)據(jù)庫，cache,或者消息系統(tǒng)。WEB應(yīng)用程序的客戶端將查詢Redis生成頁面或執(zhí)行請求或由用戶觸發(fā)。在這個例子中，WEB應(yīng)用鏈接了Redis和不可信的客戶端。

這是一個特定的例子，但是一般來說，不授信的Redis鏈接應(yīng)該被監(jiān)控，驗(yàn)證用戶輸入，再決定執(zhí)行什么樣的操作。因?yàn)?，Redis追求的不是最大的安全性，而是簡潔與高效。

網(wǎng)絡(luò)安全

Redis鏈接應(yīng)該對每個受信的客戶端開放。所以，服務(wù)器運(yùn)行的Redis應(yīng)該只被使用Redis應(yīng)用的計算機(jī)連接。在大多數(shù)直接暴露在互聯(lián)網(wǎng)的單個計算機(jī)，例如，虛擬化的LINUX實(shí)例(LINODE，EC2，…..)

Redis端口應(yīng)該被防火墻阻止來自外部的訪問?？蛻舳藨?yīng)該仍然能通過服務(wù)器的本地回環(huán)接口訪問Redis。注意，通過在Redis.CONF添加下面一句就可以綁定本地回環(huán)，阻止外網(wǎng)訪問了。

bind 127.0.0.1

因?yàn)镽edis的特性，沒有對外網(wǎng)訪問進(jìn)行限制會是一個很重大的安全問題。例如一條簡單的FLUSHALL命令就能被攻擊者用來刪除整個數(shù)據(jù)設(shè)置。

身份驗(yàn)證機(jī)制

如果你們不想使用訪問限制的話，Redis提供了一個身份驗(yàn)證功能，可以通過編輯Redis.CONF文件來實(shí)現(xiàn)它。

如果開啟了身份驗(yàn)證功能，Redis將拒絕所有的未身份驗(yàn)證的客戶端的所有操作。客戶端可以發(fā)送AUTH命令+密碼來驗(yàn)證自己。

密碼是由系統(tǒng)管理員在Redis。CONFIG文件中設(shè)置的明文密碼，為了防止暴力破解攻擊他應(yīng)該足夠長。原因有兩個：

Redis的執(zhí)行效率非?？?，外部設(shè)備每秒可以測試相當(dāng)數(shù)量的密碼

Redis的密碼是存儲在Redis.conf文件和內(nèi)部客戶端的配置中的，因此不需要管理員記住。所以可以使用相當(dāng)長的密碼。

身份驗(yàn)證的目標(biāo)是提供第二層的安全保障。這樣當(dāng)防火墻或者其他第一層的系統(tǒng)安全設(shè)置失效的話，一個外部設(shè)備在沒有密碼的情況下仍然不能訪問redia。

AUTH命令像其他的redia命令一樣是不加密傳輸?shù)?，所以他不能阻止攻擊者在?nèi)網(wǎng)的竊聽。

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

Redis不支持加密。為了受信的客戶端可以以加密形式通過互聯(lián)網(wǎng)可以采用加密協(xié)議(SSL)傳輸數(shù)據(jù)。

禁用特定的命令

禁用Redis的一些命令是可行的，或者將他們改名。這樣來自客戶端的請求就只能執(zhí)行有限的命令。

例如，虛擬的服務(wù)器提供商可能提供托管的Redis服務(wù)。在這種情況下，普通用戶不應(yīng)該能夠調(diào)用Redis的配置命令來修改該配置實(shí)例，但提供和刪除服務(wù)的系統(tǒng)能夠有這樣的權(quán)限。

在這種情況下，從命令表中重命名命令或者完全隱藏命令是可能的。這個功能可用在Redis.conf配置文件里做為一個聲明。

由精密的輸入觸發(fā)的攻擊

還有一類攻擊，攻擊者即使沒有獲得數(shù)據(jù)庫的訪問權(quán)限也可以從外部發(fā)起攻擊。一個此類攻擊的例子是通過Redis的內(nèi)部函數(shù)向Redis里插入數(shù)據(jù)。

攻擊者可以通過一個WEB表單將一組字符串提交到一個hash的同一個堆棧，引起時間復(fù)雜度從O(1)到O(n),消耗更多的CPU資源，最終導(dǎo)致DOS攻擊。為了防止這種特定的攻擊方式，Redis為每個執(zhí)行請求隨機(jī)分配hash。

Redis使用快速排序算法來執(zhí)行SORT命令。目前，這個算法不是隨機(jī)的，所以通過對輸入的精細(xì)控制可能觸發(fā)命令的二次執(zhí)行。

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

Redis協(xié)議里面沒有字符串轉(zhuǎn)義相關(guān)的內(nèi)容，所以在通常情況下是不存在注入的。Redis協(xié)議使用的是前綴長度的字符串，完全二進(jìn)制，保證安全性。LUA腳本執(zhí)行EVAL和EVALSHA命令時遵循相同的規(guī)則，因此這些命令也是安全的。

然而這回事一個非常奇怪的用例，應(yīng)用程序應(yīng)該避免使用LUA腳本獲取來自非信任源的字符串。

代碼安全性

在經(jīng)典的Redis設(shè)置里，客戶端可以執(zhí)行所有的命令集，但是獲得的用例應(yīng)該永遠(yuǎn)不能導(dǎo)致有控制Redis所在系統(tǒng)的能力。內(nèi)在的，Redis使用眾所周知的安全代碼規(guī)范來防止緩沖區(qū)溢出，格式錯誤和其它內(nèi)存損壞問題。然而，客戶端擁有控制使用服務(wù)器配置命令CONFIG的能力使得其能夠改變程序的工作目錄和轉(zhuǎn)儲文件的名稱。這允許客戶端寫RDB Redis在隨機(jī)路徑寫文件。這是一個安全問題，容易導(dǎo)致客戶端有Redis運(yùn)行非法代碼的能力。

Redis不需要root權(quán)限運(yùn)行，也不建議以root權(quán)限運(yùn)行。Redis的作者正在調(diào)查添加一條新的配置參數(shù)來防止CONFIG SET/GET目錄和其他類似的運(yùn)行時配置的指令的可能性。這會阻止客戶端強(qiáng)制服務(wù)器在任意位置寫Redis轉(zhuǎn)儲文件。

GPG key

安全研究人員可以在Github提交問題，當(dāng)你感覺這個安全問題真的很重要，在文檔的末尾加上GPG標(biāo)識。