【51CTO.com原創稿件】最近，AC公司組織安全部門對即將上線的一款云交流與協作平臺，在模擬的環境中進行了全方位的滲透測試。大部分測試結果指向的是與Web應用程序有關的安全漏洞，需要項目組的程序員和DBA們進行整改。但是與此同時，也暴露出了一些與平臺部署與環境有關的自身脆弱性問題(如下圖所示)。

[[199289]]

套用OWASP Top 10理論的分析，這些可以歸咎為“A5 – 安全配置的缺失”。雖然從報告結果的嚴重程度來看，不是那么的outstanding，但是這讓一直著眼于軟件程序方面的項目組領導終于頓悟到了那些有別于security coding之類的木桶短板。

的確，安全配置是來不得任何freestyle的，我們要有嚴謹的操作流程和打持久戰的心理準備。那么，怎樣才能做好全面的安全加固準備呢?其實還是有一定套路可循的。基本的思路包括：

• 識別本系統所涉及到的安全配置項。
• 著手按照一定順序，如網絡系統的層次結構，予以實施。
• 初始化建立安全配置的管理。
• 保持并動態維護各種安全配置。

安全配置項：全面私人定制

一般而言，我們可以從“操作系統->Web服務器->應用服務器->數據庫服務器->管理后臺->軟件運行環境”，來逐步深入展開。下面是一些最基本、最普遍的配置項示例，我希望能給小伙伴們帶來火箭一級助推的效果。同時希望大家能自行補齊屬于本企業的“多級助推”，成功high上天。

操作系統-Windows Server：

• 帳號偽裝之真假三人組：先重命名管理員帳戶的名稱，并設置為強密碼，然后禁用該賬號。對!你沒看錯，費這么大勁兒還是要禁用它，原因是此貨的風險太高了。是不是想起了小時候看的電影《鐵面人》路易十四啊?就是這個套路。
• 然后，創建自己的“太陽王”：新的管理員帳戶名稱，是那種自己能識別，別人不太能猜透的名稱，并創建強密碼。隨后，將其加入到Administrators組中。
• 這還不夠，我們還要創建一個“馬甲”管理員，名字還叫做administrator。但是呢，將其放置到guest組里去。
• 按照“先禁用三個月、再刪除”的策略將系統自帶的以Guest為首的一干無用帳號打入冷宮。
• 接著是“約法三章”：通過本地安全策略來加固密碼強度、留存期、帳號鎖定策略，不顯示最后登錄的用戶名、限制軟件的安裝，并添加審核策略。
• 僅限Administrators組具有“本地”、“遠程關機”權限以及“文件或其他對象的所有權權限”，禁用“允許系統在未登錄前關機”，將“本地登錄”和“從網絡訪問”分配給指定的帳號。
• 關閉系統的默認共享，盡量不要使用共享文件夾，非要啟用的，要制定訪問帳號。
• 做好文件權限的保護，在重要文件夾屬性的安全標簽里刪除父項繼承(如下圖)，以及一般用戶組的可修改權限。

• 通過配置日志，使系統能夠“審核登錄事件”、“策略更改”、“對象訪問”、“特權使用”、“系統事件”、“帳戶管理” 以及“ 進程追蹤”。當然也要注意配置日志文件的大小和歸檔。
• 通過對注冊表的鍵值設置，將TCP連接請求數閾值(TcpMaxPortsExhausted)設為5、TCP 半連接數閾值(TcpMaxHalfOpen)設為500、以及重傳的TCP 半連接數閾值TcpMaxHalfOpenRetried設為400，從而實現對SYN攻擊保護。
• 禁用網卡屬性里的TCP/IP上的NetBIOS，以及系統上的服務。
• 關閉默認無用的服務，包括Computer Browser、IP Helper、Print Spooler、Remote Debugging、Remote Registry、TCP/IP NetBIOS Helper 、Windows Remote Management、WinHTTP Web Proxy Auto-Discovery Service、Windows Error Reporting Service等。
• 不允許遠程訪問注冊表、對SAM帳號的匿名枚舉，而啟用對通信進行數字簽名、基于128位加密的NTLM SSP的最小會話安全。
• 通過自動訂閱或定期手動的方式，及時給系統打上補丁。
• 當然也要安裝好主機級的防病毒軟件，并運用工具定期掃描。這一步就像我們小時候經常假想自己擁有的一種特異功能：把耳朵天線打開一樣。

