最近集团安全部扫描到我们组的redis没有设置密码。如何扫描的?一个脚本,登陆到服务器上查看固定路径下的redis配置,没有配置密码就被扫出来。简单无脑暴力。
于是开始虐心的添加redis密码之旅。
Server端配置
方法1:redis-cli -h xxx -p xxx CONFIG SET requirepass xxx
方法2:修改redis.conf文件,配置requirepass
对于twemproxy,可以升级到最新版本,然后配置redis_auth xxx。
Client端配置(Jedis)
项目中都是用的JedisPool。我们的方案是给所有代码进行如下处理:
1 2 3 4 5 6 7 8 9 10 11 12 |
... var jedis: Jedis = null try { jedis = jedisPool.getResource try{jedis.auth(password)}catch {case Exception=> } ///捕获一切异常,如果redis没有设置密码,这里的异常会被捕获,不影响后续操作 ... } finally { if (jedis != null) { jedisPool.returnResource(jedis.asInstanceOf[BinaryJedis]) } } ... |
看起来应该没问题,实际上测试了下,也一切ok,于是开始了第一次改密码尝试。将涉及到的七八个应用、几十处代码全部修改完毕上线后,一切正常。然后redis server端添加密码,瞬间崩溃了四五个服务,只剩两三个服务正常运转。于是立马去掉密码,开始查原因。
JedisPool初始化的坑
1 |
public JedisPool(final Config poolConfig, final String host, int port, int timeout, final String password, final int database) |
经过一轮排查,发现出问题的服务都是用的上面的方式初始化JedisPool。而没有出问题的都是下列方式初始化:
1 |
public JedisPool(final Config poolConfig, final String host, final int port, final int timeout) |
然后看了下源码,果然在有database参数且不等于0时,会进行一次select操作,而我们的password用的是null,所以就会报错。于是又一次将涉及到的七八个应用、几十处代码全部修改完毕,开始第二次改密码尝试。所有应用上线后,一切正常。开始redis server端添加密码,瞬间又是几个服务崩溃,几个服务正常。于是立马去掉密码,开始第二次查原因。
setTestOnBorrow的坑
又一轮排查后,发现出问题的服务都是
还好,没有其他幺蛾子了,这次终于没有问题,加上密码,去掉密码,服务都正常运转。心塞。
哥们,我问个问题,你把testOnborrow去掉了。。如果得到的jedis资源是个不可用的,服务从来都不出问题么?
哥们,我问个问题,你把testOnborrow去掉了。。如果得到的jedis资源是个不可用的,服务从来都不出问题么?