一個端口沒關，我得服務器被黑到系統崩潰，看我怎麼找回數據！
騰訊雲服務器被黑了，沒想到這是我第二次被黑，又是一個慘痛得經歷！
先說說上次被黑得經歷，上次被黑的服務器是阿里雲，服務器倒是沒事，僅僅是被刪庫了，主要原因有亮點，一是外網數據庫端口沒關，二是線上數據庫密碼過於簡單，總結來說是弱密碼口令攻擊，數據庫密碼有多簡單，123456，說到這裏，一口老血噴出來！
這次被黑顯得有些科幻了，搞到提工單都沒辦法解決，系統都沒辦法重啓，我都懷疑入侵者在我機器根目錄上上執行了 rm -rf *
首次發現
第一次發現得時候在於昨晚，在百度上查看網站得收錄情況，突然發現網站打不開了！以爲是服務器不穩定，打算登錄上去重啓一下，然後悲劇得發現登不上去了！
於是麻溜得去騰訊雲提工單，看看是什麼情況！
通過工程師得分析，我得機器是因爲cpu爆滿導致沒有資源能夠進行遠程連接，建議我重啓後通過VNC登錄（網頁登錄得一種）
好嘛，終於通過網頁端登錄進來了，趕緊看看出了什麼問題！由於我的服務都是基於docker得，於是首先docker查看了一下容器信息，一看嚇一跳
臥槽，我的機器啥時候被掛上兩個程序在跑了，一個是15小時前，另外一個是39小時前，也就是在這一兩天，並且這個哥們倒是很聰明，沒有動我得其他東西，要不是機器跑掛了我都沒發現。立馬刪除了這兩個容器
好，問題找到了，我現在沒有時間去管跑的這兩個到底是啥應用，反正就是被黑了，至於被黑得原因，我想到前段時間寫的帖子就猜到了：docker外網遠程端口忘記關了。真是打臉啪啪啪
立馬去關了遠程端口，以防壞淫繼續作亂
爲了進一步保證安全，我再次更換了ECS服務器得登錄密碼
現在想着既然隱患都解決了，那就重啓下系統唄。
完蛋，遠程又是連接不上，還是隻能通過VNC連接，這也不方便啊，心累，關燈睡覺，明天再說吧
第二天早上，通過xshell遠程登錄，還是登錄不上，再次後臺點擊重啓，過了一會，依舊是失敗，通過VNC去連接，發現連VNC都連不進去了，只看到如下界面,沒錯，卡住不動了！重啓都GG
有問題立馬提工單找騰訊小哥哥啊，各種授權
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-KfOPpi6y-1574071824949)(C:\Users\tyu\AppData\Roaming\Typora\typora-user-images\1574067849972.png)]
因爲機器都重啓不了，自然雲硬盤數據快照備份都使用不了，也就是說
我的所有資料都GG了！！！！
通過我得描述，工程師確認是因爲黑客攻擊導致系統文件缺失，導致無法重啓，必須得重裝系統才能用了，那我得文件怎麼辦呢？我的數據庫還存着上百篇得博客呢~ 於是爲了將損失降低到最小，跟工程師溝通了一下恢復方案，對方建議我從原來得系統盤進行試恢復，希望黑我得這位老鐵沒把我以前手動備份得文件給清除，不然我真的要哭了！
首先，購買了一份雲硬盤，將原來得系統盤數據拷貝到雲硬盤，因爲要想重新去查看原來得數據，必定是先重裝系統然後掛載雲硬盤，因爲系統盤會隨着實例釋放，所以不得不掏錢買了一個一樣大得雲硬盤，花了十幾塊錢買了一個月得，開整！
首先將ecs服務器關機，然後進行系統盤拷貝，拷貝完成以後將不能啓動得ecs服務器重裝系統，嗯，思維縝密，給自己一個贊！
重裝完成以後，將新的硬盤進行掛載，使用命令查看數據庫盤符
# fdisk -l
Disk /dev/vda: 53.7 GB, 53687091200 bytes, 104857600 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000c5e30
Device Boot Start End Blocks Id System
/dev/vda1 * 2048 104857566 52427759+ 83 Linux
Disk /dev/vdb: 53.7 GB, 53687091200 bytes, 104857600 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000c5e30
Device Boot Start End Blocks Id System
/dev/vdb1 * 2048 104857566 52427759+ 83 Linux
手動進行掛載
mount /dev/vdb1 /mnt/
然後進去以前得主目錄，看看數據還在不在
看到ls命令之後蹦出來得數據，我喜極而泣！
數據終於最小損失得找了回來！
列一下我這個目錄下得一些主要文件
- aliyun_mysql_back_up 阿里雲數據庫異地備份目錄
- dblogXXX.sql 博客數據庫 手動備份腳本
- mysqlBackUp mysql腳本備份
- nginx docker容器得宿主機目錄，一些 https證書以及nginx配置文件和日誌文件
- ngrok 內網穿透相關
- redis redis容器宿主機相關
比較幸運得是，數據基本都能找回來了，也沒有什麼太大得損失，算是驚魂了一把。
因爲我的應用都是基於docker得，數據庫備份腳本也都找回來了，所以短時間內應用就歡快得跑了起來！
總結
- 雲服務器敏感得端口儘量不要設置爲開放，即使設置爲開放，也要設置爲固定ip可訪問，而不是所有客戶端能訪問
- 事故發生了不要急，一步一步來，沒準就會像樓主一樣能最大減少損失，不拋棄不放棄
- 心態別崩，即使都掛了，也要做好從頭再來得準備，別像樓主，救護車都準備叫好了
- 不要怕麻煩，數據做好備份，真正出事得時候，你會覺得：真香！
歡迎關注我的個人公衆號，只發原創！
