【大話IT】RedisCrackIT入侵引發(fā)Linux 淪陷，你的服務(wù)器還安全嗎？

王楠w_n

獲獎(jiǎng)詳情：http://72891.cn/thread-4235292-1-1.html

事件描述

很多使用者都是把redis下載到服務(wù)器直接運(yùn)行使用，無ACL，無密碼，root運(yùn)行，且綁定在0.0.0.0:6379，暴露在公網(wǎng)。攻擊者在未授權(quán)訪問 Redis 的情況下通過redis的機(jī)制，可以將自己的公鑰或者其他惡意程序?qū)懭肽繕?biāo)服務(wù)器中，從而可以直接控制目標(biāo)服務(wù)器。

2015年11月10日，不知名團(tuán)體利用redis世界缺陷針對全球互聯(lián)網(wǎng)的全網(wǎng)性入侵，本次攻擊事件已經(jīng)影響至少萬余家服務(wù)器被成功入侵。redis官網(wǎng)并未對此提供補(bǔ)丁，到目前為止看到的利用過程是基于redis提供的正常功能，而且這一問題早在去年九月就作為遠(yuǎn)程代碼執(zhí)行RCE的技術(shù)問題做了公開發(fā)布，并只得到小范圍傳播。

問題：

1 此次容易遭受攻擊的環(huán)境是用戶自建的運(yùn)行了Redis服務(wù)的Linux主機(jī)，您認(rèn)為受到攻擊的主要原因是什么？

2 redis在特定的領(lǐng)域下，具有一定的不可代替性，但安全性上，Redis未授權(quán)訪問問題是一直存在，您怎么看待？

3 Redis作者放棄解決未授權(quán)訪問導(dǎo)致的不安全性，您認(rèn)為這樣的做法是否正確？Redis作者這樣做的原因是什么？

4 針對此事件的解決方案是什么？有什么直接有效的建議？

討論時(shí)間：2015年11月17日——12月17日

獎(jiǎng)勵(lì)設(shè)置：

活動(dòng)結(jié)束后，我們將選取1位最佳討論獎(jiǎng)，送ChinaUnix社區(qū)14周年圣斗士系列紀(jì)念徽章。

                                         
白銀圣斗士      冥斗士       青銅圣斗士     黃金圣斗士                           

將選取3位討論精彩的小伙伴送論壇讀書徽章一枚

獲得圖書徽章的朋友，可在ChinaUnix社區(qū)圖書庫兌換技術(shù)圖書一本。（如果沒有合適的圖書，大家可以先屯著徽章，有喜歡的圖書在兌換）

jieforest

坐個(gè)沙發(fā)，這套章不錯(cuò)。


1 此次容易遭受攻擊的環(huán)境是用戶自建的運(yùn)行了Redis服務(wù)的Linux主機(jī)，您認(rèn)為受到攻擊的主要原因是什么？
2 redis在特定的領(lǐng)域下，具有一定的不可代替性，但安全性上，Redis未授權(quán)訪問問題是一直存在，您怎么看待？
3 Redis作者放棄解決未授權(quán)訪問導(dǎo)致的不安全性，您認(rèn)為這樣的做法是否正確？Redis作者這樣做的原因是什么？
4 針對此事件的解決方案是什么？有什么直接有效的建議？

幾個(gè)問題一起回答吧，反正說的是一件事。
Redis這個(gè)開源軟件本身不具備安全機(jī)制，這是眾所周知的。
把Redis服務(wù)部署在公網(wǎng)，本身這種做法就存在問題，明顯是相關(guān)的開發(fā)團(tuán)隊(duì)太菜了。
Redis服務(wù)最常見的應(yīng)用場景是做高速緩存或者是分布式緩存。也可以作為計(jì)數(shù)器這樣的應(yīng)用場景。
不管怎么樣，Redis服務(wù)都是作為后端業(yè)務(wù)的一部分，應(yīng)該部署在內(nèi)網(wǎng)環(huán)境，被防火墻隔離。
LZ提到的問題根本就不算問題，討論一群菜鳥遇到的安全問題能算什么？？？

vermouth

redis 不知道還是不是當(dāng)年了解過的那個(gè)。。。

VIP_fuck

redis他爹也比較搞，說redis得部署在防火墻后邊，然后就不用考慮安全機(jī)制了，，擦，

wsysx

這套徽章瞅著不錯(cuò)

wsysx

這套徽章瞅著不錯(cuò)

xdsnet

1 此次容易遭受攻擊的環(huán)境是用戶自建的運(yùn)行了Redis服務(wù)的Linux主機(jī)，您認(rèn)為受到攻擊的主要原因是什么？
這個(gè)其實(shí)還是應(yīng)用者整體的安全意識(shí)不夠好，特別一些用戶作為專業(yè)的管理者，其實(shí)沒有真正的安全意識(shí)，所有應(yīng)用都以root來跑，一個(gè)被攻破了，然后就整體淪陷。其實(shí)Redis是否有授權(quán)訪問并非這個(gè)事件的真正原因，因?yàn)橐话阍O(shè)計(jì)中Redis屬于內(nèi)部訪問。整體安全意識(shí)好，這樣的應(yīng)用有很多方案進(jìn)行隔離，讓數(shù)據(jù)只能在有限的域/ip范圍內(nèi)訪問（進(jìn)入這些的應(yīng)用必須是經(jīng)過一定認(rèn)證和簽權(quán)的）這也是可行的�。∷�以這樣的事件其實(shí)更多的是因?yàn)閮?nèi)外系統(tǒng)分隔隔離不到位造成的。

