審計 Linux 系統(tǒng)的操作行為的 5 種方案對比
很多時候我們?yōu)榱税踩珜徲嫽蛘吖收细櫯佩e，可能會記錄分析主機系統(tǒng)的操作行為。比如在系統(tǒng)中新增了一個用戶，修改了一個文件名，或者執(zhí)行了一些命令等等，理論上記錄的越詳細, 越有利于審計和排錯的目的。不過過剩的記錄也會為分析帶來不少麻煩， 尤其是將很多主機的記錄行為發(fā)送到固定的遠程主機中，數(shù)據(jù)越多，分析的成本便越大。
實際上，絕大多數(shù)的系統(tǒng)行為都是重復多余的，比如 cron 任務計劃，我們信任的程序等, 這些都會產(chǎn)生大量的記錄，但很少用于審計分析?；谶@個需求，我們在審計系統(tǒng)操作行為的時候，至少應該添加一些過濾規(guī)則，避免記錄過多的無用信息，比如重復的 cron 任務操作，同時也要避免記錄一些敏感信息，比如帶密碼的命令行操作。滿足這些需求后，我們在審計系統(tǒng)操作行為的時候應該遵照以下準則：
- 忽略 cron，daemon 產(chǎn)生的記錄；
- 忽略帶密碼的敏感命令行或腳本操作記錄；
- 忽略監(jiān)控用戶（比如 nagios，zabbix，promethus 等）產(chǎn)生的記錄；
- 忽略頻繁產(chǎn)生日志的操作行為；
第二點為可選項，在以明文方式傳輸?shù)竭h程日志服務器的時候，我們建議忽略記錄。第四點則需要著重強調(diào)，比如我們記錄一臺 web 主機中的所有 connect，accept 網(wǎng)絡系統(tǒng)調(diào)用操作，雖然可以據(jù)此分析該主機所有的網(wǎng)絡訪問請求，達到安全或者故障定位的目的，但是這兩個系統(tǒng)調(diào)用可能在短時間內(nèi)產(chǎn)生大量的日志，對 kernel 和網(wǎng)絡日志傳輸都會產(chǎn)生不小的壓力，這種大海撈針似的審計方式我們不推薦直接在線上主機中使用，建議僅在需要定位問題的時候啟用。
下面我們主要介紹有哪幾種方式可以實現(xiàn)系統(tǒng)操作的審計：
- history 記錄方式
- 定制 bash 記錄方式
- snoopy 記錄方式
- auditd 記錄方式
- eBPF 記錄方式
history 記錄方式
history 方式 很傳統(tǒng)也很簡單，本質(zhì)上是將歷史的命令發(fā)送到 syslog 日志中，可以用來簡單記錄用戶的命令操作歷史。但是這種方式有幾個重要的缺點，并不適合審計的目的：
- 容易被修改，被繞過；
- 記錄太簡單，沒有上下文信息(比如 pid, uid, sid 等)；
- 無法記錄 shell 腳本內(nèi)的操作；
- 無法記錄非登錄的操作；
- 難以實現(xiàn)過濾規(guī)則；
定制 bash 記錄方式
定制 bash 方式 比較冷門，本質(zhì)上是為 bash 源程序增加審計日志的功能，開發(fā)者可以據(jù)此添加一些操作命令的上下文信息，不過很難記錄子進程的信息，其缺點和上述的 history 方式類似:
- 容易被繞過，用戶可以使用 csh，zsh 等；
- 無法記錄 shell 腳本內(nèi)的操作；
- 過濾規(guī)則可能單一；
- 可能需要不停的更新 bash 版本，工作量大，否則容易被發(fā)行版替換 ；
snoopy 記錄方式
snoopy 方式相對新穎，本質(zhì)上是封裝了 execv，execve 系統(tǒng)調(diào)用，以系統(tǒng)預加載（preload）的方式實現(xiàn)記錄所有的命令操作。更多介紹可以參考以前的文章 snoopy 如何記錄系統(tǒng)執(zhí)行過的命令。目前大部分系統(tǒng)執(zhí)行命令時都通過 execv，execve 系統(tǒng)調(diào)用執(zhí)行，這點就和會話無關(guān)，幾乎所有的情況下，只要通過這兩個系統(tǒng)調(diào)用執(zhí)行命令，就會將操作行為記錄下來，從目前的最新版本（2.4.8）來看，snoopy 有幾個優(yōu)點：
- 難以繞過，只要設置了 PRELOAD，就肯定會記錄；
- 無論是否存在 tty 會話，都會記錄 execv，execve 相關(guān)的命令行操作，包含詳細的進程上下文信息；
- 可以記錄 shell 腳本內(nèi)部的操作行為，腳本內(nèi)的命令行操作大部分都會調(diào)用 execv，execve；
- 可以記錄操作行為的參數(shù)， 比如指定了用戶名，密碼等；
- 過濾規(guī)則豐富，可以忽略指定 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 用戶執(zhí)行了 uptime 命令，參數(shù)包含 -p 對應的進程上下文信息都比較全，不過 snoopy 的缺點也比較明顯，主要包含以下幾點：
- 僅支持 execv，execve 相關(guān)系統(tǒng)調(diào)用的操作；
- 不設置規(guī)則可能產(chǎn)生的日志過多，對日志搜集系統(tǒng)造成很大的負擔；
- 暫不支持過濾敏感信息規(guī)則；
在實際的使用中，snoopy 記錄方式可以很詳細的記錄所有的命令操作信息，幫助我們定位很多疑難問題。不過我們也需要通過過濾規(guī)則來避免產(chǎn)生過多的信息，snoopy 的過濾規(guī)則可以滿足以下需求：
- 忽略 cron，daemon 產(chǎn)生的記錄；
- 忽略監(jiān)控用戶（比如 nagios，zabbix，promethus 等） 產(chǎn)生的記錄；
比如以下配置，即可忽略 crond，my-daemon 守護進程，忽略 zabbix 用戶：
- # zabbix uid 為 992
- filter_chain = exclude_uid:992;exclude_spawns_of:crond,my-daemon
備注：過濾規(guī)則在（filtering.c - snoopy_filtering_check_chain）函數(shù)實現(xiàn)，由 log.c - snoopy_log_syscall_exec 函數(shù)調(diào)用，過濾規(guī)則為事后行為，即在打印日志的時候判斷是否滿足過濾規(guī)則，并非事前行為。
另外，我們在 snoopy 的基礎(chǔ)上增加了 exclude_comm 過濾規(guī)則，我們可以忽略記錄指定的命令，比如以下：
- filter_chain = exclude_uid:992;exclude_comm:mysql,mongo,redis-cli
exclude_comm 指定忽略以 mysql，mongo 和 redis-cli 工具執(zhí)行的命令，很多管理員或者腳本在使用這些工具的時候常常會加上用戶密碼信息，這在明文環(huán)境中是很危險的行為，exclude_comm 規(guī)則簡單的避免了常用工具泄漏敏感信息的隱患。
auditd 記錄方式
auditd 記錄方式 本身存在內(nèi)核層面(kauditd 進程)的支持，它實現(xiàn)了一個大而全的框架，幾乎能監(jiān)控所有想監(jiān)控的指標，不管是按照訪問模式，系統(tǒng)調(diào)用還是事件類型觸發(fā)，都能滿足監(jiān)控需求。因為其提供了內(nèi)核層面的支持，所以本質(zhì)上比起 snoopy(僅封裝 execv，execve 系統(tǒng)調(diào)用)要更加強大和健全。
生成的日志也容易查看，進程的上下文信息，參數(shù)信息都很全面，如下所示：
- 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/mysq
- l" 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 整體上為分離的架構(gòu)，auditctl 可以控制 kauditd 生成記錄的策略，kauditd 生成的記錄事件會發(fā)送到 auditd 守護程序，audisp 可以消費 auditd 的記錄到其它地方。其主要的幾個工具包含如下:
auditd 的策略規(guī)則主要根據(jù) -a 或 -w 參數(shù)設置，可以將策略規(guī)則保存到默認的 /etc/audit/rules.d/audit.rules 配置，也可以通過 auditctl 動態(tài)的調(diào)整。值得注意的是策略規(guī)則的加載是按照順序生效的，我們在配置例外情況的時候就需要注意將例外情況添加到合適的位置，比如參考 auditd-best-practice 中給出的示例，如果需要忽略 mysql，mongo 等命令工具，就需要將以下策略加到合適的位置（-a always，exit 規(guī)則之前）：
- ### 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 實現(xiàn), exe 為執(zhí)行工具的路徑, 需要設置其絕對值, 這點沒有 snoopy 的 exclude_comm 方便.
更多規(guī)則設置見: audit-define
eBPF 記錄方式
eBPF 在較新版本的 Linux 內(nèi)核中實現(xiàn)，提供了動態(tài)追蹤的機制，可以閱讀之前的文章 Linux 系統(tǒng)動態(tài)追蹤技術(shù)介紹了解更多動態(tài)追蹤相關(guān)的知識。bpftrace 和 bcc 是基于 eBPF 機制實現(xiàn)的工具，方便大家對系統(tǒng)的調(diào)試和排錯，bcc 提供了很多工具集，從應用到內(nèi)核，不同層面的工具應有盡有，比如 execsnoop 即可記錄系統(tǒng)中所有的 execv，execve 相關(guān)的命令執(zhí)行：
- # ./execsnoop
- PCOMM PID PPID RET ARGS
- bash 32647 32302 0 /bin/bash
- id 32649 32648 0 /usr/bin/id -un
- hostname 32651 32650 0 /usr/bin/hostname
- uptime 410 32744 0 /bin/uptime
其它更細致的記錄可以參考 bcc 工具說明。值得注意的是，eBPF 僅適用于 Linux 4.1+ 的版本，以 eBPF 開發(fā)的進度的來看，eBPF 在 kernel-4.10 之后的支持才相對全面，線上在使用的時候盡量選擇較高內(nèi)核版本的發(fā)行版（比如 Centos 8，Debian 10 等）。另外 Readhat/Centos 7 從 7.6（3.10.0-940.el7.x86_64）版本開始支持 eBPF 特性，不過內(nèi)核版本較低，并沒有支持所有的特性，其主要目的在于試用此技術(shù)：
總結(jié)
從上述介紹可以看到，審計系統(tǒng)的操作行為其實就是為了更方便的追溯和排查問題，審計所產(chǎn)生的日志記錄本身也可以作為取證的材料。一些對安全敏感的企業(yè)可以通過 auditd 方式來實現(xiàn)不同級別的審計標準。
在實際的使用中，我們建議通過 snoopy 或 auditd 來實現(xiàn)系統(tǒng)操作的審計需求，一些細致的記錄追蹤可以通過 eBPF 方式實現(xiàn)。另外也可以將審計的日志發(fā)送到 ELK 等日志平臺做一些策略方面的告警，不過在具體的實踐中，我們需要做好詳細的過濾規(guī)則避免產(chǎn)生大量重復且收效甚微的數(shù)據(jù)。
