记一次小小的redis攻击
背景
前一段时间测试环境(阿里云)上面的redis环境,老是莫名其妙的消失key被清空,一般是晚上出现攻击,时间不定,一开始因为不冲突也没怎么管,毕竟测试环境,不过后来到底还是觉得不舒服,还是看看
研究
首先是用redis的管理后台打开看了一下,发现有一个很长的key被保留了下来,我研究了一下,感觉应该是类似于sql注入里面的SQL Column Truncation”的攻击方式
在某些情况下，将会导致发生一些安全问题。在MySQL的配置选项中，有一个sql_mode选项。当MySQL的sql-mode设置为default时，即没有开启STRICT_ALL_TABLES选项时，MySQL对于用户插入的超长值只会提示warning，而不是error（如果是error则插入不成功），这可能会导致发生一些“截断”问题。
我猜redis里面应该是有类似的工具漏洞,通过这样的方式实现类似于sql注入的形势.然后因为我们测试服用的redis下的docker,所以限制了内存导致他的攻击清空了其他的键值对.然而因为docker的原因,他也只能拿到有限的数据和资源.没办法跑到docker外面去.
令人感慨现代技术的发展还是大大压缩了攻击的防御的压力,如果是早年这样的漏洞,估计早就测试服爆破成功了.
迷你攻防战
既然是攻击找到了就可以找方法了应对了,首先是端口开放和限制ip访问.首先是把默认端口换了,这个确实是之前疏忽了,不过也没什么测试服么,每个人的权限都拉的老高了.也没考虑那么多.
ip限制倒是没做,权衡了一下,毕竟大家经常在家用,很多时候甚至会有稀奇古怪的玩法,比如连接外网服务器然后在连接测试服.
然后就是试图加密码.因为一些原因搞了好几天.大概是当时比较忙着上线新的需求,然后挂在测试服的和同事的管理后台又是不同版本的语言的代码.
结果密码没加只改端口还是没用,估计是被上了人家的肉鸡名单里面,改了端口继续扫描.后来花了几个小时统一换了密码访问,就顺利结束了.再也没有发现redis被攻击.
端口的小小往事
之前看人老外的一次攻防战,说的是某地的qq,用的memcache,结果端口是默认端口,就被人开了,放了出来,还是印象深刻,那哥们还是著名佬佬佬.看来端口还是要换,不要用默认端口
|