拯救被“綁架”的服務(wù)器

河南 劉景云

單位的一臺Web 服務(wù)器出現(xiàn)運行緩慢的現(xiàn)象，無法為外部的客戶提供服務(wù)。該機(jī)安裝的是CentOS 6.X 系統(tǒng)，后臺使用的Redis 數(shù)據(jù)庫，一直以來運行的都很正常。

為了排查問題，筆者隨手在一臺客戶機(jī)上執(zhí)行了“redis -h x.x.x.x -p 6308”命令，來檢測是否可以訪問后臺的Redis 數(shù)據(jù)庫。其中的“x.x.x.x”為該服務(wù)器的IP，“6308”為Redis 開放的端口。按照正常情況，是需要輸入認(rèn)證密碼的，但是該機(jī)卻沒有提示任何認(rèn)證提示，直接連接成功。這一反常情況引起了筆者的注意。

尋覓蹤跡，發(fā)現(xiàn)幕后“黑手”

筆者登錄到服務(wù)器上，執(zhí)行“top”命令，在返回信息中的“Load average”欄中顯示系統(tǒng)負(fù)載情況，可以看出在1分鐘，5 分鐘以及15 分鐘等時間段中，系統(tǒng)平均負(fù)載都比較高，這說明系統(tǒng)運行壓力很大。因為該機(jī)硬件配置較高，應(yīng)對正常的工作應(yīng)該沒有任何問題的，肯定有來歷不明的程序大量占用了系統(tǒng)資源。果然，在進(jìn)程列表中發(fā)現(xiàn)了名為“nginx0”的可疑進(jìn)程，其CPU 占用率極高，是以Root身份運行的。

但是該機(jī)并沒有安裝Nginx服務(wù)，這明顯存在問題，肯定是該不法程序過度占用CPU 資源，才造成服務(wù)器運行緩慢的問題。

經(jīng)過檢測，發(fā)現(xiàn)該機(jī)網(wǎng)絡(luò)帶寬占用率很高，很明顯該不法程序在頻繁和外界進(jìn)行通訊，產(chǎn)生了很大的流量的緣故。在進(jìn)程列表中，顯示該進(jìn)程的PID 為21039，據(jù)此可以追蹤到其實際的藏身地。執(zhí)行“l(fā)s -al/proc/21039/exe”命令，顯示其存儲路徑為“/var/data/nginx0”。

既然找到了不法程序，就將其清除，執(zhí)行“kill -9 21039”命令，將該進(jìn)程關(guān)閉。

執(zhí)行“rm -rf/var/data/nginx0”命令，將該非法程序刪除。本以為這樣就萬事大吉了，奇怪的是，當(dāng)經(jīng)過幾分鐘后，再次執(zhí)行“top”命令，發(fā)現(xiàn)該非法進(jìn)程有出現(xiàn)了。據(jù)此推斷，在系統(tǒng)中還存在與其關(guān)聯(lián)“內(nèi)應(yīng)”，當(dāng)其判斷該進(jìn)程被清除后，就會自動生成并啟動該非法進(jìn)程。

筆者首先想到的是計劃任務(wù)，應(yīng)該是在系統(tǒng)的Crontab 中存在預(yù)設(shè)的定時任務(wù)，來定時激活該不法進(jìn)程。

對于Linux 的計劃任務(wù)來說，實際上存在系統(tǒng)級別和用戶級別的Crontab，兩者分別對應(yīng)“/etc/crontab”和“/var/spool/cron”存儲路徑。

對用戶級別的Cron 進(jìn)程檢測，并沒有發(fā)現(xiàn)問題。執(zhí)行“l(fā)l/var/spool/cron”命令，發(fā)現(xiàn)了幾個計劃任務(wù)項目，但實際上，該機(jī)管理員根本并沒有配置任何計劃任務(wù)。這些計劃任務(wù)肯定和不法進(jìn)程有關(guān)。

執(zhí)行“cat/var/crontab/stroot”命令，打開名為“stroot”的計劃任務(wù)，發(fā)現(xiàn)其中存在亂碼信息，但是這并不影響Shell 的執(zhí)行，在其中可以看到其使用了“curl”命令，在指定的時間段，每隔幾分鐘從某個來歷不明的網(wǎng)站下載并執(zhí)行一個Shell 腳本，該腳本作用是判斷上述非法進(jìn)程是否存在，如果不存在的話，就會自動下載并運行上述不法程序。

筆者隨手執(zhí)行了“netstat -antlp”命令，查看網(wǎng)絡(luò)端口開啟情況，在其中看到TCP 22 端口處于監(jiān)聽狀態(tài)，那么在黑客會不會利用SSH 登錄本機(jī)呢？

