Redis的初步搭建及被入侵经历

越来越觉得Redis的火热，同时日常开发中迫切需要用到，所以赶紧来充充电吧。

网上非常详细的介绍了Redis的来源、特点、数据结构、应用场景等。

在这里仅以一个新接触的入门者来自我总结下，Redis可以理解为以内存作为数据存储介质，因此读写效率极高，相比较于传统的关系数据库，如Mysql，非常适合存储读取频繁使用的数据。同时实现了持久化，不用担心数据丢失，支持多种数据结构，主从模式、配置集群什么的当然不在话下啦。

 

参考网上资料，记录一下自己简单搭建的过程，基于Linux(CentOS7.4)环境。

1.      下载Redis的源码

执行命令

wget http://download.redis.io/releases/redis-2.8.3.tar.gz

下载完成得到redis-2.8.3.tar.gz

2.      解压redis-2.8.3.tar.gz文件并编译

执行命令

tar –zxvf redis-2.8.3.tar.gz

cd redis-2.8.3

make

cd src

make install

3.      获取执行文件

进入到src目录，将以下下文件拷贝到自定义的redis目录

redis-server                   服务启动程序

redis-benchmark                性能测试工具

redis-cli                      客户端连接工具

redis-check-aof                数据修复工具

redis-check-dump               检查导出工具

mv redis-benchmark redis-check-aof redis-server redis-check-dump redis-cli/usr/local/Software/redis/bin

除了redis-server、redis-cli其它我都没使用过，后续希望能去了解深入学习下。

将根目录的配置文件拷贝到自定义redis目录

cd ../

mv redis.conf/usr/local/Software/redis/etc/

4.      启动Redis服务

cd /usr/local/Software/redis/

./bin/redis-server./etc/redis.conf

出现此界面即表示Redis服务启动成功了。

Redis安装和启动的教程，网上非常多，过程也比较简单，以上内容仅作为个人的总结。

下面聊聊自己一次被攻击的经历。

在搞定了redis后，继续安装了phpredis拓展，set、get、del玩的不亦乐乎。

为了不每次关闭命令行窗口导致redis服务被关闭，设置为守护程序。

daemonize默认为no，即开即用，若需要离开命令行窗口redis服务仍存在，设置为yes。

 

我就这么简单设置就让redis24小时运行着了，好像过了一天两天？记某天下午，邮箱不停的接收着阿里云的警告邮件，具体内容记不清了，邮件太多，我也清了邮箱。内容大概是说6379对外进行ddos攻击。当时正在外面准备一件大事，看着不断嘀嘀嘀通知的邮件和短信，我是懵逼的。总之打开电脑先把redis关了再说吧。

晚上闲余时间，想好好看看服务器到底咋滴了。操作下普通指令，很明显的感觉服务器卡起来。这比较奇怪，毕竟我只是个linux的初学者，没有乱安装程序，也没有乱开服务。

思考片刻，使用top命令，发现一个进程占满了CPU使用率。我用了比较错误的做法，想着用kill指令去杀进程，kill后，发现恢复了响应速度，但是没隔多久，进程又出现了！这次我再用ps –ef | grep xxx，发现类似/tmp目录增加了文件。我就rm –rf和kill齐上阵，结果是只消停一会儿，又出现了文件和进程。

先对自己吐槽一下，没有无缘无故出现的非法进程，直接kill的做法真是太蠢了，一定要了解进程的来源，追根究底知其源才是正确做法。

嗯，又思考了片刻。既然杀了进程和删了文件每隔多久都会恢复，那是存在一个定时检测吗？想到了会不会是crontab的定时器导致的，一看，crontab –e。果真，每间隔5秒，一次curl和一次wget。可惜自己没有截图下来，也没仔细分析。发现了就赶紧删，给自己一个差评。。

 

在格式化了crontab和进程文件齐删之后，稍微等待会儿时间确实没出现了。不过随之而来的一个新疑问，这密码我刚新设置没多久，且复杂度也够高，应该不大可能破解了密码入侵了吧~。突然近期git的使用来了点感觉，为了让本地仓和远程仓库免密交互可折腾了好久。有兴趣的同志们网上一搜，Linux实现免密登录，一查一个准。

果然~/.ssh/authorized_keys里面塞满了不明key。结合阿里云的邮件内容，联想到难道是因为redis未设置密码被人非法连接，然后把本地的公钥写入到这里？

 

现在模拟入侵连接上redis。（当然我现在设置了密码哈哈~）

可以获取到数据保存到硬盘的目录及文件名

同理现在进行路径及文件名的更换

就这样轻松的改了文件名及保存目录。

再将公钥写入到redis，执行save命令，ssh root@xxx，直接登录成功

这里有个疑问，如果/root/.ssh文件夹不存在，那还能成功吗？

至少我在把.ssh文件夹删了后，dir是无法设置的。在网上找资料好像也都默认了.ssh存在。

但是既然能够通过redis注入文件了，实测完全可以通过写入crontab来生成.ssh文件夹。所以说只要存在redis被连接的情况，就像是敞开了大门。

再后续查阅发现，其实这是一个大众所知的坑了，但是对刚接触redis的人来说还真想不到。

所以总结下能避免该漏洞的方法：

1.      设置密码

2.      将redis的启动用户降级，设置为非root，类似写入crontab操作执行权限不会这么大

3.      绑定访问IP