操作系統-Linux：

• 運用passwd -l鎖定不必要的帳號，運用userdel命令刪除不必要的帳號;查看口令為空的帳號并設置復雜密碼;查看UID為0的帳號，并確保只有root。
• 通過在/etc/profile中添加傳說中的“umask 027”，實現新建文件僅“屬主可讀寫，同組用戶只讀和執行，其他用戶根本無權”的默認文件管控。
• 編輯/etc/pam.d/common-auth文件，添加“如果連續輸錯三次密碼，則帳號鎖定半小時”的策略;并編輯/etc/pam.d/su文件，限制能夠su到root的用戶組。
• 通過script實現對全部用戶的登錄進行日志記錄。
• 關閉不必要的服務，并通過編輯/etc/ssh/sshd_config文件，對SSH使用的版本、允許的密碼錯誤次數等進行加固。

Web服務器-Apache/IIS：

• 修改默認帳號及其密碼，創建專門用于運行的用戶帳號和組。
• 嚴格控制主目錄的訪問權限，非特權管理用戶不能修改或寫入該目錄中的內容。
• 通過配置，跟蹤包括時間和用戶使用的 IP 地址等信息，來實現對運行錯誤和用戶訪問等方面的日志記錄。
• 禁止該服務訪問本Web目錄之外的任何文件。
• 禁用或拒絕目錄羅列的功能與瀏覽請求。
• 修改設置錯誤頁面重定向功能，并隱藏版本號及其軟件相關的敏感信息。
• 設置 session的保持時間，以應對DoS攻擊。
• 刪除默認安裝的無用文件、文件夾和腳本。
• 對于Apache，要禁用TRACE、CGI功能;禁用PUT和DELETE等危險的HTTP 方法，僅允許GET和POST方法。
• 對于IIS，禁用掉不必要的Web服務擴展(WebDAV)和應用程序擴展，限定支持的頁面類型。

如前所述，另外還有其他方面需要進行安全加固與配置，這里就不贅述了。我們的基本思路就是：做好賬戶(組)和例程腳本的剪裁，文件(夾)訪問、端口和服務的最小化，會話連接、錯誤信息與日志的設置，管理后臺的更改以及安全補丁與殺毒的更新。

在根據上述流程逐步完成了系統與服務的安全配置，并且導入了相關的業務數據之后，我們就可以進行多種、多次的漏洞掃描和滲透測試了。我們的宗旨就是要在系統的起步階段，盡量掃清如OWASP提及的十大安全隱患。

配置管理庫：自制月光寶盒

如果您是在邊讀邊做的話，那么到這里，恭喜您基本上闖過了“OWASP Top 10的A5—安全配置缺失”這一關。那么該怎么“紀念”一下呢?我們就來個“立此存照”—將這些配置的經驗和方法都錄入到配置管理庫吧。有關配置管理庫的基礎知識，大家可以去問“度娘”，當然也可以通過猛戳這里來進行快速和直接地獲取—http://zhuanlan.51cto.com/art/201612/525020.htm。而這次，我主要跟大家分享的則是有關安全配置項在入庫時和使用中的事項。

