很多時候我們為了安全審計或者故障跟蹤排錯，可能會記錄分析主機系統的操作行為。比如在系統中新增了一個用戶，修改了一個文件名，或者執行了一些命令等等，理論上記錄的越詳細, 越有利于審計和排錯的目的。不過過剩的記錄也會為分析帶來不少麻煩， 尤其是將很多主機的記錄行為發送到固定的遠程主機中，數據越多，分析的成本便越大。

實際上，絕大多數的系統行為都是重復多余的，比如 cron 任務計劃，我們信任的程序等, 這些都會產生大量的記錄，但很少用于審計分析?；谶@個需求，我們在審計系統操作行為的時候，至少應該添加一些過濾規則，避免記錄過多的無用信息，比如重復的 cron 任務操作，同時也要避免記錄一些敏感信息，比如帶密碼的命令行操作。滿足這些需求后，我們在審計系統操作行為的時候應該遵照以下準則：

忽略 cron，daemon 產生的記錄；

忽略帶密碼的敏感命令行或腳本操作記錄；

忽略監控用戶（比如 nagios，zabbix，promethus 等）產生的記錄；

忽略頻繁產生日志的操作行為；

第二點為可選項，在以明文方式傳輸到遠程日志服務器的時候，我們建議忽略記錄。第四點則需要著重強調，比如我們記錄一臺 web 主機中的所有 connect，accept 網絡系統調用操作，雖然可以據此分析該主機所有的網絡訪問請求，達到安全或者故障定位的目的，但是這兩個系統調用可能在短時間內產生大量的日志，對 kernel 和網絡日志傳輸都會產生不小的壓力，這種大海撈針似的審計方式我們不推薦直接在線上主機中使用，建議僅在需要定位問題的時候啟用。

下面我們主要介紹有哪幾種方式可以實現系統操作的審計：

• history 記錄方式

• 定制 bash 記錄方式

• snoopy 記錄方式

• auditd 記錄方式

• eBPF 記錄方式

history 記錄方式

history 方式 很傳統也很簡單，本質上是將歷史的命令發送到 syslog 日志中，可以用來簡單記錄用戶的命令操作歷史。但是這種方式有幾個重要的缺點，并不適合審計的目的：

容易被修改，被繞過；

記錄太簡單，沒有上下文信息(比如 pid, uid, sid 等)；

無法記錄 shell 腳本內的操作；

無法記錄非登錄的操作；

難以實現過濾規則；

定制 bash 記錄方式

定制 bash 方式 比較冷門，本質上是為 bash 源程序增加審計日志的功能，開發者可以據此添加一些操作命令的上下文信息，不過很難記錄子進程的信息，其缺點和上述的 history 方式類似:

容易被繞過，用戶可以使用 csh，zsh 等；

無法記錄 shell 腳本內的操作；

過濾規則可能單一；

可能需要不停的更新 bash 版本，工作量大，否則容易被發行版替換；

snoopy 記錄方式

snoopy 方式相對新穎，本質上是封裝了 execv，execve 系統調用，以系統預加載（preload）的方式實現記錄所有的命令操作。更多介紹可以參考以前的文章 snoopy 如何記錄系統執行過的命令。目前大部分系統執行命令時都通過 execv，execve 系統調用執行，這點就和會話無關，幾乎所有的情況下，只要通過這兩個系統調用執行命令，就會將操作行為記錄下來，從目前的最新版本（2.4.8）來看，snoopy 有幾個優點：

難以繞過，只要設置了 PRELOAD，就肯定會記錄；

無論是否存在 tty 會話，都會記錄 execv，execve 相關的命令行操作，包含詳細的進程上下文信息；

可以記錄 shell 腳本內部的操作行為，腳本內的命令行操作大部分都會調用 execv，execve；

可以記錄操作行為的參數， 比如指定了用戶名，密碼等；

過濾規則豐富，可以忽略指定 daemon，uid，也可以僅記錄指定的 uid；

如下日志示例：

Oct 27 11:34:31 cz-t1 snoopy[24814]: [time_ms:778 login:cz uid:0 pid:24814 ppid:24676 sid:24579 tty:/dev/pts/0 cwd:/root filename:/bin/uptime username:root]: uptime -p

上述日志顯示 root 用戶執行了uptime命令，參數包含?-p對應的進程上下文信息都比較全，不過 snoopy 的缺點也比較明顯，主要包含以下幾點：

僅支持 execv，execve 相關系統調用的操作；

不設置規則可能產生的日志過多，對日志搜集系統造成很大的負擔；

暫不支持過濾敏感信息規則；

在實際的使用中，snoopy 記錄方式可以很詳細的記錄所有的命令操作信息，幫助我們定位很多疑難問題。不過我們也需要通過過濾規則來避免產生過多的信息，snoopy 的過濾規則可以滿足以下需求：

忽略 cron，daemon 產生的記錄；

忽略監控用戶（比如 nagios，zabbix，promethus 等）?產生的記錄；

比如以下配置，即可忽略 crond，my-daemon 守護進程，忽略 zabbix 用戶：

# zabbix uid 為 992filter_chain = exclude_uid:992;exclude_spawns_of:crond,my-daemon

