作者:哈兹本德
来源:FreeBuf
0×00 前言
故事是这样的，大年初一，客户反应他们服务器无法访问，查看路由，发现某
oracle+tomcat
服务器
UDP
流量超大，把带宽占完了，过年嘛，客户那边先找了当地的技术人员弄了几天没搞定，然后没办法大年初三的找我们弄…顾客是上帝！
其实吧以前也遇到过这类攻击，当时某IDC都被打瘫了，只不过马儿不在我们的设备上，所以没过多关注…
0×01 查找木马
首先SSH登陆，top查看进程，发现奇怪名字的命令gejfhzthbp,一看就感觉有问题。
lsof –c gejfhzthbp
查看关联文件，发现对外的
tcp
连接，不知道是不是反向
shell…
执行命令
Whereis gejfhzthbp
ls -al gejfhzthbp
查看文件路径。并查看文件创建时间，与入侵时间吻合。
顺便把文件拷贝下来放到kali虚拟机试了下威力，几秒钟的结果如下…
之前还以为是外国人搞的，这应该能证明是国人搞的了…
0×02 恢复业务
首先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
拒绝对外访问
到此，业务恢复正常。
0×03 查找原因
其实原因一开始我就意识到了是
SSH
的问题，只是先要帮人把业务恢复了再说，
web
端口方面就只有
tomcat
的，
web
漏洞都查过了，什么
struts2
，
manager
页面，还有一些常规
web
漏洞均不会存在，除非有
0day…. Oracle
也不外连，只有个
SSH
基于这一点，我直接
查
root
账户
ssh
登陆日志，翻啊翻，终于….
cd /var/log less secure