• 配置項入庫要做好命名規則的一致性。如：<站點/部門/項目名稱>-<系統/服務名稱>-<主機名或軟件名稱>-<型號/版本信息>-<創建YYYMMDD>。
• 事先為每個配置項定義好豐富的標識類元數據。通過在入庫時填寫相應的完備信息，方便事后對該項的快速查找與定位，從而大幅提高配置項的復用價值。
• 管理庫的目錄結構應當按照服務系統架構里的功能、地域、類型等多個維度進行清晰、全面的設定，以保證配置項能夠直接“拎包入住”，且被正確放置。
• 細粒度地定義各個配置項所在文件夾的所有者，和其對應的訪問權限;禁用直接刪除任何配置項的功能，改用“先標記，7天后系統自動刪除”的策略。我們在實際使用中發現這樣能最大限度地防止誤刪等操作的發生。
• 實現對配置項的版本控制和任何操作的日志記錄與審計功能，就像配備了一臺小型time machine一樣。
• 最后，記得在每一次完成系統或服務的相關配置之后，都要習慣性的將其“快照”下來，做成“配置基線”，添加注解，再備份到配置管理庫中。與此同時還要檢查從庫里簽出的，本次參考過的配置模板和操作指南，確保其可用性，以方便下一次還能夠“開箱即用(OOTB)”。

大家可以試想一下：如果沒有對各種應用安全配置信息的可用性、完整性和有效性的持續管理，我們的系統將如同那艘駛向“三體艦隊”的探測器一樣終將在各種風險因素的作用下完全失控。可見，我們只有通過對配置知識庫的建立和維護，加上一整套行之有效的入庫和簽出管理，才能從源頭上解決以往諸多企業在安全配置上僅能單方面依靠運維大牛的個人經驗與能力的現象。而且，這能夠杜絕各種人工批量操作時的失誤可能性。

變更管理：以萬變應萬變

說了那么多的配置，思路清奇的您是不是已經想到了它那相愛相殺的好基友--變更管理呢?還記得我們在廉環話的變更與發布章節就討論過變更管理的基本概念和流程。這里我給大家補充一些有關配置項變更的內容吧。首先，就算僅僅是對配置管理庫里的配置項基線的細微變更，都要準備一份與之對應的變更請求(Request for Change，RFC)，其中包括：

• 變更發起人與實施人：發起變更請求的不一定是真正實施的人。
• 所涉及到的配置項及類型：服務器、路由交換、存儲設備或軟件相關等。
• 簡單描述：主要是變更意圖、必要性和預期的效果。
• 波及范圍：包括在邏輯上波及的現有IT系統與服務，和在地域上牽扯到的部門、站點或外部客戶。
• 緊急程度：視需要和嚴重程度進行綜合且如實的判斷。
• 請求開始和結束的日期/時間。
• 最重要、最詳細的三大元：實施步驟、后退回滾步驟和完成后的效果測試步驟。
• 附件：可以附上必要的截圖、郵件或文檔，讓變更管理者更為深入和全面的了解該變更的來龍去脈。比如說下圖就是一份標準的虛擬機添加模板。

下面是我們正在使用的一個風險矩陣的示例：

而作為變更管理者最好能夠做到：

• 多找幾個“臭皮匠”組成委員會(Change Control Board，CCB)，既能互為備份，又能集思廣益、風險共擔。
• 手頭應該有一張“事件匯總日歷”，能夠全局性地根據請求時間來判定當日的忙閑程度，從而在批復通知里的批準實施的時間項上做適當的微調。
• 及時地將新批準的變更加入到總日歷對應的時間段中。
• 伺機用現成的模板向變更將要波及到的人群發送服務中斷和變更實施通知。當然，重要的變更可以“說三遍”。
• 針對實施過程中報告上來的變更失敗，既要確保能夠“回滾”到原配置項狀態，又要引入事故或問題管理流程。

小結

通過重視對安全配置的設置和配置管理庫的運維，AC公司的云平臺順利通過了各種后繼的測試與檢驗，并已正常上線。運行至今，按照其項目負責人的說法是：“So far so good，我們的團隊仍和它愉快地玩耍著。”

在這個暑假里，我陪著小孩子經常對弈國際象棋。有一天我突然頓悟到：其實我們平時做的系統安全設置就像下棋一樣，我們并不是比的是誰下得水平高，而比的是誰犯錯少。最后做一個小調查：行文風趣的廉哥和專業高冷的大拿，你更愛看誰的文章呢?留言告訴我吧。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】