HIDS(Host-based Intrusion Detection System)作為網絡安全的最后一條戰線,我們現階段是否處于攻防不對等的地位?現在主流的HIDS的建設思路和方式是否又存在各種不可忽視的缺陷?

1.為何是最后一條戰線

我們面對各種不同的針對生產環境的威脅,攻擊者最終訴求大多是維持一個可長期訪問的/有一定權限的通道,便于從內部尋找弱點,得到想要的諸如核心系統,數據庫,git/svn/郵件系統的權限,從而實現自己的目的.

那么在這么常規的攻擊路徑中,HIDS作為主機層的一雙眼,往往是離真相最近的那一雙,NIDS存在鏡像流量可能不全/HTTPS/加密/規則繞過等問題,而據我的經驗,稍微高級的入侵者往往并不會采用掃描/暴力破解等動作;WAF作為入口的看門大爺往往沒有能力管理從內出去的安全問題;各種架構問題總會導致各處的日志收集不全/或者沒有關鍵上下文難以甄別異常等等.

那么HIDS的作用就異常重要了,即:其他安全防線失效的情況下,HIDS是最后一道防線.如果這里也沒有辦法發現如:后門,webshell等行為,那么企業可能會長期處于被入侵但是自己絲毫不知情的糟糕地步.

2.現在部分的HIDS技術

我們來大概看看現在主流的HIDS部分關鍵技術.

Linux Auditd,作為一款以Hook框架發展起來的安全組件,可以Hook任意Syscall和一些關鍵操作.缺點是性能略差,不支持Namespace(即不支持容器技術,如Docker),還有比如Connect Hook位置靠前導致得不到源端口等小坑,使用Netlink傳輸性能略差,且難以二次開發等.

cn_proc,很多都采用cn_proc來獲取進程創建信息,缺點也是很明顯的,獲取信息缺失嚴重,大多數場景需要自己去/proc取(瞬時進程還取不到),不支持Namespace,用戶態的功能疊加同樣可能會導致性能問題的出現.

用戶態Hook,比如LD_PRELOAD,容易被繞過,且有時不是故意繞過...

clamAV/BusyBox/Rootkit Hunter等其他開源組件,使用規則的問題就是容易被繞過,開源組件拼湊往往難以實現威脅的全覆蓋.

其他系統日志,比如bash_history等等,部分容易被繞過.

3.我們談談繞過的問題

為什么我總是說到被繞過?因為我們防御到不是普通的正常用戶,面對已知的防御能力,入侵者會想出各種的繞過方法,逃避檢測.筆者在之前處理了一起APT攻擊事件,攻擊組織使用了Kernel Rootkit來逃避檢測,而發現時居然已距入侵估計時間節點長達數年之久.

HIDS上一起被繞過的入侵行為,很有可能就是企業安全最不想面對的夢魘,而夢魘來襲,防御者往往毫不知情.

我們隨意例舉幾個筆者所知道的繞過姿勢,如果有參與研發HIDS的甲方/乙方的同事不妨評估一下自己的HIDS是否可以精準捕獲有效數據已足以支撐你們的決策部分作出判斷:

1.更換默認Bash,如csh/zsh

2.巧用shell 命令:

或者:?

3.反彈shell時不用bash,而是cp /usr/bin/bash test,然后使用test進行反彈shell

4.進程注入

5.pwnginx/mod_rootme/Knock-out等“復古后門”

6.各種隱秘通道技術(不僅僅有大家都熟知的DNS/ICMP)

7.Rootkit

7.自定義system_call,逃避Auditd等Hook技術

8.nc -e

9.利用memfd_create無文件滲透/利用ptrace模糊執行參數

仔細思考上面隨便列舉的幾個方法,就會發現,攻防不對等技術一直存在.安全工程師過于理想的考慮攻擊方手段,逐漸失去Hack的本質.大量使用開源檢測組件而逐步失去思考能力,“無開源,不安全” 又導致檢測規則和邏輯逐步被繞過而不知.

對于HIDS的檢測能力,太多的依賴規則和”進程名“這種不可信的信息來源.而想要的到更精準/全面的信息,要么會出現短連接/短進程捕獲不到,性能出現壓力,沒有成熟的開源組件而放棄想法,一直妥協最終出現目前的狀態.

又有多少企業在虛假的安全中而忽視了這些風險呢?我們不得而知.當針對性的攻擊出現時,很可能就是:防御終將失效.

4.我們談談內核態HIDS

筆者之前開源了Hook system_call的HIDS:AgentSmith-HIDS,反響寥寥.大多數的評價是:“內核態不穩定”,我相信大多數評價者應該都沒有使用過/測試過這款開源的產品.習慣性的“Kernel態不穩定”總是政治正確的.當然筆者承認,穩定性和適配性的確是他的一大短板.我們暫且不討論AgentSmith-HIDS,我們聊聊內核態的HIDS有哪些優勢:

性能,內核態HIDS無需遍歷/proc之類的,天然支持Namespace.傳輸方案也可以用共享內存代替Netlink

二次開發友好,想要stdin/out?簡單,幾行代碼的事.想要tgid?簡單.

天然支持微隔離,隔離到進程級別-syscall級別(大多數場景connect應該就夠了)

難以繞過(但還是可能,相對困難些,比如“??/!!”這種還是是無法繞過的)

可以做到一定程度的實時行為檢測Rootkit(之前說的APT的后門就是通過這種方式檢測出的)

內核態HIDS并不全是內核態,通常是LKM+用戶態Agent,所以,可以做到相互補充,用戶態也可以做一些諸如:資產盤點,漏洞檢測.webshell靜態查殺等等行為

監控能力到達syscall級別,面對很多繞過的行為,可以支撐更多的行為監測邏輯.比如上文所述的一些繞過的反彈shell

可以借鑒LKRG(Linux Kernel Runtime Guard)這樣優秀的產品,面對各種Linux Kernel的0day也可以做到一定程度的防御

良好可信的數據收集,帶來的是后續優質的,可持續的,可以作為數據分析的數據源,可以建立不同維度的行為模型來發現更隱蔽的異常

Hook部分syscall甚至可以做到業務級的資產梳理,比如A發出了HTTP的Request,Host是XXX(理論可行)

誠然,依然會有很多缺點,但是內核態HIDS并非僅僅有一個LKM,肯定會伴隨著用戶態Agent的存在,可以發揮的地方比起傳統的HIDS只多不少.整體信息收集能力更可信且難以被繞過,由于有進程的完整的syscall信息(hook的syscall)作為支撐,可以做更多的行為檢測能力,后期也可以向進程級別微隔離/可信計算/Linux Kernel 0day漏洞檢測方向發展,性能/容器化的支持也具有天然優勢.

5.思考

作為防御方,我們應該有哪些盾來抵御潛在的“暗箭”呢?這是每一個防御方都要思考的問題,我們更要思考攻擊者會有那些可能的方法,繞過我們的防御.想想馬奇諾防線吧,臆想的防御方式很有可能不那么奏效.最后,筆者對HIDS的了解和研究也不是很深入,HIDS的學習/研發/測試也只有4-5個月的時間.后來一直在研究其他領域,也歡迎大家提出不同的觀點和意見.

最后,這是筆者和老友Gaba還有另一位安全從業10年的老兵一起創建的公眾號,偶爾發發技術干貨和吐吐槽,歡迎大家關注

總結

以上是生活随笔為你收集整理的为什么我认为现阶段HIDS处于攻防不对等的地位?（ids、nta、绕过）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。