2 redis在特定的領(lǐng)域下，具有一定的不可代替性，但安全性上，Redis未授權(quán)訪問問題是一直存在，您怎么看待？
其實(shí)還是和前面回答的一樣。安全性并非僅僅靠單個(gè)組件的原因，還要看整個(gè)系統(tǒng)的搭建，是一個(gè)整體性的策略應(yīng)用，需要區(qū)分內(nèi)部應(yīng)用安全和外部訪問安全，并進(jìn)行隔離。一般來說，外部訪問安全需要很多技術(shù)措施進(jìn)行保障，內(nèi)部訪問安全更多的體現(xiàn)在一些規(guī)則制度的嚴(yán)格遵守上。因?yàn)閮?nèi)部安全僅僅靠技術(shù)手段是無法根本性防止了（就好比有權(quán)限的用戶鐵心要搞破壞，你僅僅從技術(shù)手段上防止的可能已經(jīng)很小），所以很多時(shí)候，對于內(nèi)外訪問隔離很好的，內(nèi)部簽權(quán)的要求是很低的。而且很多事是有沖突的，比如簽權(quán)和性能要求在很多情況下都是有沖突的，為了一個(gè)本來該在其他方面進(jìn)行隔離防治的安全問題來增加Redis的安全處理成本，進(jìn)而降低其核心業(yè)務(wù)數(shù)據(jù)訪問的性能可能是不被Redis開發(fā)者接受的。

3 Redis作者放棄解決未授權(quán)訪問導(dǎo)致的不安全性，您認(rèn)為這樣的做法是否正確？Redis作者這樣做的原因是什么？
其實(shí)前面已經(jīng)提到了Redis作者放棄解決未經(jīng)授權(quán)訪問導(dǎo)致的不安全性的原因，我覺得這樣的考慮是合乎邏輯的選擇，即安全的問題可以有其他好的安全策略應(yīng)用通過內(nèi)外隔離來解決，我提供的應(yīng)用是內(nèi)部應(yīng)用，可以不涉及安全考慮，而專心做好數(shù)據(jù)訪問性能。我個(gè)人是支持這樣的選擇的。

4 針對此事件的解決方案是什么？有什么直接有效的建議？
好的解決方案是：
調(diào)整/制定 好的安全策略， 做好系統(tǒng)的重新規(guī)劃，分析好那些是內(nèi)部訪問領(lǐng)域，那些是外部訪問領(lǐng)域，做好安全隔離，在外部訪問領(lǐng)域做好/做強(qiáng) 安全處理
直接有效的建議就是把Redis部署在內(nèi)網(wǎng)中（采用有限權(quán)限特定用戶），限定內(nèi)網(wǎng)訪問，進(jìn)行物理/應(yīng)用 隔離，防止外部非法訪問 ，同時(shí)對內(nèi)部人應(yīng)用制定安全規(guī)程（提供安全訪問的標(biāo)準(zhǔn)程序/方法/路徑...，進(jìn)行內(nèi)外隔離應(yīng)用的示范）

xdsnet

網(wǎng)絡(luò)慢，居然發(fā)重了，這個(gè)純灌水啦

chenxing2

1 此次容易遭受攻擊的環(huán)境是用戶自建的運(yùn)行了Redis服務(wù)的Linux主機(jī)，您認(rèn)為受到攻擊的主要原因是什么？

   未做安全控制，主要還是針對公網(wǎng)開放了。

   部署redis集群時(shí)，對公網(wǎng)開放運(yùn)維/開發(fā)省事

2 redis在特定的領(lǐng)域下，具有一定的不可代替性，但安全性上，Redis未授權(quán)訪問問題是一直存在，您怎么看待？

   作者不認(rèn)為是問題，估計(jì)他嚼的他只需把核心功能做好，這類問題交給使用者處理

3 Redis作者放棄解決未授權(quán)訪問導(dǎo)致的不安全性，您認(rèn)為這樣的做法是否正確？Redis作者這樣做的原因是什么？

   對于作者來說，目前回復(fù)是：這是正常功能。
   其實(shí)對于Redis本身的功能來說，只要來訪問就做出相應(yīng)也確實(shí)是redis的功能，從這方面來說是無可厚非的。

   如果說作者不想加入這個(gè)功能，這就意味著這安全是由使用者來考慮的，作者只考慮核心功能即可。


4 針對此事件的解決方案是什么？有什么直接有效的建議？

> 不使用root啟用redis服務(wù)，或者用低權(quán)限的用戶啟用
> 修改redis.conf配置文件
   增加
      rename-command FLUSHALL ""
      rename-command FLUSHDB ""
      rename-command CONFIG ""
      rename-command EVAL ""
   將這幾個(gè)危險(xiǎn)命令廢掉

   增加
       requirepass   密碼

   有主備的，在備機(jī)也要配置

       masterauth    密碼

   增加訪問控制

        bind   多個(gè)IP地址（僅限指定IP可以訪問），這個(gè)也應(yīng)該可以通過linux防火墻控制

lsstarboy

這一個(gè)不應(yīng)該算是程序的漏洞，屬于管理的漏洞，就相當(dāng)于家里的門天天不鎖，或者是天天車門都不關(guān)。