Redis被入侵之后

发表于   |   分类于   |  

之前开发的东华车管OBD的数据采集端一直比较稳定，所采用的技术方案是以Netty为网络框架，以Redis作为消息队列和存储工具，进行数据采集、存储和发送，虽然经历了不少问题，但是经过一段时间的处理之后，相对来说还是比较稳定的，最长时间连续运行近一个月没有出现过任何问题，不过最近我们的服务端几乎每天都崩溃，这让我非常的纳闷，已经稳定运行了好几个月的平台从未出现过如此严重的稳定性问题，所以我也非常重视这个Bug，以最快的时间开始着手解决问题。

Bug的内容是这样的：

1
2
Could not get a resource from the pool
java.lang.NullPointerException

第一句是说，没办法从jedis连接池里获取jedis对象了，第二句是说，空指针异常了。
从错误的本身理解，我的第一反应是，坏了，是不是我的Jedis连接池没有正常回收，导致连接池中的连接数被用完了？
当然我是比较怀疑的，因为：
1.采集的车辆数据并不多，由于并发造成的连接池连接数被用完的可能性微乎其微。
2.运行了好几个月了都没有出现这种情况，在车辆没有大批量增加且车辆总数并不多的情况下，怎么可能突然就开始出现这种问题呢？
但是，Bug is Bug,该解决你就得解决，所以我就立即从连接数回收的方向去入手，看看是不是我的Jedis写的有问题。

虚惊一场

通过谷歌，我找到了别人写的Jedis服务类：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// 生成多机连接信息列表
List<JedisShardInfo> shards = new ArrayList<JedisShardInfo>();
shards.add( new JedisShardInfo("127.0.0.1", 6379) );
shards.add( new JedisShardInfo("192.168.56.102", 6379) );

// 生成连接池配置信息
JedisPoolConfig config = new JedisPoolConfig();
config.setMaxIdle(10);
config.setMaxTotal(30);
config.setMaxWaitMillis(3*1000);

// 在应用初始化的时候生成连接池
ShardedJedisPool pool = new ShardedJedisPool(config, shards);

// 在业务操作时，从连接池获取连接
ShardedJedis client = pool.getResource();
try {
    // 执行指令
    String result = client.set("key-string", "Hello, Redis!");
    System.out.println( String.format("set指令执行结果:%s", result) );
    String value = client.get("key-string");
    System.out.println( String.format("get指令执行结果:%s", value) );
} catch (Exception e) {
    // TODO: handle exception
} finally {
    // 业务操作完成，将连接返回给连接池if (null != client) {
        pool.returnResource(client);
    }
} // end of try block// 应用关闭时，释放连接池资源
pool.destroy();

我又看了看我的Jedis回收写法：

1
2
3
4
5
6
7
8
9
10
public static void close(Jedis jedis) {
	try {
		jedis.close();
	} catch (Exception e) {
		if (jedis.isConnected()) {
			jedis.quit();
			jedis.disconnect();
		}
	}
}

发现了和人家写的怎么不一样啊？
这句：

1
pool.returnResource(client);

我怎么没有写啊？
当时大骂自己粗心，回收方法都没写对怎么就能心安理得的发布程序呢？于是赶紧打开IDE加上这句话，可是当我在我的程序中加上上边这句代码的时候，突然发现这行代码是被遗弃的了，旁边写着提示：

Deprecated. starting from Jedis 3.0 this method will not be exposed. Resource cleanup should be done using @see redis.clients.jedis.Jedis.close()
意思是Jedis 3.0以后，这句代码已经被jedis.close()方法替代了，所以我的写法是没有问题的，之前是虚惊一场。

初见端倪

好不容易缓口气，但是依旧迷茫，既然我的回收写法是正确的，那为什么我的服务突然就无法从连接池获取连接了呢？
带着一头的雾水，我开始在服务器的Redis服务上找原因。
当时我怀疑的是，是不是Redis的服务挂了？第一反应去WIndows的服务里去看，结果发现没有挂，正常运行中。
我想既然没挂，那我连接一下看看吧。
于是就用redis-cli命令直接连接服务，连上了没问题。
然后想说 看看缓存队列中还存着哪些数据吧？
于是就打了一个命令：

