貫徹10項原則，構建Linux系統安全體系

通過大量的實踐經驗，我們總結出10個最關鍵且有效的安全原則，分別是縱深防禦、運用PDCA模型、最小權限法則、白名單機制、安全的失敗、避免通過隱藏來實現安全、入侵檢測、不要信任基礎設施、不要信任服務、交付時保持默認是安全的。

1. 縱深防禦

在安全領域，有一種最基本的假設—任何單一的安全措施都是不充分的，任何單一的安全措施都是可以繞過的。

試想一下，在諜戰影片中，最核心的機密文件一般放在哪裏？

最核心的機密文件不會放在別人輕易接觸到的地方，而是放在有重兵把守的深宅大院裏面，房間的門會配置重重的鐵鎖，進入房間後還有保險櫃，打開保險櫃之後，發現原來機密文件還是加密過的。在這樣的場景中，守門的精兵強將、鐵鎖、保險櫃都是防止機密文件被接觸到的防禦手段，加密是最後一道防禦，防止機密文件萬一被竊取後導致的信息泄露。這是典型的縱深防禦的例子。

早在1998年的時候，由美國國家安全局和國防部聯合組織編寫的《信息保障技術框架（Information Assurance Technical Framework，IATF）》開始出版。該書針對美國的“信基礎設施”防護，提出了“縱深防禦策略”（該策略包括了網絡與基礎設施防禦、區域邊界防禦、計算環境防禦和支撐性基礎設施等深度防禦目標）。從此，信息安全領域的縱深防禦的思想被廣泛流傳了下來。

縱深防禦（Defense in depth），也被稱爲“城堡方法（Castle Approach）”，是指在信息系統上實施多層的安全控制（防禦）。實施縱深防禦的目標是提供冗餘的安全控制，也就是在一種控制措施失效或者被突破之後，可以用另外的安全控制來阻擋進一步的危害。換句話說，縱深防禦的目標也就是增加攻擊者被發現的機率和降低攻擊者攻擊成功的機率。

縱深防禦的概念，可以參考圖1：

圖1 縱深防禦體系

如圖1所示，爲了保護核心數據，我們需要在多個層面進行控制和防禦，一般來說包括物理安全防禦（例如，服務器加鎖、安保措施等）、網絡安全防禦（例如，使用防火牆過濾網絡包等）、主機安全防禦（例如，保障用戶安全、軟件包管理和文件系統防護等）、應用安全防禦（例如，對Web應用防護等），以及對數據本身的保護（例如，對數據加密等）。如果沒有縱深防禦體系，就難以構建真正的系統安全體系。

2. 運用PDCA模型

在實施了縱深防禦策略以後，我們還需要不斷的檢查策略的有效性，細緻分析其中潛在的問題，調查研究新的威脅，從而不斷的改進和完善。

我們需要牢記的一句話是“安全不是一勞永逸的，它不是一次性的靜態過程，而是不斷演進、循環發展的動態過程，它需要堅持不懈的持續經營。”因此，筆者認爲，動態運營安全是一條需要持續貫徹的原則，而PDCA模型恰好能有效的輔助這種運營活動。《ISO/IEC 27001:2005 信息安全管理體系規範與使用指南》中也明確指出，“本國際標準採用了‘計劃-執行-檢查-改進’（PDCA）模型去構架全部信息安全管理體系（Information Security Management System，ISMS）流程。”

PDCA（Plan–Do–Check–Act，計劃—執行—檢查—改進），也被稱爲戴明環（Deming Cycle），是在管理科學中常用的迭代控制和持續改進的方法論。PDCA迭代循環所強調的持續改進也正是精益生產（Lean Production）的靈魂。

標準的PDCA循環改進流程如圖2所示：

圖2 標準的PDCA循環改進流程

在安全領域實施PDCA的方法和步驟如下：

計劃階段的任務如下：

• 梳理資產：遺忘的資產往往成爲入侵的目標，也往往導致難以在短時間內發現入侵行爲。對資產“看得全，理的清，查得到”，已經成爲企業在日常安全建設中首先需要解決的問題；同時在發生安全事件時，全面及時的資產數據支持，也將大大縮短排查問題的時間週期，減少企業損失。資產梳理的方法包括使用配置管理數據庫（Configuration Management Database，CMDB）、網段掃描、網絡流量分析、對相關人員（如業務方、運營方、開發方、運維方）進行訪談等。需要梳理的對象包括：服務器IP地址信息（公網、內網）、域名信息、管理平臺和系統地址、網絡設備IP地址信息以及與這些資產相關的被授權人信息。

