文章來自一個非常不成熟的程式媛的短暫性抽風式總結！
最近公司的伺服器（阿里雲）一直給老闆發資訊說，伺服器在訪問惡意下載源。老闆一開始沒在意，後來一天一條簡訊，然後讓我處理一下。作為一個後端工程師，普通的伺服器維護在小公司基本都是自己上手來。廢話太多了，下面具體描述一下我遇到問題的和解決方法，以便大家遇到了之後不知所措。（大佬們，不吝指教~）
一. 問題描述
阿里雲伺服器警告截圖：
看這種警告，其實主要看幾個重點
- 父程式路徑：/usr/sbin/crond
- URL連結：http://185.181.10.234/e5db0e07c3d7be80v520...
-
與該URL有關聯的漏洞：Drupal CVE-2018-7600 ，ElasticSearch Groovy指令碼遠端程式碼執行漏洞CVE-2015-1427 ，Hadoop Yarn REST API未授權漏洞 ，WebLogic CVE-2017-10271
（PS：這個點我覺得並沒很大用處，可能阿里雲考慮的比較仔細）所以我當時就很詫異，因為這個伺服器是我司一個測試伺服器，所以很多漏洞沒更新，我也不怎麼處理，被攻擊也可能是常有的事，也無傷大雅。
然後第一反應就是，這不就是定時任務
crontab跑了個東西，可能是訪問了某個連結被阿里雲檢測到不合法了。然後我就開始一頓查詢定時任務，然後開始清理。
查詢crontab執行命令：tail -f /var/*log*/cron
上面這個記錄看著出了一些 nobody 的使用者組進行了一個未知的定時任務執行記錄。
然後crontab -l除了自己的業務定時任務並沒看到這個所謂的curl 了某個連結的定時指令碼。然後我直接採取非常暴力的rm 方法，把所有定時任務全部清除。（第二天發現並沒什麼用。。。）
接著我就開始百度了（我搜了這個 ：185.181.10.234/e5db0e07c3d7be80v520/init.sh），這個東西會不會有人遇到過，果然還是度娘靠譜，光一個連結就能捕捉到我要啥。然後我就看到了這篇文章：
《一個有趣的利用redis未授權訪問漏洞進行挖礦的分析及防範》
https://www.freebuf.com/column/211777.html簡直是救命稻草，恍然大悟的我想起來測試服當時redis 安裝完確實沒有怎麼處理過，密碼也沒設定。
然後我開始設定redis 的登陸密碼和許可權，怎麼設定參考https://www.cnblogs.com/tenny-peng/p/11543440.html
順帶一起清空且重置了一下redis。
我就覺得這下應該萬事大吉了。然後第三天老闆依舊收到了來自阿里的警告資訊。我鬱悶了，啥玩意，為啥還可以，我不都設定密碼了麼。咋還執行呢？
想起前一天大佬提醒我要注意ssh key 是否被人新增了免密登入的許可權。其實我真的看了，
開啟vi authorized_keys並沒有任何東西。然後我順帶把其它/root/.ssh/下的四個檔案都翻了一遍。
才發現known_hosts檔案中多了兩個IP地址為新加坡的ssh key ,我才明白為啥上面做了那一堆都沒用了。
所以我解決上述問題的方法就是：
- 清空crontab 未知的計劃任務。
- 設定redis 埠許可權和賬號密碼（敲重點！）
- 清空未知的ssh key
結語
先總結到這吧。大家遇到了可以一起分享一些伺服器日常維護的經驗啊，畢竟不會運維的前端不是一個好後端~
本作品採用《CC 協議》，轉載必須註明作者和本文連結