今天我们收到了这个警告,同时服务器网络很卡,用SSH连接都会经常断,ping也时断时续,
警告的描述:
几年前strtus2 的严重漏洞 很多人都知道,但公司这个项目已经上线了,换的成本太高,所以一直用struts2,就把jar包升级了,按理说不应该有严重漏洞。
服务器被攻击之前也有过,但只是见过简单的sql注入到应用服务,注意一下,并不严重。
服务器症状
用free -m 看了内存,也正常,top看 cpu 也正常,
首先查看一下,/var/log/secure
发现有一个ip 一直在试密码,
嗯,但不确认是不是它引起的,
不过可以尝试把这个ip 给禁了,
一些常规查看,可参考https://zhidao.baidu.com/question/744901405128179692.html
这个网址可以查看到不少服务器的日志方法
https://www.cnblogs.com/ylong52/p/5665708.html
查看整体网络情况,
dstat -nf
发现 有时会有177M这样的高流量出现
--net/eth0- --net/eth1-
recv send: recv send
111B 71B: 40B 122B
111B 71B: 40B 170B
111B 71B: 40B 122B
111B 71B: 40B 90M
111B 71B: 40B 177M
dstat还是很实用的,除了网络,cpu,io等也能监控到,如果你的生产机有问题,首先用这个方法,可能会给你带来一些线索
用iftop确认具体的流量,
发现服务器有进程,一直send
iftop -i -N -P eth1
iftop的使用
http://www.vpser.net/manage/iftop.html
如果要更细一点,查看所有请求的情况,可以用tcpdump -nn -i eth1,但这个是抓包的,感觉不是很合适.
尝试找到进程
但我用 lsof -i:37815 并不能找到该进程,,估计是这个客户端端口总是换。而我看到这个端口又有延迟,所以通过看到的端口找不到进程。。。
同样,这样也找不到,netstat -tunple | grep 37815
我也用 nethogs 去查看进程对应的流量 ,但是也没发现大流量,。很奇怪。 、
找不到进程,这个瓶颈持续了挺久,都没啥好办法,
通过进程方式找问题
然后我直接ps -ef 查看下全部进程,有没有奇怪的,发现有一个yundun (不是AliYunDun),感觉为啥 “yundun” 会有两种?然后pwdx 这个进程,发现是在tmp中的,而用户又不是root, 于是我考虑了一下,尝试把它给kill 了,发现问题解决。。。
不过,隔一段时间会又起来,把用户的密码给改掉,貌似解决
直接问题解决了,根本问题还没解决..而且还留了不少疑问。
通过查看进程找问题是一个碰运气的做法,可以通过一些条件来限制,如用户,如果要查看下用户的登陆情况,命令:last
其它方式找问题
百度了一下
这些症状有点像下面这个网址描述的有点类似
http://www.oicqzone.com/pc/2014110420120.html
- 找疑问文件
cd /etc/rc.d/rc1.d 这个目录下面这两个文件 我在其它正常的机上是看不见的,
看到用户是root, 有可能是root 被其它人使用, 需要尽快找时间更新密码(其它用户 的权限没那么大,是写不了文件到这个目录下的,建议如果安装其它工程或软件,都不要使用root账户,要自建用户来使用)
在etc中找到问题文件
find /etc -mtime -5 -type f -print // 近5天的文件
/etc/init.d/DbSecuritySpt 和 /etc/init.d/selinux这个文件里的内容是/usr/bin/bsd-port/getty
bsd-port 在百度上搜索,发现有挺多是 和入侵有关的事,
在bin中找到问题文件
// 近5天有修改的文件
find /etc -mtime -5 -type f -print
find /bin -mtime -5 -type f -print
有几个命令被替换了,包括ps,lsof等,/usr/bin/dpkgd 里面是正确的文件(简单和其它正常机器的命令对比过),
我已经把ps,lsof等命令放回原位了.具体操作
为了保证没有误操作,对于疑似文件,我并没有进行删操作,只是把这些文件移到 指定目录,
在服务器中做了如下操作:
mv /usr/bin/bsd-port* /root/bak/usrbin/
mv /usr/bin/.sshd /root/bak/usrbin/
mv /etc/rc.d/init.d/selinux /root/bak/etc/
mv /etc/rc.d/init.d/DbSecuritySpt /root/bak/etc/
找到攻击的守护进程
[root@iZ944ytt77sZ etc]# ps -ef | grep bsd-port
root 14441 1 0 Dec05 ? 00:01:18 /usr/bin/bsd-port/getty
[root@iZ944ytt77sZ etc]# lsof -n | grep 14441
getty 14441 root cwd DIR 202,1 888832 393217 /tmp
getty 14441 root rtd DIR 202,1 4096 2 /
getty 14441 root txt REG 202,1 1223123 1070611 /root/bak/usrbin/bsd-port/getty
getty 14441 root 0u CHR 1,3 0t0 3866 /dev/null
getty 14441 root 1u CHR 1,3 0t0 3866 /dev/null
getty 14441 root 2u CHR 1,3 0t0 3866 /dev/null
getty 14441 root 3uW REG 202,1 5 1070612 /root/bak/usrbin/bsd-port/getty.lock
getty 14441 root 4u sock 0,6 0t0 859801 can't identify protocol
kill 掉这个14441
可以进一步etc和bin中找bsd-port 关键字的文件
find /etc -name ‘*’ | xargs grep -ri ‘wdcp’
find /usr/bin -name ‘bsd-port’
结果
改用户密码,换端口,升级部分jar包,但这个问题貌似是php 的漏洞,还不好说是哪里引起的.
小结
- 你的进程开启不要用root.. 要用指定的用户,即使被攻击了,一是不会系统崩溃,二是方便排查 lsof -n | grep umall,这可以看到哪些文件和进程.
- 先宏观,再微观,如果遇到瓶颈了,多去看其它指标,有时运气和直觉也挺重要
- 找安全问题有时候和找性能问题有些像
- 找一些疑问文件,尤其是/etc和/bin里的,find ./ -mtime -5 -type f -print –近五天的修改文件(http://blog.csdn.net/tongzidane/article/details/42291771)
- 通过关键字也可以找下疑问文件,find ~/ -name ‘*.out’ | xargs grep -ri ‘/tmp’