redis全部key莫名消失——redis被攻击

最新推荐文章于 2024-08-05 10:42:15 发布

iteye_10

最新推荐文章于 2024-08-05 10:42:15 发布

阅读量4.5k

点赞数

分类专栏： redis 数据库文章标签： redis ssh

本文链接：https://blog.csdn.net/iteye_10/article/details/82645194

版权

数据库同时被 2 个专栏收录

5 篇文章 0 订阅

订阅专栏

redis

2 篇文章 0 订阅

订阅专栏

本文记录了一次Redis数据莫名消失的事件，分析原因是由于未设置密码及默认端口导致黑客扫描并清空Redis数据库。黑客还尝试通过输入SSH公钥以实现对服务器的控制。解决方案包括以非root权限启动Redis，设置密码验证，限制公网访问Redis端口，以及检查authorized_keys文件。

摘要由CSDN通过智能技术生成

redis全部key莫名消失——redis被攻击

刚刚接触redis不久，对redis也只是做了一些简单的配置，所以，在刚刚使用的时候，也仅仅是将redis的环境搭建好，至于redis的端口（6379）和密码（redis默认配置没有密码）也没有做更改。

前一段时间，偶然的发现，有时候redis里面的数据莫名其妙的全部被清除掉了，刚开始总是以为是redis哪里配置的有问题，可能配置的有定时清空数据库的机制吧，但是找了一圈没有发现redis有类似的配置。随后开始研究redis.conf配置文件，首先将redis的log级别提升到最高，也就是debug的级别，
debug的打印信息如下：
[16279] 08 Dec 17:39:09.340 - DB 0: 70 keys (0 volatile) in 128 slots HT.
[16279] 08 Dec 17:39:09.340 - 0 clients connected (0 slaves), 829448 bytes in use
[16279] 08 Dec 17:39:13.047 * 10 changes in 300 seconds. Saving...
[16279] 08 Dec 17:39:13.047 * Background saving started by pid 16324
[16324] 08 Dec 17:39:13.070 * DB saved on disk
[16324] 08 Dec 17:39:13.071 * RDB: 0 MB of memory used by copy-on-write
[16279] 08 Dec 17:39:13.147 * Background saving terminated with success
[16279] 08 Dec 17:39:14.349 - DB 0: 70 keys (0 volatile) in 128 slots HT.

会将当前连接的客户端个数，你使用的数据库，当前存储的key个数，设置过期的key个数(0 volatile)，快照的保存时间，状态，打印出来。当有客户端连接，会将客户端的ip打印
[16279] 08 Dec 17:40:05.187 - Accepted 123.57.41.84:44459

过了大概两天左右，又发现数据被清除了，这时在看看redis的log
[16279] 10 Dec 07:05:39.105 - DB 0: 78 keys (0 volatile) in 128 slots HT.
[16279] 10 Dec 07:05:39.105 - 0 clients connected (0 slaves), 856544 bytes in use
[16279] 10 Dec 07:05:40.468 - Accepted 221.194.44.175:34038
[16279] 10 Dec 07:05:40.508 * DB saved on disk
[16279] 10 Dec 07:05:40.530 - Client closed connection
[16279] 10 Dec 07:05:40.565 - Accepted 221.194.44.175:34041
[16279] 10 Dec 07:05:40.584 - Accepted 221.194.44.175:34042
[16279] 10 Dec 07:05:40.627 * DB saved on disk
[16279] 10 Dec 07:05:40.627 - Client closed connection
[16279] 10 Dec 07:05:40.627 - Accepted 221.194.44.175:34043
[16279] 10 Dec 07:05:40.645 - Client closed connection
[16279] 10 Dec 07:05:40.660 - Client closed connection
[16279] 10 Dec 07:05:40.681 - Accepted 221.194.44.175:34045
[16279] 10 Dec 07:05:40.705 - Client closed connection
[16279] 10 Dec 07:05:40.722 - Accepted 221.194.44.175:34047
[16279] 10 Dec 07:05:40.736 - Client closed connection
[16279] 10 Dec 07:05:44.136 - DB 0: 1 keys (0 volatile) in 4 slots HT.
[16279] 10 Dec 07:05:44.136 - 0 clients connected (0 slaves), 755920 bytes in use

很明显，在七点零五分的时候还有78个key，此时有客户端连接上来，数据悲剧了，只剩下了一个key，立马打开redis的aof文件，看看是不是此时有人执行了清空redis的操作

$8
flushall
*3
$3
set
$7
crackit
$398
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApC0OZYaozpKXFCagPTUQ0eqIXbeX+u/tSYDVrMpMXxswTxi9uZ4SKUsOKemVsGcp5YNGJ8HhB8KBoejGkTrAE7v9Sl5zwG6xMAjSj0ZBlcW80h4M0uC5Ntb95BX9bUBbUPJf70eZ5Phe2zrO9RM1Rd96HZxuFjNOw3JKMIs/Lw/qm33FIm4z1j9dnMJ5h7BYz1Fkr6hl12GvhpTZWcfgg/BzZsb0oAJGLJd5km6KPGmn0oJGMaqCbiD2ynfgQo0kpTlJExikfZe8BE0CAHAxrXNGb+cPOc1HZt7cwXQfo+Y88vG4BdfNRC1CyQTr8ZcIV7KUxSwsc/8HuUEuPVZm7Q== root@cloud
*4
$5

很明显的看到flushall的命令，就是将redis中所有的key清除，并且写了一个key为crackit的一堆有关于ssh的神马东西，ok当下百度了一下redis crackit，铺天盖地的redis被黑的新闻，好吧，终于知道原因了，由于没有设置密码，还有使用了默认的redis端口，黑客通过扫描redis的端口，不是用密码也可以连接到你的redis库中，既然连接了上来肯定是要来搞一些事情，把你的redis清空并不是目的，看到存入的那一段ssh的东西了吗，这个才是关键。利用redis将服务器的ssh公钥替换，也就是说如果你使用的root用户启动的redis，可以将自己的公钥或者其他恶意程序写入目标服务器中，从而可以直接控制目标服务器。

经过试验，确实可以使用ssh免密登录到目标服务器中（具体的步骤可以百度一下redis crackit）,

目前大多数人的解决方案：
1，以非 root 权限启动 Redis
2，增加 Redis 密码验证
3，禁止公网开放 Redis 端口, 例如可以在青云防火墙上禁用 6379 Redis 的端口
4，检查 authorized_keys 是否非法

也可以根据情况对服务器的ssh进行配置，例如免密登录