技術分享 | Linux 入侵檢測中的程式建立監控

作者簡介：張博，網易高階資訊保安工程師。

0x00 簡介

在入侵檢測的過程中，程式建立監控是必不可少的一點，因為攻擊者的絕大多數攻擊行為都是以程式的方式呈現，所以及時獲取到新程式建立的資訊能幫助我們快速地定位攻擊行為。

本文將介紹一些常見的監控程式建立的方式，包括其原理、Demo、使用條件和優缺點。行文倉促，如果有哪些錯誤和不足，還望大家批評指正。

0x01 常見方式

目前來看，常見的獲取程式建立的資訊的方式有以下四種：

• So preload
• Netlink Connector
• Audit
• Syscall hook

下面我們就從原理、Demo、使用條件和優缺點來了解一下這四種方式。

0x02 So preload

原理

首先跟大家介紹兩點基礎知識：

1.Linux 中大部分的可執行程式是動態連結的，常用的有關程式執行的函式例如 execve均實現在 libc.so 這個動態連結庫中。

2.Linux 提供了一個 so preload 的機制，它允許定義優先載入的動態連結庫，方便使用者有選擇地載入不同動態連結庫中的相同函式。

結合上述兩點不難得出，我們可以透過 so preload 來覆蓋 libc.so 中的 execve等函式來監控程式的建立。

Demo

下面我們就來實現一個簡單的 demo 。

1.建立檔案 hook.c ，內容如下：

#define _GNU_SOURCE

#include

該檔案的主要部分就是重新定義了 execve函式，在原始的 execve執行之前列印可執行檔案的名字。

2.生成動態連結庫：gcc hook.c-fPIC-shared-o hook.so

3.將上面生成的動態連結庫註冊成 preload ：echo'/path/to/hook.so'>/etc/ld.so.preload

4.退出當前 shell 並重新登入（下面會講原因），執行命令即可看到我們編寫的程式碼已被執行：

使用條件

該方法沒有什麼條件限制，只需有 root 許可權即可（做入侵監控程式 root 許可權是必需的，後面的幾種方法預設也都是在 root 許可權下）。

優缺點

優點

• 輕量級，只修改庫函式程式碼，不與核心進行互動。

缺點

對於使用方法的第四步，可能大家會有疑問：為什麼一定要重新獲取 shell 才可以看到效果呢？這是因為其實在當前 shell 下執行命令（也就是執行 execve）的實際上是當前的 shell 可執行程式，例如 bash ，而 bash 所需的動態連結庫在其開始執行時就已確定，所以我們後續新增的 preload 並不會影響到當前 bash ，只有在新增 preload 之後建立的程式才會受 preload 的影響。這也就得出了該方法的第一個缺點：

• 只能影響在 preload 之後建立的程式，這就需要檢測 Agent 安裝得越早越好，儘量在其他應用程式啟動之前就完成安裝。

除此之外還有以下幾點缺點：

• 無法監控靜態連結的程式：目前一些蠕蟲木馬為了降低對環境的依賴性都是用靜態連結，不會載入共享庫，這種情況下這種監控方式就失效了。
• 容易被攻擊者發現並篡改：目前一些蠕蟲木馬本身也會向 /etc/ld.so.preload 中寫入後門，以方便其對機器的持久掌控，這種情況下這種監控方式也會失效。
• 攻擊者可透過 int80h繞過 libc 直接呼叫系統呼叫，這種情況下這種監控方式也會失效。

0x03 Netlink Connector

原理

在介紹 Netlink Connector 之前，首先了解一下 Netlink 是什麼，Netlink 是一個套接字家族（socket family），它被用於核心與使用者態程式以及使用者態程式之間的 IPC 通訊，我們常用的 ss命令就是透過 Netlink 與核心通訊獲取的資訊。

Netlink Connector 是一種 Netlink ，它的 Netlink 協議號是 NETLINK_CONNECTOR，其程式碼位於 https://github.com/torvalds/linux/tree/master/drivers/connector 中，其中 connectors.c 和 cnqueue.c 是 Netlink Connector 的實現程式碼，而 cnproc.c 是一個應用例項，名為程式事件聯結器，我們可以透過該聯結器來實現對程式建立的監控。

