HIDS基本原理
熟悉HIDS的朋友应该了解，服务器的shell监控一般有两种，一种依靠Linux的audit审计功能，比如Wazuh，一种是重编译和替换bash二进制文件，将shell上执行的命令实时通过socket传递到服务端。
前一种方法优点是记录完整，缺点是会产生大量的日志，以及audit.rules配置失误的话导致服务器宕机。
后一种方式虽然日志简洁，但如果通过命令远程执行漏洞不走服务器的shell则捕获不到操作。在此我主要介绍Wazuh所使用的audit监控。
audit的原理浅显来说，linux 用于用户空间与内核空间的中间层叫做syscall，是连接用户态和内核态的桥梁，当用户访问硬件设备，比如申请系统资源、操作设备读写、创建新进程时，用户空间发起请求，内核空间负责执行，syscall提供一套标准接口实现。
当用户空间向内核空间发出syscall时，会产生软中断，让程序由用户态进入内核态进而执行相应的操作，每个syscall都有唯一的系统调用号对应。
这样做的好处是内核空间是在受保护的地址空间中，用户空间程序无法直接执行内核代码，也无法访问内核数据。
网上举例了kill()函数的执行流程：
kill() -> kill.S -> swi陷入内核态 -> 从sys_call_table查看到sys_kill -> ret_fast_syscall -> 回到用户态执行kill()下一行代码。
参考syscall list：http://man7.org/linux/man-pages/man2/syscalls.2.html
audit框架如下：
Linux 监控框架：
除了Wazuh，开源Agent方案还有AuditBeat、OSQuery、NxLog等等，可以根据规模和平台的大小进行选择，各种入侵检测方案。
audit开启风险
规则配置建议
部署完wazuh-agent后，需要通过auditctl配置一些监控规则，auditctl官方文档中介绍，过多的规则将导致性能下降，建议合并规则，比如：
auditctl -a exit,always -S open -F success=0
auditctl -a exit,always -S truncate -F success=0
可以合并为一条规则：
auditctl -a exit,always -S open -S truncate -F success=0
此外，善用文件系统审核，比如如果只关注/etc中的文件，而不关心/usr或者/sbin，可以写作：
auditctl -a exit,always -S open -S truncate -F dir=/etc -F success=0
audit规则文件注意事项
audit规则文件默认路径为/etc/audit/audit.rules，非常需要注意的参数：
-e [0..2] 当参数为0时，暂时禁用审核；为1时，启用审核；为2时，不符合审核配置的操作将被拒绝
Set enabled flag. When 0 is passed, this can be used to temporarily disable auditing. When 1 is passed as an argument, it will enable auditing. To lock the audit configuration so that it can't be changed, pass a 2 as the argument. Locking the configuration is intended to be the last command in audit.rules for anyone wishing this feature to be active. Any attempt to change the configuration in this mode will be audited and denied. The configuration can only be changed by rebooting the machine.
-f [0..2] 当参数为0时，内核出现的严重错误会被忽略；为1时，当缓冲区耗尽或发生越界访问时会在/var/log/audit/audit.log日志中报错；为2时，到用户控件的audit守护进程传输错误、backlog超出限制、内存不足以及超出速率限制都会导致auditd使主机panic来阻止进一步的操作。
Set failure flag 0=silent 1=printk 2=panic. This option lets you determine how you want the kernel to handle critical errors. Example conditions where this flag is consulted includes: transmission errors to userspace audit daemon, backlog limit exceeded, out of kernel memory, and rate limit exceeded. The default value is 1. Secure environments will probably want to set this to 2.
-p [r|w|x|a] 文件系统监控将触发的权限访问类型，r =读取，w =写入，x =执行，a =属性更改，读和写默认是syscall中省略的，会导致产生过多日志
Describe the permission access type that a file system watch will trigger on. r=read, w=write, x=execute, a=attribute change. These permissions are not the standard file permissions, but rather the kind of syscall that would do this kind of thing. The read & write syscalls are omitted from this set since they would overwhelm the logs. But rather for reads or writes, the open flags are looked at to see what permission was requested.
已知问题如下：
1、默认audit.rules中，默认缓冲区buffer的大小为-b 320，有可能导致缓冲瓶颈，官方建议是将这个值翻倍也就是设置为640，视具体测试情况而定，当发生时日志报错为：audit: backlog limit exceeded
2、当-f 的参数设置为2时，由于错误日志超出限制，audit使主机通过重启的方式来应对，造成严重事故
在我司环境中，由于只存在Linux 64位系统，我只对execve进程执行syscall进行监控，因此只对服务器配置一条规则：
auditctl -a exit,always -F arch=b64 -S execve -k audit-wazuh-c
并且在规则配置前，会强制检查audit.conf（或者auditctl -s）检查参数的配置，当-e/enabled、-f/failure 参数为2时，则不允许auditctl规则的建立。
参考：
https://www.freebuf.com/articles/es/222976.html
https://linux.die.net/man/8/auditctl
https://linux.die.net/man/7/audit.rules
https://www.cnblogs.com/zl1991/p/6543634.html