• 制定安全策略：安全策略既包括安全技術策略，也包括安全管理策略。實現兩手抓，兩手都要硬。安全技術策略，包括安全工具和系統、平臺。如果沒有它們的輔助，那麼就沒有辦法阻止惡意入侵。安全管理策略，包括制度和流程。如果沒有它們發揮強有力的作用，那麼就會使得安全技術策略的效力也大打折扣。

• 制定安全策略的實施方案：在這個階段，需要制定具體的安全策略實施方法、實施負責人、實施步驟、實施週期。

• 制定安全策略的驗證方案：制定驗證方案的的目的，是在檢查階段能夠以此爲基準檢查確認安全策略的有效性。

在執行階段的任務

實施計劃階段制定的方案，包括物理防護、網絡防護、主機防護、應用防護和數據防護以及安全管理制度的實施。

在檢查階段的任務

按照計劃階段制定的驗證方案驗證安全策略的有效性，從而確認安全策略的效果，包括自我檢查、漏洞掃描、網絡掃描、應用掃描、滲透測試等，也包括安全管理制度實施效果的檢查。這一階段的成果是下一階段的輸入。

在改進階段的任務

以檢查階段的輸出爲指導，完善安全策略，進入下一個升級迭代。

3. 最小權限法則

最小權限法則（Principle of Least Privilege，PoLP）是指僅僅給予人員、程序、系統最小化的、恰恰能完成其功能的權限。

在系統運維工作中，最小化權限法則應用的一些例子包括：

• 服務器網絡訪問權限控制。例如，某些後端服務器不需要被外部訪問，那麼在部署時，就不需要給予公網IP地址。這些服務器包括MySQL、Redis、Memcached以及內網API服務器等。

• 使用普通用戶運行應用程序。例如，在Linux環境中，監聽端口在1024以上的應用程序，除有特殊權限需求以外，都應該使用普通用戶（非root用戶）來運行。在這種情況下，可以有效的降低應用程序漏洞帶來的風險。

• 爲程序設置Chroot環境。在經過Chroot之後，程序所能讀取和寫入到的目錄和文件將不在是舊系統根下的而是新根下（即被指定的新的位置）的目錄結構和文件。這樣，即使在最糟糕的情況下發生了入侵事件，也可以組織黑客訪問到系統的其他目錄和文件。

• 數據庫訪問控制。例如，針對報表系統對MySQL數據庫的訪問控制，一般情況下，授予SELECT權限即可，而不應該給予ALL的權限。

在運維和運營過程中，未遵循最小權限法則將會對系統安全造成極其嚴重的威脅。例如，根據The Hack News網站報道，運行在公網上、未使用認證的Redis服務器中高達75%已經被黑客入侵。造成該嚴重安全問題的重要原因之一就是未遵循最小權限法則來限制Redis服務器其對外服務和使用較低權限的用戶啓動Redis服務。

4. 白名單機制

白名單機制（Whitelisting）明確定義什麼是被允許的，而拒絕所有其他情況。

白名單機制和黑名單機制（Blacklisting）相對，後者明確定義了什麼是不被允許的，而允許所有其他情況。單純使用黑名單機制的顯而易見的缺陷是，在很多情況下，我們是無法窮盡所有可能的威脅的；另外，單純使用黑名單機制，也可能會給黑客通過各種變形而繞過的機會。使用白名單機制的好處是，那些未被預期到的新的威脅也是被阻止的。例如，在設置防火牆規則時，最佳實踐是在規則最後設置成拒絕所有其他連接而不是允許所有其他連接。本書“第2章 Linux網絡防火牆”中正是使用了這一原則來進行網絡防護。

5. 安全的失敗

安全的失敗（Fail Safely）是指安全的處理錯誤。安全的處理錯誤是安全編程的一個重要方面。

在程序設計時，要確保安全控制模塊在發生異常時是遵循了禁止操作的處理邏輯。如代碼清單1-1所示：

代碼清單1-1 不安全的處理錯誤

isAdmin = true;
try {
    codeWhichMayFail();
    isAdmin = isUserInRole(“Administrator”);
}
catch (Exception ex)
{
    log.write(ex.toString());
}

如果codeWhichMayFail()出現了異常，那麼用戶默認就是管理員角色了，這顯然導致了一個非常嚴重的安全風險。

修復這個問題的處理方式很簡單，如代碼清單1-2所示。

代碼清單1-2 安全的處理錯誤

isAdmin = false;
try {
    codeWhichMayFail();
    isAdmin = isUserInrole( "Administrator" );
}
catch (Exception ex)
{
    log.write(ex.toString());
}

在代碼清單1-2中，默認用戶不是管理員角色，那麼即使codeWhichMayFail()出現了異常也不會導致用戶變成管理員角色。這樣就更加安全了。

