故事是这样的,大年初一,客户反应他们服务器无法访问,查看路由,发现某 oracle+tomcat 服务器 UDP 流量超大,把带宽占完了,过年嘛,客户那边先找了当地的技术人员弄了几天没搞定,然后没办法大年初三的找我们弄…顾客是上帝!
其实吧以前也遇到过这类攻击,当时某IDC都被打瘫了,只不过马儿不在我们的设备上,所以没过多关注…
首先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 文件,看人家都干了些什么。
坏人的操作过程基本就在这里了,他执行了好多脚本,谁知道他干了多少事,还是建议客户重装系统吧…
主要还是自己经验尚浅,linux运维玩的不熟,不知道怎么把马儿彻底赶出去…大牛勿喷。