審計 Linux 系統(tǒng)的操作行為的 5 種方案對比

很多時候我們?yōu)榱税踩珜徲嫽蛘吖收细櫯佩e,可能會記錄分析主機(jī)系統(tǒng)的操作行為。比如在系統(tǒng)中新增了一個用戶,修改了一個文件名,或者執(zhí)行了一些命令等等,理論上記錄的越詳細(xì), 越有利于審計和排錯的目的。不過過剩的記錄也會為分析帶來不少麻煩, 尤其是將很多主機(jī)的記錄行為發(fā)送到固定的遠(yuǎn)程主機(jī)中,數(shù)據(jù)越多,分析的成本便越大。
忽略 cron,daemon 產(chǎn)生的記錄;
忽略帶密碼的敏感命令行或腳本操作記錄;
忽略監(jiān)控用戶(比如 nagios,zabbix,promethus 等)產(chǎn)生的記錄;
忽略頻繁產(chǎn)生日志的操作行為;
history 記錄方式 定制 bash 記錄方式 snoopy 記錄方式 auditd 記錄方式 eBPF 記錄方式
history 記錄方式
history 方式 很傳統(tǒng)也很簡單,本質(zhì)上是將歷史的命令發(fā)送到 syslog 日志中,可以用來簡單記錄用戶的命令操作歷史。但是這種方式有幾個重要的缺點,并不適合審計的目的:
容易被修改,被繞過; 記錄太簡單,沒有上下文信息(比如 pid, uid, sid 等); 無法記錄 shell 腳本內(nèi)的操作; 無法記錄非登錄的操作; 難以實現(xiàn)過濾規(guī)則;
定制 bash 記錄方式
容易被繞過,用戶可以使用 csh,zsh 等; 無法記錄 shell 腳本內(nèi)的操作; 過濾規(guī)則可能單一; 可能需要不停的更新 bash 版本,工作量大,否則容易被發(fā)行版替換;
snoopy 記錄方式
難以繞過,只要設(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 的缺點也比較明顯,主要包含以下幾點:
僅支持 execv,execve 相關(guān)系統(tǒng)調(diào)用的操作; 不設(shè)置規(guī)則可能產(chǎn)生的日志過多,對日志搜集系統(tǒng)造成很大的負(fù)擔(dān); 暫不支持過濾敏感信息規(guī)則;
在實際的使用中,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ù)實現(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
auditd 記錄方式
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 可以消費 auditd 的記錄到其它地方。其主要的幾個工具包含如下:
### 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í)行工具的路徑, 需要設(shè)置其絕對值, 這點沒有 snoopy 的 exclude_comm 方便.
更多規(guī)則設(shè)置見: audit-define
eBPF 記錄方式
# ./execsnoopPCOMM 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
總結(jié)
從上述介紹可以看到,審計系統(tǒng)的操作行為其實就是為了更方便的追溯和排查問題,審計所產(chǎn)生的日志記錄本身也可以作為取證的材料。一些對安全敏感的企業(yè)可以通過 auditd 方式來實現(xiàn)不同級別的審計標(biāo)準(zhǔn)。
在實際的使用中,我們建議通過 snoopy 或 auditd 來實現(xiàn)系統(tǒng)操作的審計需求,一些細(xì)致的記錄追蹤可以通過 eBPF 方式實現(xiàn)。另外也可以將審計的日志發(fā)送到 ELK 等日志平臺做一些策略方面的告警,不過在具體的實踐中,我們需要做好詳細(xì)的過濾規(guī)則避免產(chǎn)生大量重復(fù)且收效甚微的數(shù)據(jù)。
來源:http://blog.arstercz.com/how-to-audit-linux-system-operation/
