首先SSH登陆，top查看进程，发现奇怪名字的命令gejfhzthbp,一看就感觉有问题。
 

　　lsof –c gejfhzthbp

　　查看关联文件，发现对外的tcp连接，不知道是不是反向shell…

　　执行命令

　　Whereis gejfhzthbp

　　ls -al gejfhzthbp

　　查看文件路径。并查看文件创建时间，与入侵时间吻合。

　　顺便把文件拷贝下来放到kali虚拟机试了下威力，几秒钟的结果如下…

　　之前还以为是外国人搞的，这应该能证明是国人搞的了…

　　恢复业务

　　首先kill进程，结果肯定没那么简单，进程换个名字又出来了

　　中间尝试过很多过程，ps –ef |grep 发现父进程每次不一样，关联进程有时是sshd，有时是pwd，ls，中间装了个VNC连接，然后关闭ssh服务，同样无效，而且kill几次之后发现父进程变成了1 ，水平有限，生产服务器，还是保守治疗，以业务为主吧…

　　既然被人入侵了，首先还是把防火墙的SSH映射关掉吧，毕竟服务器现在还要用，还是写几条iptables规则吧

　　iptables -A OUTPUT -o lo -j ACCEPT

　　允许本机访问本机

　　iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT

　　允许主动访问本服务器的请求

　　iptables -A OUTPUT –p tcp –d 192.168.1.235 -jACCEPT

　　允许服务器主动访问的IP白名单

　　iptables -A DROP

　　拒绝对外访问

　　到此，业务恢复正常。

　　 查找原因

　　其实原因一开始我就意识到了是SSH的问题，只是先要帮人把业务恢复了再说，web端口方面就只有tomcat的，web漏洞都查过了，什么struts2，manager页面，还有一些常规web漏洞均不会存在，除非有0day…. Oracle也不外连，只有个SSH

　　基于这一点，我直接查root账户ssh登陆日志，翻啊翻，终于….

　　cd /var/log less secure

　　如上图，使用印尼IP爆破成功，而后面服务器内网IP登陆竟然是失败，问了客户，算是明白了怎么回事，他们年底加设备，给服务器临时改了弱密码方便各种第三方技术人员调试，然后估计忘了改回来，结果悲剧了，被坏人登陆了不说，root密码还被改，自己都登不上…不知道他们老板知不知道…

　　继续查看history文件，看人家都干了些什么。

　　坏人的操作过程基本就在这里了，他执行了好多脚本，谁知道他干了多少事，还是建议客户重装系统吧…

本文由 帝一博客 原创发布。用户在本站发布的原创内容（包括但不仅限于回答、文章和评论），著作权均归用户本人所有。独家文章转载，请联系邮箱：17762131@qq.com。获得授权后，须注明本文地址： https://bubukou.com/linuxyunwei/1746.html