做為一個運維人員要經常面對各種問題，其中不可避免的就是網站入侵問題，據觀察此類問題基本上是為了掛馬、流量攻擊、拖庫，除了拖庫對網站安全影響很大，掛馬和流量攻擊的危害性相對比較小。大部分網站都會面臨被掛馬的問題，更甚者在掛馬頁竟然寫著“友好往來，拒絕刪鏈，否則后果自負”，這對服務器運維人員來說簡直是赤裸裸的挑釁。
一般的運維人員對這種問題往往沒有太好的解決辦法，只是簡單的刪除鏈接恢復網站，但沒過幾天問題依然沒有解決，掛馬依然存在，雙方就這樣在刪除與添加中對峙。
有好多客戶打電話過來反映網站被掛馬了，咨詢網站掛馬之后該如何處理，具體問客戶什么時間被掛的，客戶大部分都說不出來具體時間，他們的解決辦法也很簡單，掛完之后直接刪除，然后繼續這場無頭的拉鋸大戰，其實這是不對的。
如果我們發現網站被入侵之后，首先要做的不是刪除，而是保留證據，第一步操作是找到文件的具體修改時間，要把這個時間點確定，只有時間點確定之后才能有后續的操作，如果你連自己網站什么時候被入侵的都不知道，還談什么后續的處理呢？
第二步：查找相關日志
找到文件的修改時間之后，馬上查找對應時間的網站訪問日志、服務器登錄日志、ftp日志，按這個時間點查詢肯定會有蛛絲馬跡，找日志的目地是為了找到我們的程序或者服務器的漏洞，只有找到漏洞，把漏洞封堵才是解決問題的根本，不然漏洞給人留著，隨時都可以進行修改，你所有的工作都白做了。
注意：windows日志和文件時間會有8個小時的時間差！
第三步：漏洞修復
如果是網站的漏洞，通過網站訪問日志就可以看到，一般文件修改時間點的日志前后會有大量不正常訪問頁面，請求方式大部分都是post，網站訪問基本上是get，如果是post請求就需要特別注意了，有的時候找到的文件是黑客上傳的文件，然后要根據這個文件創建的時間重復之前的操作，直到找到根本，這里面大部分都是編輯器上傳漏洞引起的，fck問題居多。
溫馨提示：使用編輯器的時候一定要主要上傳的處理，不要使用編輯器默認的上傳處理，默認的上傳處理是沒有用戶驗證的，也就是說別人知道這個上傳地址可以上傳任意文件，能傳文件也就能傳webshell，否則，一時的省心到時候哭都來不及了。
網站遭遇入侵之后，一定要查找入侵原因，把漏洞修改，這樣才能徹底解決問題，是服務器安全沒有做好，還是程序安全沒有做好，把該處理的處理好，徹底杜絕后患，同時要把安全時刻放在心上，時刻保留安全意識，只有這樣才能減少網站被入侵的風險。
