文|陳越
我們將該項目開源，希望可以幫助到廣大的信息安全團隊來建設和完善自己的HIDS體系，也希望大家能夠支持並共同維護這個還處於剛起步階段的項目。
項目地址：
https://github.com/DianrongSecurity/AgentSmith-HIDS
HIDS(Host-based Intrusion Detection System)作爲傳統攻防視角的重要一環，有着不可替代的作用，可以有效的檢測到從網絡層面難以發現的安全問題，如：後門，反彈shell，惡意操作，主機組件安全漏洞，系統用戶管理安全問題，主機基線安全風險等。
衆所周知，HIDS開源產品不乏有一些經歷過大量大型甲方考驗的產品，比如大名鼎鼎的OSSEC，也有一些非常完善的產品幫助可以我們建設自己的HIDS，如Linux Audit等。我們曾經嘗試基於OSSEC進行裁剪和二次開發，也曾經試圖藉助Linux Audit的能力獲取用戶操作信息，但是這些嘗試往往因爲性能和資源消耗問題、用戶態監測的信息來源完整性的問題，最終放棄了這種改造方案。在探索嘗試過程中，我們逐漸清晰了點融對於HIDS的需求：
* 靈活且輕量級：對系統資源需求少，系統負載佔用小；
* 有豐富的API和強大的聯動能力：需要可以和我們自研的AgentSmith-NIDS聯動，達到網絡層發現一切安全問題可以追溯到主機層的用戶-進程信息等一些具體細節，不僅方便排查，也可以快速解決誤報，可以更詳細的制定規則；
* 支持基線檢查/系統完整性檢測；
* 支持規則引擎，能夠靈活的進行規則配置(規則引擎最好可以和AgentSmith-NIDS複用)；
* 支持最基本的HIDS功能，如各種主機層安全問題的檢測等；
* 支持和CMDB聯動，支持Docker，可以梳理建立“白名單”(如某應用的對外連接名單，數據庫名單等)。
從上述需求可以看到，完全符合的開源產品並不存在。但是當談論到“安全縱深防禦體系”，就一定繞不開不同層次安全設備的聯動能力，而HIDS、NIDS和CMDB的聯動意義重大，幾乎是一切聯動的基礎。
前文提到的幾種嘗試中，我們曾經着重測試了Linux Audit，但是其對Docker容器的不支持，收集的信息過於碎片化比較成爲問題，最爲關鍵的是，其較爲複雜龐大的架構實現導致對宿主機性能產生了顯著的影響，因此最終放棄。而其他的產品往往過於強調其本身的安全能力，失去了聯動能力，二次開發難度也頗大，因此最終我們選擇了自研之路，試圖打造一款可以符合我們自身期望的產品。
AgentSmith-HIDS從設計伊始，就是以黑客攻擊的Kill Chain作爲出發點，從這個角度分析梳理常見的風險操作，從而確保輕量化和對性能損耗的最小化。我們採用了通過加載LKM來實現Hook execve,
connectinit_module,finit_module 的system_call，execve是爲了捕獲執行的命令來監控異常操作，歸檔等；監控connect是爲了捕獲服務器的網絡行爲，不僅僅可以發現很多安全問題，也可以方便的和AgentSmith-NIDS聯動；監控init_modle和finit_module是爲了監控加載LKM的行爲，可以在這個層面做一些Anti-Rootkit的檢測。
爲什麼要在內核態實現這些Hook呢？因爲我們希望可以儘可能的全面的收集以上信息，避免被繞過。而且在這裏做Hook如果將來需要做一些危險命令等攔截也成爲了可能，如：rm -rf /等。我們認爲，越接近底層，離真相越近。
關於性能，我們爲了儘可能的減少系統負載，放棄了最開始的傳輸方案：netlink，改用共享內存的方式來實現內核態到用戶態到消息傳輸，經過測試對Hook的system_call的性能影響相較於netlink降低30%左右（更加詳細的性能測試報告請見項目內）。
由於Docker的底層實現依賴了Linux namespace，因此我們在Hook的過程中可以很容易的區分信息的來源是宿主機本身還是其上的某個Docker容器，達到對Docker的一定支持，在這裏我們確定了Docker容器信息後便可方便的和我們的CMDB關聯，梳理業務信息等。
以上是AgentSmith-HIDS的LKM模塊的功能，而用戶態的接收端，目前的主要作用是接收LKM傳輸的信息，格式化，傳輸到server端，功能還較爲簡單，開源的部分還不具備檢測能力(規則引擎複用AgentSmith-NIDS規則引擎，聯動能力複用AgentSmith-NIDS，歸檔等其他功能複用AgentSmith-NIDS)，有簡單的心跳檢測支持，斷連自動關閉LKM等，後期會增加基線檢查/系統完整性檢測兩項比較重要的功能。
AgentSmith HIDS整體架構
AgentSmith HIDS實現原理
考慮到AgentSmith-HIDS在縱深防禦體系中的定位和功能需求，我們希望除了監測能力之外，還要保持充分的聯動能力和可擴展性，在規則引擎上，能夠儘量複用我們的AgentSmith-NIDS的規則引擎/聯動/告警/歸檔/異常檢測算法/資產模塊等基礎能力，保持體系的一致性和連貫性。
這樣，一方面能夠儘可能的減少在宿主機的運算，另一方面我們的思路還是“看好兩扇大門”：操作和網絡行爲。因此在第一階段我們捨去了文件變更檢測等功能，而是嘗試通過梳理“白名單”來發現異常。比如，我們規範了線上服務器用戶後，我們不需要監測authorized_keys和/etc/shadow，在異常用戶第一次操作的時候我們便可以關聯到堡壘機或其他地方來檢測該用戶是否有存在的合理性；一切對外連接行爲無論是正常第三方業務調用，DNS，NTP，反彈shell，被C&C上線，各種姿勢的隱祕通道通信，我們都可以通過連接行爲基礎信息(TCP/UDP五元組+nodename+appid)+CMDB+pre環境第三方業務調用名單+DNS/NTP等基礎服務白名單(往往是內部指定)來排除掉正常的連接行爲，而簡單的反彈shell等，規則引擎就可以應付一二。
這樣不僅可以有發現安全問題，歸檔操作等安全能力，還可以來建立起對我們自己業務的熟悉程度，比如：通過HIDS，NIDS，CMDB的關聯，可以快速查詢出數據庫、表和應用的調用訪問關係及相關的db user；我們可以快速的識別到我們整個業務線應用系統調用了哪些第三方服務，在故障應急需要切換線路IP時快速的聯繫對方，將我們新出口的IP加入白名單；還有一些終端信息收集的能力，可以大大的提高我們定位、分析、處置異常的能力，比如以前只有NIDS的時候，端口掃描的策略是通過源IP+被reset的頻率來做的，但是也可能是某些業務調整或者故障引起的，這時候NIDS排查較爲困難，但是有了HIDS的聯動我們可以快速的識別是我們的內部應用還是惡意行爲。
總而言之，我們的HIDS的期望是儘量輕量化，注重聯動能力，儘可能複用已有的基礎能力，二次開發友好，整體思路還是黑名單(規則)+異常檢測+白名單來做，可以參考點融的NIDS的建設思路：http://www.ebwill.com/2018/09/10/DR_NIDS/
AgentSmith-HIDS對二次開發應該是很友好的，基礎的LKM模塊完善程度較高，遵循其共享內存的消息傳輸算法便可獲取信息，項目中有基礎的Demo實現，任何人都可以快速搭建並實現最基礎的信息收集，關於規則引擎的編寫也應該足夠簡單，如果有自己的NIDS，那麼基於TCP/UDP五元組的信息也可以快速聯動，這樣未來發現NIDS告警或者威脅情報告警就再也不用上服務器抓包/手動排查了，通過關聯HIDS的信息就可以有一個基礎的判斷（這是曾經我努力堅持推HIDS的一個重要目標。面對稍縱即逝的短連接和大量的威脅情報告警NIDS提供的有限的信息讓我們判斷是不是誤報都成爲問題）。
最後，該項目是本人的第一個C && Rust項目，時間倉促，開發週期不滿2個月，但已經過點融內部的初期性能、穩定性測試，也歡迎大家把玩測試，希望能在issue區見