zoukankan      html  css  js  c++  java
  • Redis数据库漏洞防护

    Redis是一个高性能的数据库,Redis Crackit及Redis安全漏洞本质上是由于Redis自身缺乏安全防护机制,同时Redis的使用者又未曾遵循官方的安全规范所导致的。

    Redis安全漏洞

    对于安全漏洞的防护,很多面向大数据的应用架构(NOSQL、Caching)都存在类似的问题。这些架构在设计之初并没有考虑到相关的安全问题,又或者设定了架构的应用环境,不允许暴露在公共场景中。但大多数用户在部署及使用这些应用架构的过程中,似乎忽略了这些问题,那么随着使用量级的不断提升,终有一天攻击者盯上了它们。

    so,此次Redis安全漏洞事件的关键并不在Redis本身,而是在于利用技巧,而这个Redis漏洞利用的方法就是Redis之父Antirez自己公布的。后来这个利用方法及PoC,被攻击者们所使用,于是 Redis Crackit事件出现了。

    Redis安全漏洞利用

    在此次的Redis安全漏洞事件中,攻击者采用了如下方式进行漏洞利用:

    先通过ssh-keygen产生一对密钥对,然后将公钥写到一个临时文件中,清空redis数据,将临时文件的内容写到redis, 
    再通过redis config命令设置存储文件为authorized_keys,这样就将linux系统中的authorized_keys全给覆盖了, 
    最后通过密钥登录。

    Redis安全漏洞影响

    一旦入侵成功,Redis数据会丢失,攻击者可直接添加账号用于ssh远程登录控制服务器,会给用户的 Redis 运行环境以及 Linux 主机造成安全风险,引发重要数据泄露。

    Redis 安全检测

    首先我们通过几步简单的命令来查看redis的一些常用配置。第一步检测redis的监听地址,可通过如下命令来检测:

    root@kali:~# netstat -anp|grep 6379
    tcp        0      0 0.0.0.0:6379            0.0.0.0:*               LISTEN      12377/redis-server`   

    从上例可以看出redis监听在任意地址的6379端口上,同时运行的进程号是12377,接着我们看redis运行的用户,可通过ps命令来实现。

    `root@kali:~# ps -elf|grep 12377
    5 S root     12377     1  0  80   0 -  8979 -      03:39 ?        00:00:00 redis-server     /etc/redis/redis.conf`  

    可以看出redis是以root 用户运行着。看完运行用户之后,我们接着看redis是否设置了相应的密码,可通过如下命令实现:

    root@kali:~# redis-cli -h 192.168.10.212
    redis 192.168.10.212:6379> keys *
    1) "1"`        

    keys *的输出结果来看,没有报出 not permit的错误,说明未设置用户名、密码,当然这些配置也可从redis的配置文件查看,默认配置文件为/etc/redis/redis.conf.

    如果您的配置基本上如上,root用户运行,监听在任意地址上,还未设置复杂密码,那么您就得赶紧加固了,这种方式不仅能外连shell,甚至搞定ssh连接。

    Redis 加固

    在redis常见安全检测中讲到几种查看常见安全配置的方法,接着阐述了如何构造和利用redis来实现ssh登录,其中涉及到的redis crackit不要轻易实验,一个是会清空redis数据,第二个是覆盖原先的authorized_keys,导致以前的密钥失效。所以最重要的还是如何加固你的redis,下面接着讲述redis的加固,主要涉及网络,认证, 权限分离,重命名重要命令等方面。

    网络加固

    绑定127.0.0.1

    redis默认是监听的127.0.0.1上,如果仅仅是本地通信,请确保监听在本地。这种方式缓解了redis的风险,当然并不能绝对保证安全了,假如攻击者有了一个webshell,并且redis以root用户运行,就可以通过该redis来反弹shell,来实现提权。 在/etc/redis/redis.conf中配置如下:

    `bind 127.0.0.1` 

    设置防火墙

    如果需要其他机器访问,或者设置了slave模式,那就记得加上相应的防火墙设置,命令如下:

    `iptables -A INPUT -s x.x.x.x -p tcp --dport 6379 -j ACCEPT`

    如果是Ubuntu那就更简单了,ufw直接搞定。

    认证

    redis 默认没有开启密码认证,再加上redis的运行速度极快,一秒能跑十多万个密码,一般的密码用处都不大。如何开启呢?还是打开/etc/redis/redis.conf配置文件,写上 requirepass @nsF0cus!@#

    这样就将认证密码设置为了@nsF0cus!@#,一定得保证足够的密码复杂度,redis没有做频率和次数限制。做了密码认证,保存redis.conf,重启redis(/etc/init.d/redis-server restart)之后,需要执行auth @nsF0cus!@#,示例如下:

    root@kali:~# redis-cli -h 192.168.10.212
    redis 192.168.10.212:6379> keys *
    (error) ERR operation not permitted
    redis 192.168.10.212:6379> auth @nsF0cus!@#
    OK` 

    强烈推荐通过sha256sum来构造密码,密码基本上难以猜测,毕竟这个密码不需要我们记住,只需配置在配置文件中即可。

    root@kali:~# echo -e "xxlegend"|sha256sum
    b59869cac63a67e7ee97e6923a75811ff58bd4936ed3be3480b46145d43ae335`

    在登录的时候的时候输入密码:

    redis-cli -p 6379 -a b59869cac63a67e7ee97e6923a75811ff58bd4936ed3be3480b46145d43ae335

    先登陆后验证:

    redis-cli -p 6379
    redis 127.0.0.1:6379> auth b59869cac63a67e7ee97e6923a75811ff58bd4936ed3be3480b46145d43ae335

    AUTH命令跟其他redis命令一样,是没有加密的;阻止不了攻击者在网络上窃取你的密码;

    认证层的目标是提供多一层的保护。如果防火墙或者用来保护redis的系统防御外部攻击失败的话,外部用户如果没有通过密码认证还是无法访问redis的。

    低权限账户

    设置一个单独的redis账户很有必要,redis crackit就利用到了root用户的特性来重置authorized_keys。首先创建一个redis账户,然后通过该账户启动。

    setsid sudo -u redis /usr/bin/redis-server /etc/redis/redis.conf

    启动之后应该如下:

    root@kali:~# ps -elf|grep redis
    1 S redis    14720     1  0  80   0 -  8979 -      08:40 ?        00:00:00 /usr/bin/redis-server /etc/re

    重命名一些重要命令

    由于redis没有做基本的权限分离,没有管理账号,普通账户之分,所以登录上去之后什么操作都能做,实在是太可恶了。因此需要将一些危险的操作隐藏起来,涉及的命令包括

    `FLUSHDB, FLUSHALL, KEYS, PEXPIRE, DEL, CONFIG, SHUTDOWN, BGREWRITEAOF, BGSAVE, SAVE, SPOP, SREM, RENAME, DEBUG, EVAL` 

    其中在redis2.8.1和Redis Redis 3.x (< 3.0.2)有eval沙箱逃逸漏洞,可执行任意lua代码。 设置方法如下,还是编辑redis.conf文件

    rename-command CONFIG ""
    rename-command flushall ""
    rename-command flushdb ""
    rename-command shutdown shutdown_dvwa

    上述配置将config,flushdb,flushall设置为了空,即禁用该命令,我们也可以命名为一些攻击者难以猜测,我们自己却容易记住的的名字。保存之后,执行/etc/init.d/redis-server restart 重启生效。

    备注:

    本月12日,绿盟远程安全评估系统(NSFOCUS RSAS)升级后,已经可以检测到此次Redis漏洞。

    参考文献:

    (1)http://antirez.com/news/96

    转载请注明:“转自绿盟科技博客”: 原文链接.

  • 相关阅读:
    zoj 1239 Hanoi Tower Troubles Again!
    zoj 1221 Risk
    uva 10192 Vacation
    uva 10066 The Twin Towers
    uva 531 Compromise
    uva 103 Stacking Boxes
    稳定婚姻模型
    Ants UVA
    Golden Tiger Claw UVA
    关于upper、lower bound 的探讨
  • 原文地址:https://www.cnblogs.com/rinack/p/11099854.html
Copyright © 2011-2022 走看看