亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標(biāo)題: 【大話IT】RedisCrackIT入侵引發(fā)Linux 淪陷，你的服務(wù)器還安全嗎？ [打印本頁(yè)]

作者: 王楠w_n 時(shí)間: 2015-11-17 17:55
標(biāo)題: 【大話IT】RedisCrackIT入侵引發(fā)Linux 淪陷，你的服務(wù)器還安全嗎？

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

事件描述

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

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

問(wèn)題：

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

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

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

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

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

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

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

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

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

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

）

作者: jieforest 時(shí)間: 2015-11-18 09:15
本帖最后由 jieforest 于 2015-11-18 13:04 編輯

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

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

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

作者: vermouth 時(shí)間: 2015-11-18 09:21
redis 不知道還是不是當(dāng)年了解過(guò)的那個(gè)。。。

作者: VIP_fuck 時(shí)間: 2015-11-18 09:24
redis他爹也比較搞，說(shuō)redis得部署在防火墻后邊，然后就不用考慮安全機(jī)制了，，擦，

作者: wsysx 時(shí)間: 2015-11-18 09:37
這套徽章瞅著不錯(cuò)

作者: xdsnet 時(shí)間: 2015-11-18 09:38
本帖最后由 xdsnet 于 2015-11-18 09:42 編輯

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

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

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

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

作者: xdsnet 時(shí)間: 2015-11-18 09:39
本帖最后由 xdsnet 于 2015-11-18 09:44 編輯

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

作者: chenxing2 時(shí)間: 2015-11-18 09:47
1 此次容易遭受攻擊的環(huán)境是用戶自建的運(yùn)行了Redis服務(wù)的Linux主機(jī)，您認(rèn)為受到攻擊的主要原因是什么？

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

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

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

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

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

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

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

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

> 不使用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 密碼

增加訪問(wèn)控制

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

作者: lsstarboy 時(shí)間: 2015-11-18 14:26
這一個(gè)不應(yīng)該算是程序的漏洞，屬于管理的漏洞，就相當(dāng)于家里的門天天不鎖，或者是天天車門都不關(guān)。

作者: GB_juno 時(shí)間: 2015-11-18 16:41
部署時(shí)明顯考慮是無(wú)密碼登錄，還放在公網(wǎng)，死掛了..
一般考慮加了密碼之后開(kāi)發(fā)會(huì)覺(jué)得折騰，也是為了不折騰，一般通過(guò)
1)跑在docker里面，你怎么搞都不會(huì)拿到主機(jī)的權(quán)限..當(dāng)然這種也是不應(yīng)該，有人訪問(wèn)也不好
2)iptables，只允許某些主機(jī)的端口連過(guò)來(lái)，這招可以把網(wǎng)絡(luò)的掃描都擋住..基本可以滿足需求.

作者: chenyx 時(shí)間: 2015-11-18 18:44
沒(méi)用過(guò)redis，友情支持下活動(dòng)。
看網(wǎng)友的討論，將一個(gè)緩存的系統(tǒng)直接暴露在公網(wǎng)，這個(gè)不應(yīng)該出現(xiàn)的問(wèn)題竟然能出現(xiàn)，系統(tǒng)維護(hù)人員有不可推卸的責(zé)任。

作者: craaazy123 時(shí)間: 2015-11-23 11:10
這個(gè)漏洞，我有個(gè)大學(xué)同學(xué)碰到過(guò)，在朋友圈里大肆罵了番。他說(shuō)他們的100多臺(tái)服務(wù)器都受到了漏洞的影響。
我當(dāng)時(shí)就問(wèn)了他一句，你們數(shù)據(jù)庫(kù)/緩存服務(wù)器都扔公網(wǎng)的嗎？
然后就沒(méi)然后了。。。

作者: laputa73 時(shí)間: 2015-11-23 16:39
redis本身是提供訪問(wèn)的密碼授權(quán)機(jī)制的。文檔描述也還算清晰。
所以我也覺(jué)得這不是功能問(wèn)題。

當(dāng)然，從安全角度，也可以做一些默認(rèn)限制，
比如做成默認(rèn)不設(shè)密碼就不能訪問(wèn)
比如設(shè)置默認(rèn)只綁定localhost

