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`,对用户的生产环境产生了很大的影响:

将redis作为持久化数据库的产品, 引起数据丢失

将redis最为缓存使用的产品, 因为从redis获取不到数据, 所用请求全部涌入到后端数据库服务器, 造成数据库服务器压力过大, 影响产品性能甚至数据库奔溃

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实例时可能会失败

  • 发表于:
  • 原文链接:http://kuaibao.qq.com/s/20171210G0AGNF00?refer=cp_1026

扫码关注云+社区