為你的自動化基礎設施拉上保險系列之四

安全的運行環境對於雲端服務來說，是個重要的議題，而對於使用者來說更為重要。

因此，對實體或虛擬主機進行弱點檢查與監測，能為雲端服務提供一個安全的基礎，也能滿足組織對於資安的基本要求。然而，安全威脅多樣，且各式作業系統的組態設定又各有巧妙，要如何才能有效率地完成這個工作，對於維運人員來說是相當令人頭疼的事情。

SCAP² (Security Content Automation Protocol) 是由美國國家標準暨技術研究院(National Institute of Standards and Technology, NIST³)所維護與制定的協定，主要用意是為主機的組態設定與安全需求提供一個共同交互與發展的基礎。同時也為 NIST 800-53 關於運行主機的安全要求與最佳實踐提供一個自動化的基礎。

OpenScap⁴ 則是基於 SCAP 的具體實作，它主要透過使用 SCAP 裡的 XCCDF⁵(Extensible Configuration Checklist Description)與 OVAL⁶(Open Vulnerability and Assessment Language)。XCCDF 透過 XML 形式的描述語言具體地提供評估與檢查一個主機時，應該進行的項目列表。測項可能是一些安全需求下的組態設定的檢查，也可能來自 OVAL 所識別的弱點測試。

此篇文章主要是基於 OpenScap 來建立一台稽核用的主機，並且示範性地對另一台虛擬主機進行遠端的掃描。其結果會以 ARF(Asset Report Format)格式輸出，鑒於這份結果報告是易於閱讀的網頁，因此會利用安裝於稽核主機上的 nginx 來觀看。實務上，可能會整合 OSSEC 等安全工具或者是透過腳本運行搭配調閱主機資產，來進行自動化的定時檢測。至於怎樣做最好，還是得回到組織對於安全的要求強度與搭配的資源。以下就開始這個範例的介紹。

環境與套件

擁有一個 GCP 的帳號，更重要的是，它必須設定好如何付 $$
建立一個具有合適權限的服務帳號
安裝 Google Cloud SDK，並且確認已經設定好 application-default
Python 為 3.x <== 這非常重要!!
從 GitHub 下載範例專案
使用 ubuntu 18.04 的 e2-small 實體 x 2

$source venv/bin/activate
$(venv) pulumi config set gcp:zone asia-east1-a
$(venv) pulumi up

套件

由於整個主機建置都已經程式化了，運行起來跑並不是太難。因此，針對一些注意的部分和大家分享一下! VM 的建置本身並不複雜，所以比較需要注意的部分是init_scripts.py，因為相關套件的安排都在初始過程中完成。

首先，要注意的當然是兩台主機都要裝好 libopenscap8。

關於稽核主機部分，則要安裝較新的 ansible。以避免後續進行自動腳本時，踩到已經被提報的問題。另外，則是要下載oscap-ssh工具，以便稍後進行遠端掃描。

$sudo add-apt-repository ppa:ansible/ansible-2.5
$apt-get update
$apt-get install libopenscap8 unzip nginx ansible -y
$wget https://raw.githubusercontent.com/OpenSCAP/openscap/maint-1.3/utils/oscap-ssh
$chmod 755 oscap-ssh
$mv -v oscap-ssh /usr/local/bin

關於受測主機，則是要額外安裝 python!

帳號與SSH

為了能夠進行遠端的掃描，務必確認兩台虛擬主機能夠透過 ssh 進行連線，由於本範例是使用 GCP 提供的 ubuntu 鏡像檔，預設上已經具備相關套件，為了能夠不需要透過密碼登入，必須再配置好稽核帳號與對應的公私鑰。

關於稽核主機的部分
1. 建立 auditor 帳號
2. 配發對應的私鑰與公鑰到 /home/auditor/.ssh中。

📣 需要注意的是稽核帳號的密碼與公私鑰請搭配組織的相關管理工具來進行。範例針對帳號密碼也是預設在初始程式碼裡，這部分主要是考量範例範圍，相關密碼更新與配發還是要看組織規範的狀況而定。

