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

作者簡介：張博，網易高級信息安全工程師。

0x00 簡介

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

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

0x01 常見方式

目前來看，常見的獲取進程創建的信息的方式有以下四種：

1、So preload

2、Netlink Connector

3、Audit

4、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 <stdio.h>

#include <unistd.h>

#include <dlfcn.h>

typedef ssize_t (*execve_func_t)(const char* filename, char* const argv[], char* const envp[]);

static execve_func_t old_execve = NULL;

int execve(const char* filename, char* const argv[], char* const envp[]) {

printf("Running hook\n");

printf("Program executed: %s\n", filename);

old_execve = dlsym(RTLD_NEXT, "execve");

return old_execve(filename, argv, envp);

}

該文件的主要部分就是重新定義了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 安裝得越早越好，儘量在其他應用進程啓動之前就完成安裝。

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

1、無法監控靜態鏈接的程序：目前一些蠕蟲木馬爲了降低對環境的依賴性都是用靜態鏈接，不會加載共享庫，這種情況下這種監控方式就失效了。

2、容易被攻擊者發現並篡改：目前一些蠕蟲木馬本身也會向 /etc/ld.so.preload 中寫入後門，以方便其對機器的持久掌控，這種情況下這種監控方式也會失效。

3、攻擊者可通過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，其核心函數爲以下三個：

1、nl_connect：與內核建立連接

2、set_proc_ev_listen：訂閱進程事件

3、handle_proc_ev：處理進程事件

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

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

獲取到的 pid 之後，再去/proc/<pid>/目錄下獲取進程的詳細信息即可。

使用條件

內核支持 Netlink Connector

1、版本 > 2.6.14

2、內核配置開啓：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 ：

1、apt update && apt install auditd

2、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

優缺點

優點

1、組件完善，使用 auditd 軟件包中的工具即可滿足大部分需求，無需額外開發代碼。

2、相比於 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.通過官方的安裝腳本進行安裝：