筆者執(zhí)行“vim/etc/ssh/sshd_config”命令，打開OpenSSH 的配置文件，在其中仔細(xì)觀察，果然發(fā)現(xiàn)一些問題，在其中的“PermitRootLogin”，“RSAAuthentication”，“PubkeyAuthentication”欄中均設(shè)置為“yes”，這表示允許Root 賬戶登錄SSH，啟用RSA 認(rèn)證，允許密鑰認(rèn)證等操作。

但是，該機(jī)管理員根本沒有改動過該配置文件，這顯示是黑客的惡意修改所致。在“AuthorizedKeysFile”欄中顯示的并不是默認(rèn)的“.ssh/authorized_keys”參數(shù)，確是一個名稱雜亂的公鑰認(rèn)證文件。進(jìn)入“/root/.ssh”目錄，果然找到了該奇怪的認(rèn)證文件。

根據(jù)以上分析，筆者斷定該機(jī)已經(jīng)被黑客完全控制，黑客一定獲取了免密鑰登錄功能，以Root 身份遠(yuǎn)程登錄系統(tǒng)，并擁有對該機(jī)的完全控制權(quán)。

看來，必須采取緊急措施，將惡意程序徹底刪除，并切斷黑客對該機(jī)控制權(quán)。

逆向分析，識破黑客伎倆

在解決問題之前，必須了解黑客究竟是如何對本機(jī)進(jìn)行滲透的。

前面已經(jīng)提到，該機(jī)安裝的是Redis 數(shù)據(jù)庫，但是卻開放了TCP 6308 端口，并且因為便于使用，沒有為Redis 設(shè)置密碼，這就為黑客造成了可乘之機(jī)。

黑客可能使用“Nmap”等掃描工具，掃描到了該機(jī)存在上述漏洞，之后會嘗試登錄操作，黑客會“驚喜”地發(fā)現(xiàn)可以順利登錄，并且可以執(zhí)行各種Redis 命令對該機(jī)上的Redis 數(shù)據(jù)庫進(jìn)行操作。

顯然，黑客并沒有滿足于此，沒有對數(shù)據(jù)庫進(jìn)行破壞，而是希望完全該機(jī)，并將其作為跳板來攻擊其他主機(jī)。

黑客先在自己的某臺主機(jī)上開啟一個監(jiān)聽端口，之后其另外一臺主機(jī)上連接到該服務(wù)器的Redis 環(huán)境，利用Redis 的指令開啟一個Socket 連接，使其指向目標(biāo)主機(jī)，同時向“/var/spool/cron”或者“/etc/crontab”等路徑寫入非法的計劃任務(wù)項目。

這樣黑客就可以在PC1 上獲取針對該服務(wù)器的Shell 連接，因為該機(jī)的Redis 是以Root 身份運行，黑客自然可以獲取Root 權(quán)限。

黑客為了便于完全控制該服務(wù)器，還會在本機(jī)上來生成RSA 密鑰對，之后將公鑰轉(zhuǎn)變?yōu)槲谋疚募?，通過特殊處理后，將其寫入到Redis 數(shù)據(jù)庫中。

連接到Redis 控制界面后，提取非法寫入公鑰信息，并將該公鑰文件寫入目錄中。這樣，黑客就可以遠(yuǎn)程控制該主機(jī)。

查補漏洞，掃除惡意程序

根據(jù)以上分析，不難發(fā)現(xiàn)正是因為該服務(wù)器開放了Redis 端口，并且沒有設(shè)置密碼，才導(dǎo)致黑客可以很輕松地獲取該服務(wù)器的控制權(quán)。

因此，當(dāng)務(wù)之急是必須強(qiáng)化Redis 的安全性，因為Redis 的TCP 6380 端口完全暴露在網(wǎng)上，其安全性是無法得到保證的。因此執(zhí)行“iptables -A INPUT -p tcp-m tcp --dport 6380 -j DROP”命令，在Linux 防火墻添加一條規(guī)則，其中的“-A”參數(shù)表示創(chuàng)建一條新規(guī)則，“-p tcp”參數(shù)表示匹配TCP 協(xié)議的數(shù)據(jù)包，“-dport 6380”表示匹配目的端口為6380 的數(shù)據(jù)包。

也可以執(zhí)行“iptables-L -n”命令，查看Linux 防火墻規(guī)則信息，如果發(fā)現(xiàn)TCP 6380 端口處于開放狀態(tài)，可以執(zhí)行“iptables -D INPUT-p tcp -m tcp --dport 6380 -j ACCEPT”命令，將對應(yīng)的規(guī)則刪除即可。因為管理員使用Root 權(quán)限來運行Redis，所以一旦Redis 被黑客控制，就很容易讓其獲取Root 權(quán)限。

