共计 4692 个字符，预计需要花费 12 分钟才能阅读完成。
很多时候咱们为了平安审计或者故障跟踪排错，可能会记录剖析主机零碎的操作行为。比方在零碎中新增了一个用户，批改了一个文件名，或者执行了一些命令等等，实践上记录的越具体, 越有利于审计和排错的目标。不过过剩的记录也会为剖析带来不少麻烦，尤其是将很多主机的记录行为发送到固定的近程主机中，数据越多，剖析的老本便越大。
实际上，绝大多数的零碎行为都是反复多余的，比方 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 为 992
filter_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/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 整体上为拆散的架构，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 不便.
eBPF 记录形式
eBPF 在较新版本的 Linux 内核中实现，提供了动静追踪的机制，能够浏览之前的文章 Linux 零碎动静追踪技术介绍理解更多动静追踪相干的常识。bpftrace 和 bcc 是基于 eBPF 机制实现的工具，不便大家对系统的调试和排错，bcc 提供了很多工具集，从利用到内核，不同层面的工具包罗万象，比方 execsnoop 即可记录零碎中所有的 execv，execve 相干的命令执行：
# ./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 开发的进度的来看，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 等日志平台做一些策略方面的告警，不过在具体的实际中，咱们须要做好具体的过滤规定防止产生大量反复且收效甚微的数据。
起源：http://blog.arstercz.com/how-…