1
lrange obdMessage 0 -1

结果Redis直接报了警：

1
NOAUTH Authentication required

这里突然感觉不太对劲了，怎么好好的报了这个错误呢？而且我的Redis是有密码的，不过很简单是 111111
我赶紧用命令：

1
auth 111111

来访问我的Redis，结果还是报错，直到这里我才发现，可能是我的Redis访问密码被人动了手脚。

着手解决

于是我重启了Redis的服务，看看重启后能不能访问Redis,结果还好，重启后Redis是可以访问了，我在查看存储的数据的过程中，突然发现好像多了一个字段：crackit。
然后我去网上一搜，出现这个Crakit就说明我的Redis肯定是被人入侵了，那么很有可能就就是我的Redis被人入侵之后，黑客改了我的Redis的密码，导致我的Redis无法使用。

入侵的漏洞：

Redis 默认情况下，会绑定在 0.0.0.0:6379，这样将会将 Redis 服务暴露到公网上，如果在没有开启认证的情况下，可以导致任意用户在可以访问目标服务器的情况下未授权访问 Redis 以及读取 Redis 的数据。攻击者在未授权访问 Redis 的情况下可以利用 Redis 的相关方法，可以成功在 Redis 服务器上写入公钥，进而可以使用对应私钥直接登录目标服务器。
入侵的特征：
Redis 可能执行过 FLUSHALL 方法，整个 Redis 数据库被清空
在 Redis 数据库中新建了一个名为 crackit（网上流传的命令指令） 的键值对，内容为一个 SSH 公钥。
在 /root/.ssh 文件夹下新建或者修改了 authorized_keys 文件，内容为 Redis 生成的 db 文件，包含上述公钥
修复建议：
1.当然就是改密码了，之前的密码太弱了，可能是不是被人家给碰上了，直接就破解了，赶紧改一个复杂一点的密码才是王道，如果你的Redis连密码都没有，那更不行了，看看我的遭遇，赶紧加上密码吧！
在Redis服务的配置中加入密码项目，默认是注释的，你要手动加入密码，打开配置文件找到：

1
#requirepass foobared

去掉之前的注释，并修改为所需要的密码，保存文件并重启Redis服务。
启动命令是：

1
redis-server --service-install redis.windows-service.conf --loglevel debug

注意 –loglevel debug ，这里是加入了日志的启动方式,也是要在配置文件中进行修改的，打开配置文件找到：

1
loglevel verbose

去掉注释并改为：

1
loglevel debug

并且由于要存放日志的话则要给存放的Redis日志启用存储路径,在配置文件中搜索”logfile“就可以了，然后给其指定路径：

1
logfile "Logs/redis_log.txt"

注意:这里改完后，要启动服务前，在你的Redis的安装目录的根目录下手动创建一个名为”Logs”的文件夹，如果缺少这个文件夹，启动服务的时候会报错。
2.改端口号，默认的6379端口肯定是不能用了，赶紧在redis的配置文件中修改端口号吧！
在Redis的配置文件中找到：

1
port 6379

改为别的未被占用的端口即可。
3.禁止一些高危的命令：
修改Redis的配置文件,加入以下几行命令：

1
2
3
4
5
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command KEYS ""
rename-command CONFIG ""
rename-command EVAL ""

﹡以下的一些设置是网上的，我没用用，因为不适合我的情况，仅供参考：
4.以权限运行Redis服务
为 Redis 服务创建单独的用户和家目录，并且配置禁止登陆
5.禁止外网访问 Redis
修改Redis配置文件，添加或修改：

1
bind 127.0.0.1

使得 Redis 服务只在当前主机可用

总结

浅薄啊！粗心啊！一切的一切都是因为自己在服务器和Redis安全性这里不够重视而导致的问题，其实只要设置一个复杂一点的密码，估计也不会这么轻易的被入侵了，希望我的遭遇能给你带来一些启发，少走或者不走弯路，赶紧加固自己的Redis安全防御吧！

热评文章