很多时候我们可能会记录分析宿主系统的运行行为，以进行安全审计或故障跟踪排查。例如，系统中增加了一个新用户，修改了一个文件名，或者执行了一些命令等等，理论上记录得越详细，越有利于审计和故障排除。但是过多的记录也会给分析带来很多麻烦，尤其是如果将很多主机的记录行为发送到固定的远程主机，数据越多，分析的成本就越大。事实上，大部分系统行为都是冗余的，比如cron任务调度、我们信任的程序等，会产生大量的记录，但很少用于审计分析。基于这样的需求，我们在审计系统操作行为时，至少应该增加一些过滤规则，避免记录过多的无用信息，比如重复的cron任务操作，也避免记录一些敏感信息，比如带密码的命令行操作。满足这些要求后，我们在审计系统运行行为时应遵循以下准则：忽略cron和daemon产生的记录；忽略带密码的敏感命令行或脚本操作记录；忽略监控用户（如nagios、zabbix、promethus等）产生的记录；忽略频繁产生日志的操作；第二点是可选的，我们建议在以明文形式传输到远程日志服务器时忽略记录。第四点需要强调。比如我们在一个web主机中记录所有的connect和accept网络系统调用操作。虽然主机的所有网络访问请求都可以据此进行分析，以达到安全或故障定位的目的，但这两个系统调用可能会在短时间内产生大量的日志，造成很大的压力关于内核和网络日志传输。我们不建议直接在在线主机上使用这种大海捞针审计方法。启用时间。下面主要介绍审计系统运行的几种方式：history记录方式自定义bash记录方式snoopy记录方式auditd记录方式eBPF记录方式history记录方式history方式非常传统简单，本质上就是history的命令发送到syslog日志，可以用来简单记录用户的命令操作历史。但是，这种方法有几个重要的缺点，不适合审计目的：容易被修改和绕过；记录过于简单，没有上下文信息（如pid、uid、sid等）；它不能记录shell脚本中的操作；无法记录非登录操作；过滤规则难以实现；自定义bash记录方式自定义bash方式比较冷门，本质上是在bash源程序中增加审计日志功能，开发者可以在此基础上添加一些操作命令的上下文信息，但是很难记录子进程的信息，其缺点与上述history方法类似：容易被绕过，用户可以使用csh、zsh等；shell脚本无法记录操作；过滤规则可以是单一的；可能需要不断更新bash版本，工作量大，否则容易被release版本取代；snoopy记录方法snoopy方法比较新颖，本质上是封装了execv和execve系统调用，以系统预加载的方式记录所有的命令操作。更多介绍可以参考之前的文章snoopy如何记录系统执行的命令。目前大部分系统通过execv和execve系统调用执行命令，与会话无关。几乎在所有情况下，只要通过这两个系统调用执行命令，都会记录操作行为。从目前最新的版本（2.4.8）来看，snoopy有几个优点：难以绕过，只要设置PRELOAD就一定会记录；无论是否有ttysession，都会记录execv、execve相关的命令行操作，包括详细的Processcontext信息；可以记录shell脚本的内部运行行为，脚本中大部分的命令行操作都会调用execv、execve；可以记录操作行为的参数，如指定用户名、密码等；丰富的过滤规则，可以忽略指定的daemon、uid，也可以只记录指定的uid；以下日志示例：Oct2711:34:31cz-t1snoopy[24814]:[time_ms:778login:czuid:0pid:24814ppid:24676sid:24579tty:/dev/pts/0cwd:/rootfilename:/bin/uptimeusername:root]:uptime-p上面的日志显示root用户执行了uptime命令，包含-p的参数对应的进程上下文信息比较完整，但是snoopy的缺点是也很明显，主要包括以下几点：只支持execv和execve相关的系统调用；如果不设置规则，可能会产生过多的日志，对日志采集系统造成很大的负担；目前不支持过滤敏感信息规则；在实际使用中，snoopy记录方式可以详细记录所有命令操作信息，帮助我们定位很多疑难问题。但是，我们还需要使用过滤规则来避免产生过多的信息。Snoopy的过滤规则可以满足如下需求：忽略cron和daemon产生的记录；忽略监控用户（如nagios、zabbix、promethus等）产生的记录；例如下面的配置，可以忽略crond、my-daemon守护进程和zabbix用户：#zabbixuidis992filter_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过滤规则，我们可以忽略record指定的命令，比如如下：filter_chain=exclude_uid:992;exclude_comm:mysql,mongo,redis-cliexclude_comm指定忽略mysql，mongo和redis-cli工具执行的命令。许多管理员或脚本在使用这些工具时经常会添加用户密码信息。这在纯文本环境中是非常危险的行为。exclude_comm规则只是简单的避免了常用工具泄露敏感信息的隐患。auditd记录方式auditd记录方式本身有内核级（kauditd进程）的支持。它实现了一个庞大而全面的框架，几乎可以监控所有你想监控的指标，无论是访问方式、系统调用还是事件类型触发。可以满足监控需要。因为它提供了内核级别的支持，所以本质上比snoopy（只封装了execv和execve系统调用）更强大、更完善。生成的日志也很容易查看。进程上下文信息和参数信息比较全面，如下图：type=SYSCALLmsg=audit(1603800704.305:5304075):arch=c000003esyscall=59success=yesexit=0a0=1c79fd0a1=1bf51a0a2=1bd4450a3=7ffe7270d320items=2ppid=95264pid=99702auid=0uid=0gid=0euid=0suid=0fsuid=0egid=0sgid=0fsgid=0tty=pts0ses=571973comm="mysql"exe="/usr/bin/mysql"key="command"type=EXECVEmsg=audit(1603800704.305:5304075):argc=5a0="/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等命令工具，需要在合适的位置添加如下策略（-aalways，退出规则前）：###ignorecommontools-anever,exit-Farch=b64-Fexe=/usr/bin/redis-cli-anever,exit-Farch=b64-Fexe=/usr/bin/mysql-anever,exit-Farch=b64-Fexe=/usr/bin/mongo....##内核模块加载卸载-aalways,exit-Fperm=x-Fauid!=-1-Fpath=/sbin/insmod-kmodules....neverandalwayscan支持-F过滤字段是无限的同理，如果要根据exe忽略指定的刀具路径，只能通过never来实现。exe是执行工具的路径，需要设置绝对值，没有snoopy的exclude_comm方便。更多规则设置参见：audit-defineeBPF记录方式eBPF是在较新版本的Linux内核中实现的，提供动态跟踪机制。可以阅读上一篇文章Linux系统动态跟踪技术介绍，了解更多关于动态跟踪的知识。bpftrace和bcc是基于eBPF机制实现的工具，方便大家调试和排查系统。bcc提供了很多工具集，从应用程序到内核，以及不同层次的工具。例如execsnoop可以记录系统中所有的execv。execve相关命令执行：#./execsnoopPCOMMPIDPPIDRETARGSbash32647323020/bin/bashid32649326480/usr/bin/id-unhostname32651326500/usr/bin/hostnameuptime410327440/bin/uptimeothers更详细的记录请参考密件抄送工具说明。值得注意的是，eBPF仅适用于Linux4.1+版本。从eBPF的开发进度来看，kernel-4.10之后eBPF比较全面。在线使用时，尽量选择内核版本版本较高的发行版（如Centos8、Debian10等）。另外，Readhat/Centos7从7.6版本（3.10.0-940.el7.x86_64）开始支持eBPF特性，但内核版本比较低，并不支持所有特性。主要目的是尝试这个技术：总结从上面的介绍可以看出，审计系统的运行行为其实是为了更方便的跟踪和排查问题，审计本身产生的日志记录也可以作为取证材料。一些对安全敏感的企业可以使用auditd来达到不同级别的审计标准。在实际使用中，我们推荐使用snoopy或者auditd来实现系统运行的审计需求，一些详细的记录跟踪可以通过eBPF来实现。另外，审计日志也可以发送到ELK等日志平台进行策略预警。但是在实践中，我们需要制定详细的过滤规则，避免产生大量重复但效果不大的数据。以上就是良虚教程网为各位小伙伴分享的审计Linux系统运行行为的五种方案对比。以上就是良序教程网为各位小伙伴们分享的Linux相关知识。