作者: nfhflyrainbow 時(shí)間: 2015-11-26 10:01
11月16日，國(guó)內(nèi)安全研究團(tuán)隊(duì)啟明星辰積極防御實(shí)驗(yàn)室成功捕獲了國(guó)內(nèi)首例利用Redis漏洞實(shí)現(xiàn)的DDOS僵尸網(wǎng)絡(luò)控制樣本。自Redis漏洞被公布以來(lái)，網(wǎng)絡(luò)空間出現(xiàn)了大量利用該漏洞的攻擊事件，但利用該漏洞快速部署僵尸程序，并通過(guò)僵尸網(wǎng)絡(luò)實(shí)施高強(qiáng)度的分布式拒絕服務(wù)攻擊還是首例。

作者: 蟲(chóng)蟲(chóng)貓 時(shí)間: 2015-11-26 14:05
1 此次容易遭受攻擊的環(huán)境是用戶自建的運(yùn)行了Redis服務(wù)的Linux主機(jī)，您認(rèn)為受到攻擊的主要原因是什么？
最主要還是存在運(yùn)維安全意識(shí)不夠，對(duì)于安全來(lái)說(shuō)其實(shí)應(yīng)該是做到權(quán)限最小化，比如redis，最好使用非root的用戶進(jìn)行運(yùn)行，
即使被拿到了權(quán)限也不會(huì)造成太嚴(yán)重的后果，公網(wǎng)連接沒(méi)有必要的話不要開(kāi)啟，此外再配置上連接的密碼，就可以做到相對(duì)的安全。

2 redis在特定的領(lǐng)域下，具有一定的不可代替性，但安全性上，Redis未授權(quán)訪問(wèn)問(wèn)題是一直存在，您怎么看待？
是否進(jìn)行授權(quán)訪問(wèn)，選擇權(quán)作者都已經(jīng)提供給了用戶，在使用開(kāi)源軟件的時(shí)候一定要閱讀官方提供的文檔，做到盡可能的安全。

3 Redis作者放棄解決未授權(quán)訪問(wèn)導(dǎo)致的不安全性，您認(rèn)為這樣的做法是否正確？Redis作者這樣做的原因是什么？
這種做法沒(méi)有什么問(wèn)題，很多情況redis只是用于內(nèi)網(wǎng)使用的，如果加了密碼驗(yàn)證也會(huì)增加配置的復(fù)雜度。

4 針對(duì)此事件的解決方案是什么？有什么直接有效的建議？
跟第一條一樣：
1.用非root的用戶進(jìn)行運(yùn)行，即使被拿到了權(quán)限也不會(huì)造成太嚴(yán)重的后果，
2.公網(wǎng)連接沒(méi)有必要的話不要開(kāi)啟,或者使用防火墻只對(duì)必要的ip開(kāi)啟
3.配置上連接的密碼

作者: solohac 時(shí)間: 2015-12-01 11:52
1 此次容易遭受攻擊的環(huán)境是用戶自建的運(yùn)行了Redis服務(wù)的Linux主機(jī)，您認(rèn)為受到攻擊的主要原因是什么？
如果領(lǐng)導(dǎo)問(wèn)，原因是員工安全意識(shí)不夠，得多加強(qiáng)培訓(xùn)；
如果運(yùn)維同事問(wèn)，原因是開(kāi)發(fā)沒(méi)交代好怎么部署；
如果開(kāi)發(fā)同事問(wèn)，原因是運(yùn)維沒(méi)考慮到安全為題；
如果朋友問(wèn)，原因是說(shuō)白了就是員工工作不上心唄。
又不是新手怎么可能這點(diǎn)安全意識(shí)都沒(méi)有，說(shuō)白了就是工作不上心，一個(gè)應(yīng)用部署上去不考慮是否安全？防火墻開(kāi)沒(méi)開(kāi)？配置項(xiàng)里面有沒(méi)有什么問(wèn)題？

2 redis在特定的領(lǐng)域下，具有一定的不可代替性，但安全性上，Redis未授權(quán)訪問(wèn)問(wèn)題是一直存在，您怎么看待？
這不是redis的問(wèn)題，搭建的時(shí)候別讓對(duì)外訪問(wèn)不就行了。

3 Redis作者放棄解決未授權(quán)訪問(wèn)導(dǎo)致的不安全性，您認(rèn)為這樣的做法是否正確？Redis作者這樣做的原因是什么？
作者做法很正確。redis是用于存儲(chǔ)的，選用他的原因就是為了提高效率，加入acl這種東西，效率又變低了吧？
今天加個(gè)ACL，明天加個(gè)選舉，后天加個(gè)XX。。最后效率都被這些東西吃掉了。
專業(yè)的工作做專業(yè)的事，不做多余的事。