6. 避免通過隱藏來實現安全

通過隱藏來實現安全（Security by obscurity）是指通過試圖對外部隱藏一些信息來實現安全。舉個生活中的例子。把貴重物品放在車裏，然後給它蓋上一個報紙，我們就認爲它安全無比了。這就大錯特錯了。

在信息安全領域，通過隱藏來實現安全也是不可取的。例如，我們把Redis監聽端口從TCP 6379改成了TCP 6380但依然是放在公網上提供服務並不明顯提高Redis的安全性。又例如我們把WordPress的版本號隱藏掉就認爲WordPress安全了也是極其錯誤的。當前互聯網的高速連接速度和強大的掃描工具已經讓試圖通過隱藏來實現安全越來越變得不可能了。

7. 入侵檢測

在入侵發生後，如果沒有有效的入侵檢測系統（Intrusion Detection System，IDS）的支持，我們的系統可能會長時間被黑客利用而無法察覺，導致業務長期受到威脅。例如，在2018年9月份，某知名國際酒店集團爆出發現約5億預定客戶信息發生泄露，但經過嚴密審查發現，其實自2014年以來，該集團數據庫就已經持續的遭到了未授權的訪問。該事件充分證明了建設有效入侵檢測系統的必要性和急迫性。

入侵檢測系統，按照部署的位置，一般可以分爲網絡入侵檢測系統和主機入侵檢測系統。

• 網絡入侵檢測系統部署在網絡邊界，分析網絡流量，識別出入侵行爲。

• 主機系統檢測系統部署在服務器上，通過分析文件完整性、網絡連接活動、進程行爲、日誌字符串匹配、文件特徵等識別出是否正在發生入侵行爲或者判斷出是否已經發生入侵行爲。

8. 不要信任基礎設施

在信息安全領域有一種誤解，那就是“我使用了主流的基礎設施，例如網站服務器、數據庫服務器、緩存服務器，因此我不需要額外防護我的應用了。我完全依賴這些基礎設施提供的安全措施。”

雖然主流的信息基礎設施在設計和實現時會把安全放在重要的位置，但是如果沒有健壯的驗證機制和安全控制措施，這些應用反而成爲基礎設施中顯而易見的攻擊點，使得黑客通過應用漏洞完全控制基礎設施。

Weblogic這樣一個廣泛使用的Web容器平臺就曾經爆發過嚴重的安全漏洞。例如，在2017年12月末，國外安全研究者K.Orange在Twitter上爆出有黑產團體利用Weblogic反序列化漏洞（CVE-2017-3248）對全球服務器發起大規模攻擊，大量企業服務器已失陷且被安裝上了watch-smartd挖礦程序。這個例子告訴我們，要時時刻刻關注信息基礎設施的安全，及時修正其存在的安全缺陷。

9. 不要信任服務

這裏的服務是指任何外部或者內部提供的系統、平臺、接口、功能，也包括自研客戶端和作爲客戶端功能的軟件，例如瀏覽器、FTP上傳下載工具等。

在實踐中，我們常常見到，對於由外部第三方提供的服務，特別是銀行支付接口、短信通道接口，應用一般都是直接信任的，對其返回值或者回調請求缺少校驗。同樣，對於內部服務，應用一般也是直接信任的。事實上，這種盲目的信任關係會直接導致嚴重的安全風險。如外部和內部服務被成功控制後，我們的業務也可能會受到直接影響。來自自研客戶端或者作爲客戶端功能的軟件的數據，更是應該進行嚴格校驗的，因爲這些數據被惡意篡改的概率是非常大的。例如，黑客通過逆向工程（Reverse Engineering）對自研客戶端進行反編譯（Decompilation）往往可以直接分析出客戶端和服務器端交互的數據格式從而可以進一步模擬請求或者僞造請求而嘗試入侵。

10. 交付時保持默認是安全的

在交付應用時，我們要保證默認情況下的設置是安全的。比如，對於有初始密碼的應用，我們要設置較強的初始密碼，並且啓用密碼失效機制來強制用戶在第一次使用的時候就必須修改掉默認密碼。另一個例子是虛擬機鏡像的交付。我們在燒製虛擬機鏡像的時候，應該對鏡像進行基礎的安全設置，這包括刪除無用的系統默認賬號、默認密碼設置、防火牆設置、默認啓動的應用剪裁等。在虛擬機鏡像交付給用戶以後，用戶可以按照實際需要再進行優化和完善，以滿足業務需求。

本文內容來自作者圖書作品《Linux系統安全：縱深防禦、安全掃描與入侵檢測》，點擊購買。