關於受測主機

需要在透過 Pulumi 進行實體建置時，將稽核帳號所對應的公鑰配置好。以範例來說infrabase.py：

    ...
 68   metadata_startup_script=init_scripts.init_client,
 69   metadata={"ssh-keys":"auditor:"+init_scripts.init_client_trusted_key},
 70   opts=ResourceOptions(delete_before_replace=True),
    ...

準備掃描

為了能夠進行掃描，最重要的一步就是在稽核主機下載最新的 SSG(Scap Security Guide)。它基於各類規範(NIST SP-800-53、PCI-DSS 等)與作業系統，提供了對應的檢測清單以及對應的自動化設定腳本。

⚠️ 請確認目前已經切換到稽核帳號 auditor

$auditor/>wget https://github.com/ComplianceAsCode/content/releases/download/v0.1.55/scap-security-guide-0.1.55.zip
$auditor/>unzip scap-security-guide-0.1.55.zip

📣 當前最新的版本是 0.1.55 版。

開始進行掃描!

此範例會採用 standard 的檢測項目，如果有特別需求也可以選用其他項目，比方說 CIS。

$auditor/>oscap-ssh auditor@<client-internal-ip> 22 xccdf eval --profile xccdf_org.ssgproject.
content_profile_standard --report ~/<client-internal-ip>-standard-round1.html ~/scap-security-guide-0.1.55/ssg-ubun
tu1804-ds-1.2.xml

接下來就是等待檢測完成。

檢閱報告與消除弱點

由於沒有額外將報告匯至它處，本範例使用 nginx 來檢視報告。因此，請額外將家目錄中的報告檔案移至 nginx 預設的網站資料夾中

$auditor/> sudo mv <client-internal-ip>-standard-round1.html /var/www/html

檢測報告的統計部分如下：

顯然在直接採用預設的作業系統映像檔，也未對相關分割進行設定，檢測結果肯定不會是all pass。實務上，面對這樣的情況可以有幾種作為：

透過提供的 ansible 腳本進行自動設定，來解決失敗的項目;
透過其他方式進行移除、設定、安裝，抑或者是自製標配 OS 鏡像檔;
利用 OpenScap Workbench 挑選目標的 XCCDF 檔案，進行客製化。簡言之就是將不適合的檢測項目移除;
若企業有定義某層級上的失敗項目，才需解決的話，請無視它 😁

此處，我們就來運行一下 ansible 的自動腳本，看看能改善多少!

$auditor/>cd ~/scap-security-guide-0.1.55/ansible
$auditor/>ansible-playbook -i "<client-internal-ip>," ubuntu1804-playbook-standard.yml -b -u auditor
oscap-ssh auditor@<client-internal-ip> 22 xccdf eval --profile xccdf_org.ssgproject.
content_profile_standard --report ~/<client-internal-ip>-standard-round2.html ~/scap-security-guide-0.1.55/ssg-ubun
tu1804-ds-1.2.xml

結果會是：

失敗項目從 18 項，降至 9 項!

由於有些項目涉及磁區分割，這部分顯然是 OS 的天生問題，另外還有些項目則會涉及重啟主機，由於二測的結果並未重開。因此以這樣的改善幅度來說，對於進行安全維護的任務工作者來說，幫助相當的大，而這也是自動化的好處。

後記

此範例透過一個簡單的場景來介紹如何透過 OpenScap 統一在某台主機上對遠端主機進行掃描。當然 OpenScap 的弱掃的對象也不僅僅只在虛擬主機上，它也能夠應用至容器與容器映像檔上。若能搭配其他的安全工具，則能提供更多主動監測的能力，也因為它將繁雜的安全檢查項目自動化，並且提供對應的自動化解決的腳本，對於擁有多主機的組織與工作者來說更是帶來很大的助益。

最後一個小分享就是放棄使用 ~~openscap-daemon~~ 的念頭吧! 從別的面向上來提供定時排程與監測是比較穩妥的做法和方向 😅

為你的自動化基礎設施拉上保險系列之四 - 主機弱點掃描