因此使用普通用戶身份運行Redis，方法是執(zhí)行“useradd -s/sbin/nologin redistest”命令，創(chuàng)建名為“redistest”的普通用戶，之后執(zhí)行“cd/home/redistest”，“mkdir log dbdata run”命令，創(chuàng)建所需的文件夾。

執(zhí)行“cp/etc/redis.conf/home/redistest/redistest.conf”命令，將Redis配置文件復(fù)制到該普通賬戶的家目錄中。執(zhí)行“chow-R redistest:redistest/home/redistest/*”命令，修改上述文件夾權(quán)限，讓“redistest”賬戶擁有合適的控制權(quán)。執(zhí)行“vim redis.conf”命令，打開Redis 的配置文件，在其中的“pidfile”行中輸入“/home/redistest/run/redis_6379.pid”，在“l(fā)ogfile”行中輸入“/home/redistest/log/redis.log”。在“dir”行中輸入“/home/redistest/dbdata”，來設(shè)置新的路徑信息。

執(zhí)行“/home/redistest/dbdata”命令，在其中的“ExecStart=”欄中輸入“/usr/bin/redis-server/home/redistest/redistest.conf”，修改Redis 的啟動方式。執(zhí)行“systemctl restart redis.service”命令，就可以以普通用戶身份啟動Redis。執(zhí)行“ps-aux|grep redis”命令，可以查看Redis 的啟動信息。

為了防止隨意連接Redis，最好為其添加密碼，執(zhí)行“vim redis.conf”命令，在Redis 配置文件的“requirepass”行中輸入合適的密碼。之后執(zhí)行“systemctl restart redis.service”，來重啟Redis。

以后執(zhí)行“redis-cli -h x.x.x.x”命令，在命令行中需要輸入“auth xxx”命令，才可以連接Redis，其中的“xxx”為具體的密碼。

也可以執(zhí)行“redis-cli-h x.x.x.x -a xxx”命令，在命令行中的“-a”參數(shù)后面寫入密碼，來安全連接Redis。為了防止黑客利用非法公鑰免密登錄，執(zhí)行“rm-rf/root/.ssh/”命令，將“/root/.ssh”目錄中黑客寫入的非法公鑰文件刪除，可以在自己的主機(jī)上使用“sshkeygen”命令。將生成合法公鑰文件復(fù)制到該服務(wù)器上，在“/root/.ssh0 目錄下得到合法 的“authorized_keys”公鑰文件。

這樣，管理員就可以實現(xiàn)免密登錄該服務(wù)器。執(zhí)行“chmod 400～/.ssh/authorized_keys”命令，為“authprized_keys”文件設(shè)置嚴(yán)格的權(quán)限，讓擁有者對其只能進(jìn)行修改操作，其余的用戶沒有任何權(quán)限。執(zhí)行“chattr+i authorized_keys”命令，將該文件鎖定，只要不解鎖，連Root 用戶都無權(quán)對其進(jìn)行修改操作。因為黑客已經(jīng)對OpenSSH 的配置文件進(jìn)行了修改，為了穩(wěn)妥起見，可以從其他正常的主機(jī)上復(fù)制“sshd_config”文件，來覆蓋該機(jī)的OpenSSH 配置文件。執(zhí)行“systemctl restart sshd”命令，來重啟sshd 服務(wù)讓配置生效。

提高了Redis 的安全性，封鎖了黑客的SSH 連接通道后，之后就可以清理黑客在本服務(wù)器上創(chuàng)建的各種惡意文件了。

執(zhí)行“rm -rf/var/spool/cron”，“rm -rf/etc/crontab”之類的命令，將黑客上傳的惡意計劃任務(wù)全部刪除。繼續(xù)在該服務(wù)器檢查，發(fā)現(xiàn)在“/etc/init.d”中存在名為“stnginx”的非法文件，在“/etc/systemd/system/”目錄下發(fā)現(xiàn)名為“ngsql.service”的非法程序。在“/etc/rc.local”目錄下發(fā)現(xiàn)名為“krdisc”，在“etc/init.d”目錄下發(fā)現(xiàn)名為“netudev”的程序，這些可能是用來自動運行不法程序的，將其全部刪除。

最后使用上述方法，關(guān)閉“nginx0”的進(jìn)程并清除對應(yīng)的文件。這樣，該服務(wù)器終于可以正常運行了。