很多時(shí)候我們?yōu)榱税踩珜徲?jì)或者故障跟蹤排錯，可能會記錄分析主機(jī)系統(tǒng)的操作行為。比如在系統(tǒng)中新增了一個用戶，修改了一個文件名，或者執(zhí)行了一些命令等等，理論上記錄的越詳細(xì), 越有利于審計(jì)和排錯的目的。不過過剩的記錄也會為分析帶來不少麻煩， 尤其是將很多主機(jī)的記錄行為發(fā)送到固定的遠(yuǎn)程主機(jī)中，數(shù)據(jù)越多，分析的成本便越大。

實(shí)際上，絕大多數(shù)的系統(tǒng)行為都是重復(fù)多余的，比如 cron 任務(wù)計(jì)劃，我們信任的程序等, 這些都會產(chǎn)生大量的記錄，但很少用于審計(jì)分析。基于這個需求，我們在審計(jì)系統(tǒng)操作行為的時(shí)候，至少應(yīng)該添加一些過濾規(guī)則，避免記錄過多的無用信息，比如重復(fù)的 cron 任務(wù)操作，同時(shí)也要避免記錄一些敏感信息，比如帶密碼的命令行操作。滿足這些需求后，我們在審計(jì)系統(tǒng)操作行為的時(shí)候應(yīng)該遵照以下準(zhǔn)則：

忽略 cron，daemon 產(chǎn)生的記錄；

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

忽略監(jiān)控用戶（比如 nagios，zabbix，promethus 等）產(chǎn)生的記錄；

忽略頻繁產(chǎn)生日志的操作行為；

第二點(diǎn)為可選項(xiàng)，在以明文方式傳輸?shù)竭h(yuǎn)程日志服務(wù)器的時(shí)候，我們建議忽略記錄。第四點(diǎn)則需要著重強(qiáng)調(diào)，比如我們記錄一臺 web 主機(jī)中的所有 connect，accept 網(wǎng)絡(luò)系統(tǒng)調(diào)用操作，雖然可以據(jù)此分析該主機(jī)所有的網(wǎng)絡(luò)訪問請求，達(dá)到安全或者故障定位的目的，但是這兩個系統(tǒng)調(diào)用可能在短時(shí)間內(nèi)產(chǎn)生大量的日志，對 kernel 和網(wǎng)絡(luò)日志傳輸都會產(chǎn)生不小的壓力，這種大海撈針?biāo)频膶徲?jì)方式我們不推薦直接在線上主機(jī)中使用，建議僅在需要定位問題的時(shí)候啟用。

下面我們主要介紹有哪幾種方式可以實(shí)現(xiàn)系統(tǒng)操作的審計(jì)：

• history 記錄方式

• 定制 bash 記錄方式

• snoopy 記錄方式

• auditd 記錄方式

• eBPF 記錄方式

history 記錄方式

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

容易被修改，被繞過；

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

無法記錄 shell 腳本內(nèi)的操作；

無法記錄非登錄的操作；

難以實(shí)現(xiàn)過濾規(guī)則；

定制 bash 記錄方式

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

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

無法記錄 shell 腳本內(nèi)的操作；

過濾規(guī)則可能單一；

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

snoopy 記錄方式

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

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

無論是否存在 tty 會話，都會記錄 execv，execve 相關(guān)的命令行操作，包含詳細(xì)的進(jì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對應(yīng)的進(jìn)程上下文信息都比較全，不過 snoopy 的缺點(diǎn)也比較明顯，主要包含以下幾點(diǎn)：

僅支持 execv，execve 相關(guān)系統(tǒng)調(diào)用的操作；

不設(shè)置規(guī)則可能產(chǎn)生的日志過多，對日志搜集系統(tǒng)造成很大的負(fù)擔(dān)；

暫不支持過濾敏感信息規(guī)則；

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

忽略 cron，daemon 產(chǎn)生的記錄；

忽略監(jiān)控用戶（比如 nagios，zabbix，promethus 等）?產(chǎn)生的記錄；

比如以下配置，即可忽略 crond，my-daemon 守護(hù)進(jìn)程，忽略 zabbix 用戶：

• ?

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

備注：過濾規(guī)則在（filtering.c - snoopy_filtering_check_chain）函數(shù)實(shí)現(xiàn)，由 log.c - snoopy_log_syscall_exec 函數(shù)調(diào)用，過濾規(guī)則為事后行為，即在打印日志的時(shí)候判斷是否滿足過濾規(guī)則，并非事前行為。

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

• ?

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

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

auditd 記錄方式

auditd 記錄方式 本身存在內(nèi)核層面(kauditd 進(jìn)程)的支持，它實(shí)現(xiàn)了一個大而全的框架，幾乎能監(jiān)控所有想監(jiān)控的指標(biāo)，不管是按照訪問模式，系統(tǒng)調(diào)用還是事件類型觸發(fā)，都能滿足監(jiān)控需求。因?yàn)槠涮峁┝藘?nèi)核層面的支持，所以本質(zhì)上比起 snoopy(僅封裝 execv，execve 系統(tǒng)調(diào)用)要更加強(qiáng)大和健全。

生成的日志也容易查看，進(jìn)程的上下文信息，參數(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/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 整體上為分離的架構(gòu)，auditctl 可以控制 kauditd 生成記錄的策略，kauditd 生成的記錄事件會發(fā)送到 auditd 守護(hù)程序，audisp 可以消費(fèi) auditd 的記錄到其它地方。其主要的幾個工具包含如下:

auditd 的策略規(guī)則主要根據(jù) -a 或 -w 參數(shù)設(shè)置，可以將策略規(guī)則保存到默認(rèn)的 /etc/audit/rules.d/audit.rules 配置，也可以通過 auditctl 動態(tài)的調(diào)整。值得注意的是策略規(guī)則的加載是按照順序生效的，我們在配置例外情況的時(shí)候就需要注意將例外情況添加到合適的位置，比如參考 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 實(shí)現(xiàn), exe 為執(zhí)行工具的路徑, 需要設(shè)置其絕對值, 這點(diǎn)沒有 snoopy 的 exclude_comm 方便.

更多規(guī)則設(shè)置見: audit-define

eBPF 記錄方式

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

• ?

# ./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

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

總結(jié)

從上述介紹可以看到，審計(jì)系統(tǒng)的操作行為其實(shí)就是為了更方便的追溯和排查問題，審計(jì)所產(chǎn)生的日志記錄本身也可以作為取證的材料。一些對安全敏感的企業(yè)可以通過 auditd 方式來實(shí)現(xiàn)不同級別的審計(jì)標(biāo)準(zhǔn)。

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。