APAC 系統的 Linux 基礎設施加固
目錄
大多數生產 Linux 系統與其預設配置的接近程度，超出了任何人願意承認的範圍。加固文件是存在的，往往還是多年前為某次審計而寫的，但伺服器與文件並不一致。“文件化的基線"與"實際配置"之間的差距，正是攻擊者穩定棲身的地方。
Linux 加固就是彌合這一差距的學科，而且要以能挺過下一次部署的方式來完成。
預設配置是起點，不是安全姿態 #
預設安裝的 Linux 優先考慮相容性而非安全性。它自帶你用不到的服務、你不需要的核心特性，以及只夠桌面使用、遠不足以應對被攻陷的生產主機的日誌配置。加固就是把這臺通用機器改造成專用機器的過程。
主要工作分幾類：
- 核心與 sysctl 調優：網路防護（如忽略 ICMP 重定向、啟用源路由過濾）、檔案系統限制，以及地址空間佈局隨機化等記憶體保護。
- 服務最小化：禁用並移除主機上不執行的東西，讓不存在被利用價值的閒置元件留在系統裡。
- 強制訪問控制：SELinux 或 AppArmor，約束處理程序可以做什麼，即使它已被攻陷。
- Systemd 與容器加固：丟棄 capabilities、封禁原始套接字訪問，並用 seccomp 配置檔案限制系統呼叫。
- 審計與日誌：捕獲真正重要的事件，並傳輸出主機之外，讓攻擊者無法抹掉自己的痕跡。
CIS Benchmarks 仍然是這些控制措施最實用、認可度最高的成文標準， OpenSCAP 則將應用與審計自動化。
配置即程式碼，否則等於不存在 #
躺在 wiki 裡的加固指南只是一份願望清單。活在程式碼裡的加固（一個 Ansible role、一個 Packer 映象、一條 Kubernetes 准入策略）才是事實。當基線成為程式碼，三件事隨之改變：
- **它是可復現的。**每一臺新主機都繼承基線，而不只是那些恰好有人記得配置的主機。
- **它是可測試的。**CI 中的合規掃描會在配置漂移時讓構建失敗。
- **它是可評審的。**基線的變更就是一次 pull request，遵循與應用程式碼相同的評審紀律。
這就是"一年一次的加固活動"與"平臺固有屬性"之間的區別。
不可變基礎設施是終點 #
合乎邏輯的終局是不可變基礎設施：主機和容器從不原地打補丁，只會被替換。新映象被構建、掃描、部署；舊映象被銷燬。配置漂移成為不可能，因為沒有可以漂移的東西：執行中的系統就是一個構建產物。
不可變基礎設施與程式碼化加固天然搭配。你維護的不再是基線，而是在把安全性編譯進映象。當漏洞出現時，修復方式是一次重建，而不是深夜的一場 SSH 會話。
主機之外 #
加固不會止步於作業系統。同樣的紀律會向多個方向延伸，每個方向都有自己的失效模式。
容器繼承一切，還會疊加自己的風險。 從未加固的基礎映象層構建出來的容器映象，會把主機層面的所有弱點帶進執行它的每一個 Pod。解決方案在上游：最小化基礎映象、在 CI 中掃描、以非 root 身份執行並掛載只讀檔案系統、裁剪 capabilities，以及用 seccomp 配置檔案把 syscall 限制在工作負載真正需要的範圍內。預設 seccomp 配置已經攔截了不少；再根據實際觀察到的 syscall 行為定製一份配置，就能覆蓋剩餘部分。Kubernetes 准入策略在整個叢集層面強制執行這一切，讓不符合標準的部署根本無法被排程。
OT 環境的賭注更高。 在工業和運營技術場景中，加固與可用性的衝突是辦公 IT 從未見過的。一條錯誤套用的 CIS 控制項落在樓宇管理系統、產線 PLC 網路或醫院裝置分割槽上，產生的不是一條 finding，而是停機：有時還牽涉人身安全。因此 OT 加固的順序正好相反：先做被動監測和資產盤點，變更安排在維護視窗內並附帶回滾方案，控制措施先在與生產一致的映象環境中試點。IT 問的是"這個系統安全嗎？"，OT 必須問的是"我們能不能在不讓它停下來的前提下保護它？”
漂移檢測閉環。 基線會在日常變更中退化：工程師為了除錯開啟一個埠，某個安裝程式重新啟用了一項服務，一個熱修復沒有回寫進程式碼。沒有檢測機制，今天加固到位的主機就是明年的軟肋。有效的模式是：每日定時掃描，將線上主機和映象與程式碼化基線比對，發現的結果作為告警直接路由給責任人，而不是歸檔進沒人讀的季度報告。一天內發現的漂移是一張工單；一年後才發現的漂移是一場事件調查。
加固到位的主機，如果背後掛著一個過度寬鬆的雲 IAM 角色，或者身處未經掃描的容器流水線，依然處於暴露之中。最持久的姿態是把主機基線、容器構建鏈、雲配置和身份邊界當作同一個連續的表面來對待，並以這種方式監控它。
我們的 Linux 與基礎設施加固以程式碼形式交付基線和自動化的漂移檢測； 配置與架構評估則審查主機周邊的雲與身份層。想要全貌， 請預約一次工程與範圍界定會談。