從 Day 06 到 Day 10，我們練習了幾種 Linux 主機上的枚舉與提權案例。今天就回頭整理，看看這些案例為什麼能成功，以及可以從中學到哪些防禦觀念。

回顧實驗：問題出在哪裡？

從這些案例可以看出，問題可能來自授權範圍過大、檔案存取控制不當、程式未安全處理輸入，以及私鑰保管不當。

其中，有些案例讓我們取得 root 權限，有些則讓我們讀到原本無法存取的資料。例如 Day 07 的 SGID 案例，展示的是受保護資料被讀取，不能直接當成取得 root。

sudo、SUID／SGID、排程與 SSH 都有正常用途，但不當的設定或不安全的程式設計，可能讓使用者取得超出預期的能力。因此，分析問題時，除了檢查權限設定，也要了解程式實際做了什麼。

練習提權，也要理解成功的原因

滲透測試的練習，除了成功取得權限，也要能解釋整個過程是怎麼發生的。

如果只記住指令，卻不清楚成功所需的條件，換一個環境就可能不知道如何繼續，讓後續的練習事倍功半。

Day 02 提到，要從找到的資訊繼續追問。回顧這幾天的實驗，就能把這個觀念落實在具體條件上：

• **找到 SUID 程式：**還要檢查它提供哪些功能、如何處理輸入，以及執行時的權限。
• **找到可修改的腳本：**還要確認它是否真的被使用，以及由誰執行。
• **找到 SSH 私鑰：**還要確認私鑰是否可用、對應公鑰是否獲准登入目標帳號，以及其餘登入條件是否滿足。

發現線索之後，還需要把成立條件與實際結果確認清楚，才能說明問題的影響。

從攻擊過程，回頭思考如何防禦

練習的同時，我也會反思：如果我是管理這台主機的人，應該怎麼修正這些問題？

PATH Hijacking：明確指定指令路徑，並保護檔案

以 Day 09 的案例來說，高權限程式呼叫外部指令時，可以明確指定可信任的絕對路徑，例如 /usr/bin/date，避免依賴使用者可影響的 PATH 搜尋結果。

同時，也要確認該程式檔案及其所在路徑的目錄，不會被未授權使用者修改或替換。否則，即使指定了完整路徑，仍可能執行到遭竄改的程式。

另外，絕對路徑只處理了指令搜尋的問題；如果程式仍將不受信任的輸入直接拼接成 Shell 指令，依然可能有指令注入的風險。

SSH：保護私鑰，外洩後撤銷舊金鑰授權

SSH 私鑰應限制由必要的帳號存取，避免未授權使用者讀取。例如，本次實驗中的私鑰應由正確帳號擁有，並限制檔案權限，通常可使用 600。

如果發現私鑰曾暴露給未授權使用者，或無法排除已被複製的可能，就應撤銷舊金鑰的授權並更換金鑰。

以本文使用 authorized_keys 的情境來說，需要從相關主機與帳號的授權清單中移除舊公鑰，再部署新公鑰，並妥善保存新的私鑰。

只產生新的金鑰，或只調整原始私鑰的權限，都不會自動讓外流的舊私鑰失效。

小結：持續學習，也持續驗證自己的理解

資安攻防是一條學不完的路。隨著技術與部署方式不斷改變，需要理解的風險也會跟著增加。

曾經聽前輩說過：「十年前做資安，跟十年後做資安，是完全不同的。」現在回頭想，逐漸能理解這句話。許多基礎原理依然重要，但應用的環境與需要注意的細節，會持續改變。

因此，我想鼓勵自己繼續學習，也持續驗證自己的理解：能不能解釋攻擊為什麼成立？知道它造成什麼影響？又能不能提出對應的修正方式？

接下來，我們將從 Linux 主機延伸到容器環境，繼續研究容器的運作方式、可能的攻擊面與防禦措施。前面學到的身分、權限與資源存取觀念，也會成為後續學習的基礎。

明天就從容器的角度出發，看看攻擊者會注意哪些地方。感謝大家的收看，我們明天見！