【大话IT】RedisCrackIT入侵引发Linux 沦陷，你的服务器还安全吗？
获奖详情：http://bbs.chinaunix.net/thread-4235292-1-1.html事件描述很多使用者都是把redis下载到服务器直接运行使用，无ACL，无密码，root运行，且绑定在0.0.0.0:6379，暴露在公网。攻击者在未授权访问 Redis 的情况下通过redis的机制，可以将自己的公钥或者其他恶意程序写入目标服务器中，从而可以直接控制目标服务器。2015年11月10日，不知名团体利用redis世界缺陷针对全球互联网的全网性入侵，本次攻击事件已经影响至少万余家服务器被成功入侵。redis官网并未对此提供补丁，到目前为止看到的利用过程是基于redis提供的正常功能，而且这一问题早在去年九月就作为远程代码执行RCE的技术问题做了公开发布，并只得到小范围传播。
问题：1 此次容易遭受攻击的环境是用户自建的运行了Redis服务的Linux主机，您认为受到攻击的主要原因是什么？2 redis在特定的领域下，具有一定的不可代替性，但安全性上，Redis未授权访问问题是一直存在，您怎么看待？3 Redis作者放弃解决未授权访问导致的不安全性，您认为这样的做法是否正确？Redis作者这样做的原因是什么？4 针对此事件的解决方案是什么？有什么直接有效的建议？
讨论时间：2015年11月17日——12月17日
奖励设置：活动结束后，我们将选取1位最佳讨论奖，送ChinaUnix社区14周年圣斗士系列纪念徽章。
http://cupic.img168.net/bbsfile/forum/201511/12/111957wwkqd5yl7jj2jkkk.png http://cupic.img168.net/bbsfile/forum/201511/12/1119588tl82iisp8eu61sq.png http://cupic.img168.net/bbsfile/forum/201511/12/111958stxoxk4fy4u6su4s.png http://cupic.img168.net/bbsfile/forum/201511/12/111957a125x4qivny5882n.png
白银圣斗士 冥斗士 青铜圣斗士 黄金圣斗士
将选取3位讨论精彩的小伙伴送论坛读书徽章一枚
获得图书徽章的朋友，可在ChinaUnix社区图书库兑换技术图书一本。（如果没有合适的图书，大家可以先屯着徽章，有喜欢的图书在兑换:em03:）
本帖最后由 jieforest 于 2015-11-18 13:04 编辑
坐个沙发，这套章不错。
1 此次容易遭受攻击的环境是用户自建的运行了Redis服务的Linux主机，您认为受到攻击的主要原因是什么？
2 redis在特定的领域下，具有一定的不可代替性，但安全性上，Redis未授权访问问题是一直存在，您怎么看待？
3 Redis作者放弃解决未授权访问导致的不安全性，您认为这样的做法是否正确？Redis作者这样做的原因是什么？
4 针对此事件的解决方案是什么？有什么直接有效的建议？
几个问题一起回答吧，反正说的是一件事。
Redis这个开源软件本身不具备安全机制，这是众所周知的。
把Redis服务部署在公网，本身这种做法就存在问题，明显是相关的开发团队太菜了。
Redis服务最常见的应用场景是做高速缓存或者是分布式缓存。也可以作为计数器这样的应用场景。
不管怎么样，Redis服务都是作为后端业务的一部分，应该部署在内网环境，被防火墙隔离。
LZ提到的问题根本就不算问题，讨论一群菜鸟遇到的安全问题能算什么？？？ redis 不知道还是不是当年了解过的那个。。。 redis他爹也比较搞，说redis得部署在防火墙后边，然后就不用考虑安全机制了，，擦， 这套徽章瞅着不错 这套徽章瞅着不错 本帖最后由 xdsnet 于 2015-11-18 09:42 编辑
1 此次容易遭受攻击的环境是用户自建的运行了Redis服务的Linux主机，您认为受到攻击的主要原因是什么？
这个其实还是应用者整体的安全意识不够好，特别一些用户作为专业的管理者，其实没有真正的安全意识，所有应用都以root来跑，一个被攻破了，然后就整体沦陷。其实Redis是否有授权访问并非这个事件的真正原因，因为一般设计中Redis属于内部访问。整体安全意识好，这样的应用有很多方案进行隔离，让数据只能在有限的域/ip范围内访问（进入这些的应用必须是经过一定认证和签权的）这也是可行的啊！所以这样的事件其实更多的是因为内外系统分隔隔离不到位造成的。
2 redis在特定的领域下，具有一定的不可代替性，但安全性上，Redis未授权访问问题是一直存在，您怎么看待？
其实还是和前面回答的一样。安全性并非仅仅靠单个组件的原因，还要看整个系统的搭建，是一个整体性的策略应用，需要区分内部应用安全和外部访问安全，并进行隔离。一般来说，外部访问安全需要很多技术措施进行保障，内部访问安全更多的体现在一些规则制度的严格遵守上。因为内部安全仅仅靠技术手段是无法根本性防止了（就好比有权限的用户铁心要搞破坏，你仅仅从技术手段上防止的可能已经很小），所以很多时候，对于内外访问隔离很好的，内部签权的要求是很低的。而且很多事是有冲突的，比如签权和性能要求在很多情况下都是有冲突的，为了一个本来该在其他方面进行隔离防治的安全问题来增加Redis的安全处理成本，进而降低其核心业务数据访问的性能可能是不被Redis开发者接受的。
3 Redis作者放弃解决未授权访问导致的不安全性，您认为这样的做法是否正确？Redis作者这样做的原因是什么？
其实前面已经提到了Redis作者放弃解决未经授权访问导致的不安全性的原因，我觉得这样的考虑是合乎逻辑的选择，即安全的问题可以有其他好的安全策略应用通过内外隔离来解决，我提供的应用是内部应用，可以不涉及安全考虑，而专心做好数据访问性能。我个人是支持这样的选择的。
4 针对此事件的解决方案是什么？有什么直接有效的建议？
好的解决方案是：
调整/制定 好的安全策略， 做好系统的重新规划，分析好那些是内部访问领域，那些是外部访问领域，做好安全隔离，在外部访问领域做好/做强 安全处理
直接有效的建议就是把Redis部署在内网中（采用有限权限特定用户），限定内网访问，进行物理/应用 隔离，防止外部非法访问 ，同时对内部人应用制定安全规程（提供安全访问的标准程序/方法/路径...，进行内外隔离应用的示范）
本帖最后由 xdsnet 于 2015-11-18 09:44 编辑
网络慢，居然发重了，这个纯灌水啦 1 此次容易遭受攻击的环境是用户自建的运行了Redis服务的Linux主机，您认为受到攻击的主要原因是什么？
未做安全控制，主要还是针对公网开放了。
部署redis集群时，对公网开放运维/开发省事
2 redis在特定的领域下，具有一定的不可代替性，但安全性上，Redis未授权访问问题是一直存在，您怎么看待？
作者不认为是问题，估计他嚼的他只需把核心功能做好，这类问题交给使用者处理
3 Redis作者放弃解决未授权访问导致的不安全性，您认为这样的做法是否正确？Redis作者这样做的原因是什么？
对于作者来说，目前回复是：这是正常功能。
其实对于Redis本身的功能来说，只要来访问就做出相应也确实是redis的功能，从这方面来说是无可厚非的。
如果说作者不想加入这个功能，这就意味着这安全是由使用者来考虑的，作者只考虑核心功能即可。
4 针对此事件的解决方案是什么？有什么直接有效的建议？
> 不使用root启用redis服务，或者用低权限的用户启用
> 修改redis.conf配置文件
增加
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG ""
rename-command EVAL ""
将这几个危险命令废掉
增加
requirepass 密码
有主备的，在备机也要配置
masterauth 密码
增加访问控制
bind 多个IP地址（仅限指定IP可以访问），这个也应该可以通过linux防火墙控制 这一个不应该算是程序的漏洞，属于管理的漏洞，就相当于家里的门天天不锁，或者是天天车门都不关。
页:
[1]
2