記一次服務器被植入挖礦腳本的解決過程
刪除挖礦腳本和對應的進程
找出並刪除對應挖礦腳本文件
找出進程pid，並且kill掉
無法kill掉的是原進程的守護進程，原進程不在它也會自動關閉，所以不用管它
kill掉后cpu恢復正常
需要檢查是否有定時任務
防止挖礦腳本重新下載。
我這里沒有，如果有可以使用以下命令刪除
crontab -r
檢查docker是否也有挖礦的容器在運行
檢查創建的docker容器
我這里發現了很多不是我自己創建的容器，截圖的都不是我自己的，需要全部刪除。
使用以下命令刪除全部不運行的容器（因為目前正在運行的只有我自己的容器，故不用擔心自己的容器也被刪掉）
檢查docker鏡像。
發現兩個鏡像是別人下載的，刪除掉這兩個鏡像。
用非root用戶重啟docker服務
修復redis漏洞
修改 redis.conf 文件
- 主要改端口和綁定訪問ip，還有設置日志文件及其級別（用於查看訪問的ip），設置訪問密碼
bind x.x.x.x
port 56331
logfile "56331.log"
loglevel verbose
requirepass xxx
備注：
bind 允許訪問的ip
requirepass 驗證登錄的密碼
- 禁用遠程修改 DB 文件地址，禁用lua腳本命令
rename-command FLUSHALL ""
rename-command CONFIG ""
rename-command EVAL ""
備注：
Redis Config Set 命令可以動態地調整 Redis 服務器的配置(configuration)而無須重啟。
Redis Eval 命令使用 Lua 解釋器執行腳本。
切換非root用戶，不使用root用戶啟動redis
su hzk
保證root用戶 authorized_keys 文件的安全
查看root用戶ssh免密登錄保存的公鑰是否已經添加了別人的公鑰。
如果里面存放了別人的公鑰，那它就可以直接ssh登錄我們的系統。
發現果然有別人的公鑰，需要把它們都刪除掉。
為了保證安全，您應該阻止其他用戶添加新的公鑰。
- 將 authorized_keys 的權限設置為對擁有者只讀，其他用戶沒有任何權限：
chmod 400 ~/.ssh/authorized_keys
- 為保證 authorized_keys 的權限不會被改掉，您還需要設置該文件的 immutable 位權限:
chattr +i ~/.ssh/authorized_keys
- 然而，用戶還可以重命名 ~/.ssh，然后新建新的 ~/.ssh 目錄和 authorized_keys 文件。要避免這種情況，需要設置 ~./ssh 的 immutable 權限：
chattr +i ~/.ssh
- 修改后的文件可以lsattr查看屬性
[root@study ~]# lsattr [-adR] 檔案或目錄
選項與參數：
-a ：將隱藏檔的屬性也秀出來；
-d ：如果接的是目錄，僅列出目錄本身的屬性而非目錄內的檔名；
-R ：連同子目錄的資料也一併列出來！
設置防火牆策略
如果正常業務中Redis服務需要被其他服務器來訪問，可以通過redis日志找出對方ip，然后通過設置iptables或者firewalld策略把該ip禁止訪問。
修改ssh默認端口
檢查sshd_config文件
發現sshd_config文件被修改，添加了多個ssh訪問的端口，把它們刪除掉
修改ssh訪問端口
將Port改為50000
重啟ssh服務
systemctl restart sshd.service
檢查家目錄是否有別人新創的用戶
除紅色外均不是我創建的用戶
訪問其中一個別人創建的用戶家目錄（frank），發現其.ssh目錄下的authorized_keys已保存了對方的公鑰，即對方可通過frank用戶進行免密碼登錄。
刪除該用戶（frank）數據和家目錄
而用戶的數據有：
- 用戶賬號/密碼相關參數：/etc/passwd, /etc/shadow
- 使用者群組相關參數：/etc/group, /etc/gshadow
- 用戶個人文件數據： /home/username, /var/spool/mail/usernam
使用如下命令即可刪除上述所有。
[root@study ~]# userdel -r frank
選項與參數：
-r ：連同用戶的家目錄也一起刪除
修改系統所有用戶的密碼（包括root）
建議不用root直接修改，因為root會忽略密碼安全校驗。
切換用戶，直接用passwd命令即可修改當前用戶的密碼。
參考：
https://www.freebuf.com/column/158065.html【Redis未授權訪問詳解】
https://blog.csdn.net/huyuyang6688/article/details/78994909【記一次服務器被挖礦木馬攻擊的經歷】