系統架構：

（圖片來源：https://www.slideshare.net/kerneltlv/kernel-proc-connector-and-containers）

具體流程：

（圖片來源：https://4hou.win/wordpress/?p=29586）

圖中的 ncp 為 Netlink Connector Process，即使用者態我們需要開發的程式。

Demo

在 Github 上已有人基於程式事件聯結器開發了一個簡單的程式監控程式：https://github.com/ggrandes-clones/pmon/blob/master/src/pmon.c ，其核心函式為以下三個：

• nl_connect：與核心建立連線
• set_proc_ev_listen：訂閱程式事件
• handle_proc_ev：處理程式事件

其執行流程正如上圖所示。

我們透過 gcc pmon.c-o pmon生成可執行程式，然後執行該程式即可看到效果：

獲取到的 pid 之後，再去 /proc/<pid>/目錄下獲取程式的詳細資訊即可。

使用條件

核心支援 Netlink Connector

• 版本 > 2.6.14
• 核心配置開啟： cat/boot/config-$(uname-r)|egrep'CONFIG_CONNECTOR|CONFIG_PROC_EVENTS'

優缺點

優點

• 輕量級，在使用者態即可獲得核心提供的資訊。

缺點

• 僅能獲取到 pid ，詳細資訊需要查 /proc/<pid>/，這就存在時間差，可能有資料丟失。

0x04 Audit

原理

Linux Audit 是 Linux 核心中用來進行審計的元件，可監控系統呼叫和檔案訪問，具體架構如下（圖片來源：https://slack.engineering/syscall-auditing-at-scale-e6a3ca8ac1b8）：

1.使用者透過使用者態的管理程式配置規則（例如圖中的 go-audit ，也可替換為常用的 auditd ），並透過 Netlink 套接字通知給核心。

2.核心中的 kauditd 透過 Netlink 獲取到規則並載入。

3.應用程式在呼叫系統呼叫和系統呼叫返回時都會經過 kauditd ，kauditd 會將這些事件記錄下來並透過 Netlink 回傳給使用者態程式。

4.使用者態程式解析事件日誌並輸出。

Demo

從上面的架構圖可知，整個框架分為使用者態和核心態兩部分，核心空間的 kauditd 是不可變的，使用者態的程式是可以定製的，目前最常用的使用者態程式就是 auditd ，除此之外知名的 osquery 在底層也是透過與 Audit 互動來獲取程式事件的（https://medium.com/palantir/auditing-with-osquery-part-one-introduction-to-the-linux-audit-framework-217967cec406）。下面我們就簡單介紹一下如何透過 auditd 來監控程式建立。

首先安裝並啟動 auditd ：

• apt update && apt install auditd
• systemctl start auditd && systemctl status auditd

auditd 軟體包中含有一個命名行控制程式 auditctl，我們可以透過它在命令列中與 auditd 進行互動，用如下命令建立一個對 execve這個系統呼叫的監控：

• auditctl -a exit,always -F arch=b64 -S execve

再透過 auditd 軟體包中的 ausearch來檢索 auditd 產生的日誌：

• ausearch -sc execve | grep /usr/bin/id

整個過程的執行結果如下：

至於其他的使用方法可以透過 man auditd和 man auditctl來檢視。

使用條件

核心開啟 Audit

• cat/boot/config-$(uname-r)|grep^CONFIG_AUDIT

優缺點

優點

• 元件完善，使用 auditd 軟體包中的工具即可滿足大部分需求，無需額外開發程式碼。
• 相比於 Netlink Connector ，獲取的資訊更為全面，不僅僅是 pid 。

缺點

• 效能消耗隨著程式數量提升有所上升，需要透過新增白名單等配置來限制其資源佔用。

0x05 Syscall hook

上面的 Netlink Connector 和 Audit 都是 Linux 本身提供的監控系統呼叫的方法，如果我們想擁有更大程度的可定製化，我們就需要透過安裝核心模組的方式來對系統呼叫進行 hook 。

原理

目前常用的 hook 方法是透過修改 sys_call_table（ Linux 系統呼叫表）來實現，具體原理就是系統在執行系統呼叫時是透過系統呼叫號在 sys_call_table中找到相應的函式進行呼叫，所以只要將 sys_call_table中 execve對應的地址改為我們安裝的核心模組中的函式地址即可。

