redis服务被病毒利用挖矿的一次真实经历

   因项目｛acs接入服务｝利用netty框架建立协议获取客户端数据，需要redis对这些大量数据做缓存。项目进展一个多月，还并未发现redis的使用存在异常。至2018年年初，在对传入数据做一些稳定性测试的时候，频繁发现数据存在间歇性读取异常（仪器的小时数据），一开始以为编写的代码可能存在逻辑性问题，通过逐步排查发现系统在获取redis的键Hour_Number参数｛记录appweb定时器截取的数据长度，acs数据更新时会重置长度并删除该长度旧数据，以此实现【截取】功能｝时存在异常，(但项目存在一个业务场景，在netty的一个连接｛表示一个线程｝中，在小时整点时会几乎同时触发实时、分钟、小时数据至redis的存储｛存数据｝，同时关联的appweb｛取数据｝却也几乎同时执行｛两者在日志中打印时间相差不过零点几毫秒｝，但两者执行的方法又比较长，因此一直觉得这里面对redis的操作可能存在问题，由于部分代码被组建化无法调试，因此打印日志希望重现问题找出原因｛日志也存在打印不全的情况，在后来直接看命令行打印发现这个问题｝）。周五重新部署了一遍。

   由于心有不甘，周六吃过中饭就又来公司看项目运行情况。这一看不要紧，发现又有数据丢失了，登录阿里服务器看项目运行情况，app｛竟然报空指针，一看代码redis数据没拿到｝，打开redis，键值app部分全没了｛问了下同事发现并非人为｝。此时还没意识到redis的db0有两个键｛以为是其他同事加进去的｝，在网上查询redis大量资料还以为是redis的键过期回收策略问题｛LRU淘汰策略点击打开链接｝。以下为DB0的两个键。

毫无头绪，就将db0删了｛单纯觉得不正常，这其实不符合逐点排除问题原则，但此时回想删了反倒帮我找出问题了｝，重启了一遍acs服务但未启动app，包括redis。意外发现键值又回来了，说明redis的持久化RDB备份文件并未被修改。问了下堂哥｛做redis中间件的，大神级人物｝，帮我排查问题，但都只能窄化问题范围，还未找到根源｛怪我描述重点不对！｝。再一次部署。

     至周六晚上7点到周末晚上12点，数据都运行正常。周一上班发现问题重现，同时删除的db0键又出现了，这让我不得不重视db0这两个键，看内容查了下ip地址，意大利IP.诸多的不正常意见如重磅炸弹的ip地址，让我不得不觉得，redis被攻击了。检索了下redis攻击资料，与情况相符｛redis没有配置密码【命令方式配置密码听说是临时的，断电失效】，未授权攻击｝。redis机制导致暴露外网任意访问。还好服务器是window的并未造成更严重影响｛该木马原来是针对linux的，这又不得不感叹，落伍原来也有好处！！！｝。

     网上的相关资料很多，就不一一描述了，根据实际情况｛目前几个服务都在一个阿里云服务器上｝，有如下几个方案：

1：设置绑定ip

修改redis.windows-service.conf文件｛redis服务端配置文件｝，bind 127.0.0.1 （多个ip绑定的意思是redis本机，redis所在局域网ip并非任意ip得｛很显然阿里服务器跟我公司不在一个局域网，只能写127.0.0.1，这样导致远程客户端是连接不上的，只能本机上连｝），最后｛最重要一步｝，让redis带配置启动，也就是配置文件改为redis.windows-service.conf。

     bat下完整命令为：

注：之前这个命令一直执行失败，后来发现是redis版本问题，换了一份网上的版本点击打开链接就行了。执行成功会生成log日志的。

总体来说这个方法是最安全的，但却是难以扩展的｛服务不在同一个服务器上时怎么办呢｝，而且观察数据也很不方便。

2：修改端口，授权访问

修改redis.windows-service.conf中port端口号如"6479",修改requirepass参数密码越长越好"UIHDH74593IOZHDSF$^*&(%$#$SDFF"｛另外命令方式配置密码断电会丢失，所以选则这种｝。

在redis.windows-service.conf中配置

rename-command FLUSHALL "" rename-command CONFIG "" rename-command EVAL ""
#来禁止远程修改DB文件

将redis.windows-service.conf文件设置只读权限。

以低权限启动redis：

如上步操作出现“此任务要求指定的用户帐户以批处理作业权限登录”，则需要登录cmd-》gpedit.msc计算机配置，为账户添加批处理权限。点击打开链接

另外别忘了redis文件夹给这个用户访问权限。

开启防火墙｛这一步没试过，禁止某ip访问｝。

待结果出来后期会补更！！！！