備注：過濾規則在（filtering.c - snoopy_filtering_check_chain）函數實現，由 log.c - snoopy_log_syscall_exec 函數調用，過濾規則為事后行為，即在打印日志的時候判斷是否滿足過濾規則，并非事前行為。

另外，我們在 snoopy 的基礎上增加了 exclude_comm 過濾規則，我們可以忽略記錄指定的命令，比如以下：

filter_chain = exclude_uid:992;exclude_comm:mysql,mongo,redis-cli

exclude_comm 指定忽略以 mysql，mongo 和 redis-cli 工具執行的命令，很多管理員或者腳本在使用這些工具的時候常常會加上用戶密碼信息，這在明文環境中是很危險的行為，exclude_comm 規則簡單的避免了常用工具泄漏敏感信息的隱患。

auditd 記錄方式

auditd 記錄方式 本身存在內核層面(kauditd 進程)的支持，它實現了一個大而全的框架，幾乎能監控所有想監控的指標，不管是按照訪問模式，系統調用還是事件類型觸發，都能滿足監控需求。因為其提供了內核層面的支持，所以本質上比起 snoopy(僅封裝 execv，execve 系統調用)要更加強大和健全。

生成的日志也容易查看，進程的上下文信息，參數信息都很全面，如下所示：

type=SYSCALL msg=audit(1603800704.305:5304075): arch=c000003e syscall=59 success=yes exit=0 a0=1c79fd0 a1=1bf51a0 a2=1bd4450 a3=7ffe7270d320 items=2 ppid=95264 pid=99702 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=571973 comm="mysql" exe="/usr/bin/mysql" key="command"type=EXECVE msg=audit(1603800704.305:5304075): argc=5 a0="/usr/bin/mysql" a1="-h" a2="127.0.0.1" a3="-P" a4="3301"

auditd 整體上為分離的架構，auditctl 可以控制 kauditd 生成記錄的策略，kauditd 生成的記錄事件會發送到 auditd 守護程序，audisp 可以消費 auditd 的記錄到其它地方。其主要的幾個工具包含如下:

auditd 的策略規則主要根據 -a 或 -w 參數設置，可以將策略規則保存到默認的 /etc/audit/rules.d/audit.rules 配置，也可以通過 auditctl 動態的調整。值得注意的是策略規則的加載是按照順序生效的，我們在配置例外情況的時候就需要注意將例外情況添加到合適的位置，比如參考 auditd-best-practice 中給出的示例，如果需要忽略 mysql，mongo 等命令工具，就需要將以下策略加到合適的位置（-a always，exit 規則之前）：

### ignore common tools-a never,exit -F arch=b64 -F exe=/usr/bin/redis-cli-a never,exit -F arch=b64 -F exe=/usr/bin/mysql-a never,exit -F arch=b64 -F exe=/usr/bin/mongo ....## Kernel module loading and unloading-a always,exit -F perm=x -F auid!=-1 -F path=/sbin/insmod -k modules....

never 和 always 所能支持的 -F 過濾字段不盡相同, 如果要按照 exe 忽略指定的工具路徑, 只能通過 never 實現, exe 為執行工具的路徑, 需要設置其絕對值, 這點沒有 snoopy 的 exclude_comm 方便.

更多規則設置見: audit-define

eBPF 記錄方式

eBPF 在較新版本的 Linux 內核中實現，提供了動態追蹤的機制，可以閱讀之前的文章 Linux 系統動態追蹤技術介紹了解更多動態追蹤相關的知識。bpftrace 和 bcc 是基于 eBPF 機制實現的工具，方便大家對系統的調試和排錯，bcc 提供了很多工具集，從應用到內核，不同層面的工具應有盡有，比如 execsnoop 即可記錄系統中所有的 execv，execve 相關的命令執行：

# ./execsnoop PCOMM PID PPID RET ARGSbash 32647 32302 0 /bin/bashid 32649 32648 0 /usr/bin/id -unhostname 32651 32650 0 /usr/bin/hostnameuptime 410 32744 0 /bin/uptime

其它更細致的記錄可以參考 bcc 工具說明。值得注意的是，eBPF 僅適用于 Linux 4.1+ 的版本，以 eBPF 開發的進度的來看，eBPF 在 kernel-4.10 之后的支持才相對全面，線上在使用的時候盡量選擇較高內核版本的發行版（比如 Centos 8，Debian 10 等）。另外 Readhat/Centos 7 從 7.6（3.10.0-940.el7.x86_64）版本開始支持 eBPF 特性，不過內核版本較低，并沒有支持所有的特性，其主要目的在于試用此技術：

總結

從上述介紹可以看到，審計系統的操作行為其實就是為了更方便的追溯和排查問題，審計所產生的日志記錄本身也可以作為取證的材料。一些對安全敏感的企業可以通過 auditd 方式來實現不同級別的審計標準。

在實際的使用中，我們建議通過 snoopy 或 auditd 來實現系統操作的審計需求，一些細致的記錄追蹤可以通過 eBPF 方式實現。另外也可以將審計的日志發送到 ELK 等日志平臺做一些策略方面的告警，不過在具體的實踐中，我們需要做好詳細的過濾規則避免產生大量重復且收效甚微的數據。

總結

以上是生活随笔為你收集整理的Linux 系统审计操作行为的 5 种解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。

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