伺服器被入侵之後能做什麼：偷走 GitHub 帳號、清空紀錄，為什麼唯一解法是砍掉重練，SSH 金鑰與防火牆缺一不可
從設定 SSH 金鑰、停用 root 登入到把 GitHub 金鑰接上伺服器，前面陸續做了不少安全性設定。這一節進入新的一章，正式把「安全性」單獨拉出來系統性地談：伺服器一旦被入侵，攻擊者實際上能做到什麼地步，以及為什麼防守這件事怎麼做都不嫌多。
重新檢視上線一天後的 auth.log
伺服器上線大約一天之後，回頭再看一次前面看過的 /var/log/auth.log：
bash
sudo cat /var/log/auth.log即使只是短短一天，紀錄裡也已經累積了大量連線嘗試，其中不少是無效使用者的登入紀錄。這正是前面提過的現實：伺服器只要一連上網際網路，就會立刻被各種自動化程式盯上、進行連接埠掃描（port scanning），網際網路上並非所有連線嘗試都出於善意。
如果有人真的拿到伺服器的存取權，能做什麼
即使已經停用了 root 登入，這仍然只是防線的一部分。如果攻擊者透過其他管道真的取得了伺服器的存取權，能做的事情遠比想像中嚴重：
- 濫用頻寬：任意下載大量資料，把頻寬額度用光
- 把伺服器當成跳板：拿這台伺服器去攻擊其他網站或基礎設施，變成殭屍網路的一部分
- 透過伺服器上的 SSH 金鑰偷走 GitHub 帳號：正因為前面已經在伺服器上設定好連到 GitHub 的 SSH 金鑰，一旦伺服器落入他人之手，攻擊者就能直接冒用這把金鑰連進 GitHub，把整個公司的程式碼與工作成果一併偷走，而這一切都源自於一台原本不打算讓別人碰的伺服器
- 清除入侵痕跡：入侵之後，攻擊者可以直接刪除或修改日誌檔案的內容，讓使用者完全不知道自己的機器早就已經被入侵過
為什麼機器一旦被入侵，只能整台砍掉重練
正因為攻擊者可以清除紀錄、隱藏自己做過的事，一台確定被入侵過的機器，唯一安全的處理方式就是整台砍掉重練，用很久以前的備份重新還原，因為沒有人能確定攻擊者到底動過什麼手腳。歷史上不乏企業被入侵長達兩三年、甚至四年都沒有發現的案例：即使一開始以為已經修復了漏洞，攻擊者可能早就在系統裡植入了類似 rootkit 的後門，安靜潛伏、持續觀察。真正危險的攻擊者往往不是圖一時好玩的青少年，而是願意花上好幾年時間、耐心布局，盡可能滲透得更深的長期威脅者。正因為所有系統彼此相連、環環相扣，伺服器的安全性才會如此重要。
三道基本防線：SSH 金鑰、防火牆、隨時更新軟體
面對這樣的風險，最基本、也最有效的防線包括：
- 一律使用 SSH 金鑰，不使用密碼：這也是前面反覆強調的原則，密碼本質上脆弱，容易被暴力破解，SSH 金鑰則不然
- 設定防火牆：明確規定伺服器只允許哪些類型的連線進來，例如只開放一般的網路流量，其餘一律擋下，不讓伺服器暴露在不必要的風險之下
- 隨時讓軟體維持在最新版本：一旦有漏洞被公開、或發生資安事件，確保系統上跑的都是最新版本的軟體，才能盡快補上這些已知的破口
複習
如果未經授權的人取得了設有 SSH 金鑰的伺服器存取權，會有什麼關鍵風險？
攻擊者可能利用伺服器上設定好的 SSH 金鑰連進 GitHub，進而偷走公司整個程式碼庫或帳號內容。
針對伺服器，有哪三項建議的安全防護做法？
一律使用 SSH 金鑰取代密碼、用防火牆限制伺服器的存取範圍、隨時讓軟體維持在最新版本。
一旦發現機器已經被入侵，標準的處理建議是什麼？
整台機器砍掉重練，用很久以前的備份重新還原，因為沒有人能確定入侵者實際做過哪些事。
為什麼密碼被認為是伺服器身分驗證上比較脆弱的做法？
密碼容易透過暴力破解的方式被攻破，安全性遠遠不如 SSH 金鑰。
進階網路攻擊者常見的策略是什麼？
他們往往採取「打長期戰」的策略，耐心等待數年時間，安靜地滲透系統、蒐集情報，而不急於在短時間內被發現。
此文章是 FrontendMasters 上的 Full Stack Fundamentals, v3 課程筆記