4 針對(duì)此事件的解決方案是什么？有什么直接有效的建議？
方案很簡(jiǎn)單，能不對(duì)外開(kāi)放的端口，一個(gè)都別多對(duì)外開(kāi)放；對(duì)外開(kāi)放的端口，都要相關(guān)開(kāi)發(fā)、運(yùn)維人員負(fù)責(zé)保證他的安全性。
誰(shuí)使用誰(shuí)負(fù)責(zé)，落實(shí)責(zé)任，避免工作不上心，怎么方便怎么來(lái)的工作態(tài)度。

作者: 王江玉 時(shí)間: 2015-12-02 10:56
給我發(fā)個(gè)徽章吧我還沒(méi)有呢

作者: action08 時(shí)間: 2015-12-02 19:55
理論是一套，實(shí)際是一套，何必認(rèn)真？？
用linux的人，技術(shù)應(yīng)該不是很差的吧，怎么還犯這個(gè)錯(cuò)誤？？

作者: j_cle 時(shí)間: 2015-12-03 00:18
好漂亮的勛章，樓主求勛章啊求勛章

1 此次容易遭受攻擊的環(huán)境是用戶自建的運(yùn)行了Redis服務(wù)的Linux主機(jī)，您認(rèn)為受到攻擊的主要原因是什么？
首先是應(yīng)用開(kāi)發(fā)者安全意識(shí)相對(duì)弱，沒(méi)有把權(quán)限分層管控細(xì)化放在心上，所有程序都以root運(yùn)行；
其次就是對(duì)redis本身的安全配置工作做到位，只想使用其提供的功能，但未考慮配置上的一些細(xì)節(jié)問(wèn)題；
再者就是此redis漏洞或者是缺陷對(duì)攻擊者來(lái)說(shuō)比較容易利用，像通過(guò)ssh的rsa這種方式，入侵者只需要簡(jiǎn)單的幾個(gè)命令就能輕易獲取用戶系統(tǒng)的最高權(quán)限，也誘發(fā)了對(duì)redis這種缺陷的注意。
2 redis在特定的領(lǐng)域下，具有一定的不可代替性，但安全性上，Redis未授權(quán)訪問(wèn)問(wèn)題是一直存在，您怎么看待？
這個(gè)跟開(kāi)發(fā)的用途有關(guān)系，一個(gè)產(chǎn)品的開(kāi)發(fā)跟特定應(yīng)用條件有強(qiáng)關(guān)聯(lián)，應(yīng)用條件的變化很可能會(huì)暴露出產(chǎn)品的缺陷，這是無(wú)法避免的；但就redis來(lái)說(shuō)，如果是僅僅放置于內(nèi)網(wǎng)安全環(huán)境使用來(lái)說(shuō)，風(fēng)險(xiǎn)會(huì)少很多，同樣其他產(chǎn)品也是一樣，定期開(kāi)展對(duì)公司內(nèi)部網(wǎng)絡(luò)的及應(yīng)用服務(wù)的安全測(cè)試，對(duì)企業(yè)的安全防御具有重大意義
3 Redis作者放棄解決未授權(quán)訪問(wèn)導(dǎo)致的不安全性，您認(rèn)為這樣的做法是否正確？Redis作者這樣做的原因是什么？
Redis 安全模型的觀念是: “請(qǐng)不要將Redis暴露在公開(kāi)網(wǎng)絡(luò)中, 因?yàn)樽尣皇苄湃蔚目蛻艚佑|到Redis是非常危險(xiǎn)的”,Redis 作者之所以放棄解決未授權(quán)訪問(wèn)導(dǎo)致的不安全性是因?yàn)? 99.99%使用Redis的場(chǎng)景都是在沙盒化的環(huán)境中, 為了0.01%的可能性增加安全規(guī)則的同時(shí)也增加了復(fù)雜性, 雖然這個(gè)問(wèn)題的并不是不能解決的, 但是這在他的設(shè)計(jì)哲學(xué)中仍是不劃算的.
4 針對(duì)此事件的解決方案是什么？有什么直接有效的建議？
a，開(kāi)啟身份驗(yàn)證
b，禁用、重命名部分關(guān)鍵命令
c，想web服務(wù)一樣更改默認(rèn)6379端口，雖然意義不是很大，但是卻一定程度上減小了被攻擊概率
d，減小所對(duì)應(yīng)的公網(wǎng)ip直接暴漏在公網(wǎng)中。

歡迎光臨 Chinaunix (http://www.72891.cn/)