黑客攻防Redis拉锯战之Root提权

转载来源：记一次重大安全事故，黑客攻防Redis拉锯战之Root提权 ：http://www.safebase.cn/article-259347-1.html

摘要: 黑客攻击前言要想做一名优秀的程序员，除去个人扎实的基础技能这一不可或缺的因素，还有一个更加不能忽略的潜在意识。那就是——安全防范意识！为什么说，安全防范意识会成为另外一个不可或缺的因素，你且听我慢慢道来。服务器被植入木马linux其实这件事情呢，也就发生在前几天。公司需要部署一套新的 …

前言

要想做一名优秀的程序员，除去个人扎实的基础技能这一不可或缺的因素，还有一个更加不能忽略的潜在意识。

那就是——安全防范意识！

为什么说，安全防范意识会成为另外一个不可或缺的因素，你且听我慢慢道来。

服务器被植入木马

linux

其实这件事情呢，也就发生在前几天。

公司需要部署一套新的系统到Linux服务器上，这个任务便分到了一个某一同事身上，其中用到了Redis作为缓存服务。

系统跑了几天，正常运行也没有发生什么意外，可忽然有一天，Redis服务无法响应了！包括其他局域网内的服务器也跟着接连中招。

紧接着迅速开始排查 ps -er 查看当前启动的所有进程，结果找不到之前运行正常的服务。并且查看到当前服务器各项指标运行颇高，CPU已达到98%。

刚开始还以为是服务器负载过高，或者服务器内存不够导致进程奔溃，所以随便清理了一下服务，就将异常停掉的进程重新启动。但是这个时候却启动不了任何服务，所有被停掉的服务再次启动时都报端口被占用的错误日志。

病毒

我意识到，这应该是中病毒，被黑客入侵了。

所以立马开始病毒排查，果然在 crontab -l （如果crontab -l查不到定时任务，就使用vi /etc/crontab里面查看）里找到了一个定时任务，每隔15秒访问一个叫做lsd.systemxxxxxx.org （具体地址就不透露了，以防小伙伴们被挂入木马）

挖矿病毒

对于病毒的查杀，毕竟我不是专业的运维人士，后来交给了运维小伙伴去解决。

很多人看到这里，以为问题已经解决了，但其实这只是恢复到一个状态，只要没找到问题发生的原因就永远存在安全隐患。

Redis漏洞提权Root
后来通过云盾分析到可能是存在Redis漏洞提权行为。

安全分析

这里是摘要阿里云对Redis漏洞提权的描述

漏洞描述

• Redis 因配置不当存在未授权访问漏洞，可以被攻击者恶意利用。

  在特定条件下，如果 Redis 以 root 身份运行，黑客可以给 root 账号写入 SSH 公钥文件，直接通过 SSH
  登录受害服务器，从而获取服务器权限和数据。

  一旦入侵成功，攻击者可直接添加账号用于 SSH 远程登录控制服务器，给用户的 Redis 运行环境以及 Linux
  主机带来安全风险，如删除、泄露或加密重要数据，引发勒索事件等。

受影响范围

• 对公网开放，且未启用认证的 Redis 服务器

也就是说，我们的服务器被入侵，被当成“肉鸡”挖矿了。

挖矿

挖矿本身就需要较高配置的计算机来运行解密程序，而往往这些配置较高的计算机所消耗的资源也是巨大的。

而企业本身较高配置的服务器就成了不二之选，配置又高，带宽也不差。 能够入侵一下，代替成为黑客的挖矿资源，这可是一件肥差！

Redis漏洞解决方案
那找到了问题原因，就要开始去着手解决问题了。

解决方案

一、设置Redis的访问密码

很多人启动Redis就直接启动了Server，没有去加入密码访问权限，这是最危险的。

在 redis.conf 文件中找到 “requirepass” 字段 ，在后面填上密码。

requirepass !@QEJ1H23YGY233

这里要确保密码的复杂性。

二、绑定需要访问IP

默认情况下，redis.conf 文件中 “ bind 127.0.0.1 ”，仅本地可以访问，这样也大大加强安全性。

bind 127.0.0.1

但还有一种情况是需要将Redis挂在到另外一台服务器上，进行多服务器调用，这样就加大了危险系数。

做法是将 “bind 127.0.0.1” ，改成需要访问此IP地址，或者直接清空，并且将 ”protected-mode yes“ 改为 no，如果不关闭保护模式，其余服务器是无法访问的。

在 redis.conf 文件中找到 “requirepass” 字段 ，在后面填上密码。

bind xxx.xxx.xxx.xxx
protected-mode no

三、更改Redis端口号

更改Redis的端口号，是为了加大了黑客入侵的难度。

port 6111
pidfile /var/run/redis_6111.pid 

四、隐藏重要命令

Redis 无权限分离，其管理员账号和普通账号无明显区分。攻击者登录后可执行任意操作，因此需要隐藏以下重要命令：FLUSHDB, FLUSHALL, KEYS,PEXPIRE, DEL, CONFIG, SHUTDOWN, BGREWRITEAOF, BGSAVE, SAVE, SPOP, SREM, RENAME,DEBUG, EVAL。

另外，在 Redis 2.8.1 及 Redis 3.x （低于 3.0.2） 版本下存在 EVAL 沙箱逃逸漏洞，攻击者可通过该漏洞执行任意 Lua 代码。

# Example: 危险命令重命名 设置好UUID 自己记下来 避免以后要使用
rename-command CONFIG 这里为UUID
rename-command FLUSHALL 这里为UUID
rename-command FLUSHDB 这里为UUID
rename-command EVAL 这里为UUID
...

五、服务运行权限最小化

因为安全的问题，需要将系统中root运行的redis服务转为普通用户运行，提高安全性。
1.创建普通用户

#新建invoke用户组
$ groupadd invoke 
#新建用户redisuser并加入invoke组中，并设置密码 
$ useradd redisuser -g invoke -p XXXXX 

2.将redis的配置文件复制一份到普通用户的家目录下

#强制复制redis的配置文件到redisuser用户的家目录下 
$ cp -rf /usr/local/redis/redis.conf /home/redisuser/ 

3.修改配置文件中redis运行使用到的相关文件目录的路径

# 6111 是端口号，修改为自己自定义的端口号
pidfile /var/run/redis_6111.pid 
#修改成为 
pidfile /home/redisuser/run/redis_6111.pid 

4.在普通用户根目录下创建这个文件目录

$ mkdir /home/redisuser/run 

5.以普通用户去运行Redis

$ su - redisuser
$ cd /home/redisuser
$ redis-server /home/redisuser/redis.conf

六、设置防火墙策略

如果正常业务中 Redis 服务需要被其他服务器来访问，可以通过 iptables 策略，仅允许指定的 IP 来访问 Redis 服务。

# xxx.xxx.xxx.xxx 为指定ip
# 6111是Redis端口号
iptables -A INPUT -s xxx.xxx.xxx.xxx -p tcp --dport 6111 -j ACCEPT

结语

奔溃

这一次的安全事故只不过是在我们日常开发工程中的一些案例，而像“XSS”、“SQL注入”等等安全隐患都需要我们去注意。

http://www.safebase.cn/article-259347-1.html