具體的實現細節可參考 YSRC 的這篇關於馭龍 HIDS 如何實現程式監控的文章：https://mp.weixin.qq.com/s/ntE5FNM8UaXQFC5l4iKUUw ，這裡貼出文章裡的一張圖方便大家對整個流程有個直觀地瞭解：

Demo

關於 Syscall hook 的 Demo ，我在 Github 上找了很多 Demo 程式碼，其中就包括馭龍 HIDS 的 hook 模組，但是這些都無法在我的機器上（ Ubuntu 16.04 Kernel 4.4.0-151-generic ）正常執行，這也就暴露了 Syscall hook 的相容性問題。

最後我決定使用 Sysdig 來進行演示，Sysdig 是一個開源的系統監控工具，其核心原理是透過核心模組監控系統呼叫，並將系統呼叫抽象成事件，使用者根據這些事件定製檢測規則。作為一個相對成熟的產品，Sysdig 的相容性做得比較好，所以這裡用它來演示，同時也可以方便大家自己進行測試。

具體步驟如下：

1.透過官方的安裝指令碼進行安裝：

curl-s https://s3.amazonaws.com/download.draios.com/stable/install-sysdig | sudo bash

2.檢測核心模組是否已經安全：lsmod|grep sysdig

3.啟動對 execve的監控：sysdig evt.type=execve

最終的執行效果如下：

有關於 Sysdig 的更多資訊可以訪問其 wiki 進行獲取，另外，Sysdig 團隊推出了一個專門用於安全監控的工具 Falco ，Falco 在 Sysdig 的基礎上抽象出了可讀性更高的檢測規則，並支援在容器內部署，同樣，大家如果感興趣可以訪問其 wiki 獲取更多資訊。

使用條件

• 可以安裝核心模組。
• 需針對不同 Linux 發行版和核心版本進行定製。

優缺點

優點

• 高定製化，從系統呼叫層面獲取完整資訊。

缺點

• 開發難度大。
• 相容性差，需針對不同發行版和核心版本進行定製和測試。

0x06 總結

本文共講了4種常見的監控程式建立的方法，這些方法本質上是對庫函式或系統呼叫的監控，各有優劣，這裡我再各用一句話總結一下：

• So preload ：Hook 庫函式，不與核心互動，輕量但易被繞過。
• Netlink Connector ：從核心獲取資料，監控系統呼叫，輕量，僅能直接獲取 pid ，其他資訊需要透過讀取 /proc/<pid>/來補全。
• Audit ：從核心獲取資料，監控系統呼叫，功能多，不只監控程式建立，獲取的資訊相對全面。
• Syscall hook ：從核心獲取資料，監控系統呼叫，最接近實際系統呼叫，定製度高，相容性差。

對我個人來講，單純地看監控程式建立這方面，我還是更推薦使用 Netlink Connector 的方式，這種方式在保證從核心獲取資料的前提下又足夠輕量，方便進行定製化開發。如果是想要進行全方面的監控包括程式、網路和檔案，Audit 是一個不錯的選擇。

另外本文是以 Demo 的形式對功能進行介紹，主要是想起到一個拋磚引玉的作用，至於各方法的穩定性並沒有進行充分地測試，如果各位有這方面的測試資料歡迎在這裡和大家分享討論。

0x07 參考

https://4hou.win/wordpress/?p=29586

https://tech.meituan.com/2019/01/17/distributed-hids-cluster-architecture-design.html

https://www.ibm.com/developerworks/cn/linux/l-lo-use-space-audit-tool/index.html

https://linux-audit.com/configuring-and-auditing-linux-systems-with-audit-daemon/

https://my.oschina.net/macwe/blog/603583

https://mp.weixin.qq.com/s/ntE5FNM8UaXQFC5l4iKUUw

https://mp.weixin.qq.com/s?__biz=MzUzODQ0ODkyNA==&mid=2247483854&idx=2&sn=815883b02ab0000956959f78c3f31e2b&scene=21

https://github.com/draios/sysdig

https://github.com/falcosecurity/falco