Redis 安全问题（redis的一些问题）

2015年， 很多redis节点都遭受到了攻击， redis中的数据全部被清除， 只包含一个名为crackit(换一个key就很难被发现了）的key， key的value为类似如下的公钥：

`ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCoqWfDFlTW1aG0aywc/n+f8H0DXcKJ/T5812jzo8jhgthtrOCo/C8x+R8q2KYgihO/anGtHk86Wr8Ng9Kciy495omc18aLHmq5v9TDT24ws//Gj8Rtqn3cEn6LhckDE+nYIrMTaFG164odAYUZJkJyYOxql5xnJzm1Dmlpjft8Se/fOOdtLn4sfyKntDVfVEAT1T5PRu6XS3RSuMUfDxxIhQsidZn5m+V+eHiJESSVhjEIFmbWcITyzwu+xd+/GlvyTtMWNZNB/03zlJY4KCnqMST8sAwQbHZT1JbMa4xL2RZQRONDZp2n7C3jCtNf/J67z4A6olCdaUKrSkh9lvJ5`，对用户的生产环境产生了很大的影响：

1. 将redis作为持久化数据库的产品， 引起数据丢失
2. 将redis作为缓存使用的产品， 因为从redis获取不到数据， 所用请求全部涌入到后端数据库服务器， 造成数据库服务器压力过大， 影响产品性能甚至数据库崩溃
3. redis服务器被植入了非法公钥， 以至于redis服务器被他人控制

那么攻击是如何发生的呢？简要说来有如下几个步骤：

1. 恶意扫描6379端口（redis 默认端口）， 确定包含redis服务， 并试图ssh登录， 因为Redis服务器并无攻击者public key， 登录失败

2. 使用redis 客户端连接redis服务器， 执行redis命令（del, flushdb， flushall)清除所有redis数据

3. 使用“config dir” 命令将 redis 数据备份路径至 /root/.ssh/

4. 使用“config filename”指定 RDB（redis定时备份） 备份文件名称为authorized_keys

5. 设置crackit key， 将value设置为恶意访问者的公钥

6. 执行bgsave， save动作触发RDB数据备份，将攻击者公钥存储在authorized_keys

7. 攻击者ssh到redis 服务器成功

redis本身要求redis部署在一个只有可信赖的client才可访问的安全环境， 因此包含如下建议：

1. 更改默认端口:

更改默认端口可以降低redis服务被发现的可能性， 但并不能完全制止， 攻击可以扫描其他端口并试图判定其为redis服务器

2. 增加redis密码验证，增加redis密码验证可有效防止redis服务器的恶意登录， 但redis但密码要足够复杂：

2.1 redis是基于内存的数据库， 访问速度十分快， 如果密码不够复杂， 则很容易被恶意破解

2.2 redis的密码传输是基于明文的， 如果攻击者在客户端和redisf服务器所属的网络之内， 还是可以截取到密码

3. 不要绑定所有网络接口

redis提供bind配置选项， 用于配置redis服务绑定都那个所在物理服务器的网络接口， 如果不指定则默认绑定所有网络接口， 如果服务器本身有外网地址， 则外网也可以访问

4. 使用非root用户启动redis服务

当redis被贡献后， 如果使用root启动服务器， 可能导致攻击者具有root用户权限， 对服务器危害较大， 因此尽量不要使用root用户

6. 更改命令名称防止破坏性命令的执行

redis支持rename操作更改命令名称， 如rename flushall abcdefg， renam后执行flushall命令则会提示命令不存在

rename的缺点是rename后的aof文件向前兼容， 即一个aof文件如果即包含rename前和rename后的command， 在导入其他redis实例时可能会失败