目录
4.linux后门rootkit检测与基线检查(back door)
一、什么是wazuh
Wazuh 是一个免费的开源安全平台，统一了 XDR 和 SIEM 功能。它可以保护本地、虚拟化、容器化和基于云的环境中的工作负载。
Wazuh 帮助组织和个人保护其数据资产免受安全威胁。它被全球数千个组织广泛使用，从小型企业到大型企业。
Wazuh的使用场景有：
- 入侵检测
- 日志数据分析
- 完整性检查
- 漏洞检测
- 配置评估
- 应急响应
- 云、容器安全等
此外，Wazuh 已经与 Elastic Stack 完全集成，提供了一个搜索引擎和数据可视化工具，允许用户通过他们的安全警报进行导航。
二、wazuh的安装
1.仓库安装
添加wazuh的官方仓库来安装wazuh的安装包
具体流程可以跟着wazuh的官方文档来一步步走
2.虚拟机OVA安装
在官方上下载OVA文件，可能比较大，几个g左右
下载完成后，可以在Vmware中直接导入虚拟机
右上角--->文件--->打开--->选择下载好的OVA文件
之后选择安装路径，跟着引导程序一步步走
3.其他安装方式
可以选择镜像下载、部署在docker、k8s上、使用ES安装、使用ansible安装等等
可以根据官方文档自行选择，具体步骤跟着官方来就可以了
三、浅析wazuh的规则、解码器等告警原理以及主动响应
1.主动响应(active-response)
主动响应的主要作用是检测到危险或者是告警之后，在一定条件下(比如告警等级大于7或者触发了某条或多条规则)，可以做出一系列反应来禁止入侵者访问或登录你的系统
主动响应的脚本在/var/ossec/active-response/bin目录下
这里面有许多脚本，比如
- disable-account 禁止账户登录
- firewalld-drop 防火墙拦截
- host-deny 禁止ip访问
- restart-wazuh 重启wazuh服务
等等
2.告警信息(alerts)
当入侵者或正常用户执行了某些命令、做了某些操作，触发了wazuh的规则，那么wazuh就会在日志中记录并告警
这个日志的目录是在/var/ossec/logs/alerts目录下
分为有日期的告警日志和总告警日志
以.json结尾的文件是json格式的日志，主要用于ELK分析展示
以.log结尾的文件是我们查看起来比较方便的格式
我们来仔细看一条告警信息
这条告警信息触发了规则ID5715，告警等级3，显示ssh认证成功
源IP地址：192.168.239.1
源端口：49688
用户：root
而告警信息同样也会在wazuh的可视化界面中展示出来，而且在界面中告警信息更加清晰
浏览器URL中输入https://<ip address>
用户名和密码默认为admin:admin
进入后转到如下界面，这里就是wazuh的告警信息
展开其中一条仍然可以看到我们刚刚在alerts.log日志中的信息，而且比日志看起来更方便
官方文档说告警等级可以从1-13，默认值为3
3.规则以及解码器(rules and decoders)
3.1.规则
wazuh的规则在/var/ossec/ruleset/rules目录下
而用户的自定义规则是在/var/ossec/etc/rules目录下
为什么不把用户自定义的规则放在wazuh的规则目录下，而是放在单独的自定义规则目录下呢？
这是因为wazuh的规则是在实时更新的，如果用户自定义的规则放在wazuh的规则目录下，有可能在更新的时候删除掉用户自定义的规则
说完目录后，我们来看一条具体规则的内容是什么
规则ID：5715
父分类规则ID：5700
匹配方法正则： /^Accepted|authenticated.$/
描述信息：sshd: authentication success.
剩下的mitre和id等不太了解，可以查找官方文档
5715规则使用正则匹配的ssh日志信息，以Accept开头或者以authenticated结尾，这就匹配上了
wazuh的核心配置文件在/var/ossec/etc/ossec.conf中
为什么那些规则可以匹配我们日志中的信息？
就是因为在配置文件中写入了日志的目录，便于wazuh查找和分析日志
3.2.解码器
那从日志匹配到wazuh的可视化界面的告警信息，这其中到底发生了什么？
这就不得不提到解码器的作用了
下面这是依据我的理解画的一张原理图
可以看到解码器在其中有很重要的地位
Wazuh中的解码器就是从特定类型的事件中提取相关数据。解码分为预解码阶段和解码阶段。
- 预解码阶段：从已知字段(如syslog记录头中的字段)提取静态信息。这通常包括时间戳、主机名和程序名，这些值通常在所有syslog消息中都能找到，而不管哪个应用程序生成它们。
- 解码阶段：将从事件中提取更多的动态信息，如源IP地址、用户名、URL等等。一个或多个解码器专门用于从许多不同的应用程序和日志源中提取字段数据。
一旦日志事件被解码，Wazuh就可以根据其规则集对其进行评估，以确定是否应该生成警报。如果日志没有解码，Wazuh规则将被限制在寻找出现在日志事件中任何地方的通用子字符串，从而大大降低了生成告警的质量。
上面这段解释来源我看到的一篇文章，我认为写得很好
Wazuh解码与规则匹配 - FreeBuf网络安全行业门户
简单来说，解码器能够从日志中提取一些关键信息，比如时间，主机ip，用户名，端口号等等
然后发送给规则，规则再进行匹配，生成告警，最后发送到可视化界面
解码器在/var/ossec/ruleset/decoders目录下
下面来分析一下解码器，比如说就下面这些解码器
首先第一个解码器的名字是sshd，匹配以sshd开头的内容
第二个解码器的名字是sshd-success，父解码器是sshd
匹配的是以Accepted开头的内容
然后匹配Accepted之后的内容，for、form、port关键字之前或之后的内容
提取出user、srcip、srcport三个字段
再与ssh日志比对看看
for后面接的是root，也就是user字段
from后面接的是登录IP，是srcip字段
port后面接的是登录IP的端口号，srcport字段
了解完了大致原理后，我们来测试一下
使用ssh故意登录失败多次，看wazuh的告警信息会有什么变化
这里用kali尝试ssh暴力破解
完成后看看wazuh的告警信息
可以看到触发了很多规则，告警等级最高的是第三条，尝试暴力破解来进入系统
那我们来分析一下解码器和规则是怎么触发的，这次我们就用可视化界面查看规则和解码器
首先查看解码器PAM(告警信息里有decodername字段)
两个父解码器名称"pam"，匹配以pam_unix结尾，以pam_unix开头
因为咱们的ssh日志里没有by字段，不是第一种的日志格式，所以直接跳过看下面几条
解码器名称"pam-fields"，父解码器名称"pam"
匹配logname=、uid=、euid=三个字段后的内容
后面还有其他信息，依次解码出来后发送给规则匹配
再来看规则
父规则5500，匹配authentication failure; logname=
告警信息PAM: User login failed.
再来看解码器sshd(仔细找与自己sshd日志信息匹配的解码器)
对比着日志信息看
父解码器sshd，匹配以Failed开头的内容
然后匹配for、from、port三个字段的信息
提取出user、srcip、srcport三个字段的信息
再来看规则
官方文档是这样描述frequency、timeframe和ignore字段的
frequency：触发前规则必须匹配的次数
timeframe：以秒为时间单位的时间范围，旨在和frequency一起使用
ignore：触发此规则后忽略该规则的时间（以秒为单位）（以避免洪水）
我的理解：规则id：5763，告警等级10，在120秒内如果触发8次5760规则，那就触发5763规则
告警信息：sshd: brute force trying to get access to the system. Authentication failed.
那我们来看5760规则
它的父规则5700和5716
匹配Failed password或者Failed keyboard或者authentication error
告警信息：sshd: authentication failed.
再看5700和5716
5700规则是一个父规则，解码器sshd
5716规则以5700规则为父规则
匹配以Failed开头或者以error: PAM: Authentication开头
这样一来整个规则链就梳理通了
4.linux后门rootkit检测与基线检查(back door)
后门检测和基线检查的脚本在/var/ossec/etc/rootcheck目录下
可以看到有很多基线检查，比如
debian_linux操作系统的基线检查、MySQL的基线检查
rhel_linux操作系统的基线检查、Windows2012R2操作系统的基线检查等等
图中红框部分就是后门检测的脚本
先来看检测rookit后门的脚本
可以看到wazuh检测了很多后门或者蠕虫可能存在的文件位置，基本上涵盖了百分之90的后门
这里我们可以测试一下，就在文件目录下写一个名为mcliZokhb的文件
新建后打开wazuh是检测不到的，因为配置文件ossec.conf规定12个小时检查一次，可以去修改轮循时间
这里我们就直接重启wazuh服务
systemctl restart wazuh-manager.service重启后打开，可以看到wazuh成功识别了这个后门文件，告警等级7
再看检测木马的脚本
可以看到wazuh检测了linux基础命令被恶意代码替换，hosts文件被恶意软件劫持等等
可以说wazuh真的很强大
5.配置文件ossec.conf
wazuh的配置文件路径在/var/ossec/etc/ossec.conf
配置文件详情最好查阅官方文档
json_output：是否以json格式输出
alerts_log：是否输出告警日志
email_notification：是否邮箱认证
忽略检查的文件目录
集群配置，这里绑定的是自身的服务器
这里的localfile记录的是日志的路径
具体内容还是应该去官方文档查找更为精确
四、添加代理
目前我们只是安装了wazuh的服务端，没有任何客户端连接，这是没有任何意义的
我们需要让其他服务器成为wazuh的客户端，也就是添加代理，端口号为1514
这里我们添加一台Ubuntu系统的服务器
没啥可说的，选择操作系统
注意这里填的是wazuh-server的IP地址，而非client
然后复制它提供给你的命令到client去执行
执行成功后你就可以在wazuh这里看到代理成功了
如果出现问题，首先确保client和server之间能互相通信
通信没问题就去查看wazuh服务器的日志，在/var/ossec/logs/ossec.log
根据报错信息去解决问题，也可以根据官方文档来排除问题
在连接上代理之后，wazuh会自动对client服务器进行基线检查
在真实项目中可以根据wazuh的基线检查来检查服务器的安全性并做相应修改
五、用户自定义规则
除了wazuh自带的规则，我们还可以自定义一些规则，来告警某单方面的漏洞
官方文档提供了这方面的需求
Detecting common Linux persistence techniques with Wazuh
这里我们就来写入动态链接库劫持的规则
具体的步骤和代码跟着官方走就行
记得安装auditd监控工具，它可以监控文件的完整性并记录日志
添加完规则后，我们可以尝试往/etc/ld.so.preload文件下随便写入一个动态链接库
查看一下/var/log/audit/audit.log的日志信息
可以看到audit.log的日志信息已经记录了可能发生了动态链接库劫持攻击
再来查看wazuh的告警信息，成功告警，告警等级10，规则ID100125
这样，这个规则就成功添加了并且也成功触发了
六、示例SQL注入检测
这里我们以SQL注入为例，在我们的代理服务器上进行SQL注入，看wazuh如何检测和响应
首先要把Nginx的日志路径加载到client端的配置文件里面去，wazuh默认加载好了的
如果路径不同，修改即可
然后我们随便写一些注入语句
来看wazuh的告警
已经出现了告警，显示尝试SQL注入
那既然已经出现了告警，我们怎么去防御呢，wazuh有它自身的Active-response
如何配置，官方文档也给出了步骤
How to configure active response - Active response
wazuh有两种封堵方式：
- 根据告警等级来封堵，比如说当告警等级大于7时，自动进行封堵，但这也容易造成误判，范围太大
- 根据规则ID来封堵，当触发了某条规则时，自动进行封堵，但这范围太小，面对多条规则不便于写配置文件
所以这两种方式要根据项目中的实际情况来判断
这里我们使用规则ID封堵IP方式来演示
官方文档：
File integrity monitoring and YARA - Malware detection
在wazuh服务器，也就是manager的配置文件里写入如下内容
当触发31103和31171这两条规则时，执行firewall-drop命令,600秒后恢复
<active-response>
<command>firewall-drop</command>
<location>local</location>
<rules_id>31103,31171</rules_id>
<timeout>600</timeout>
</active-response>之后随便测试一些注入语句，然后再刷新，发现已经被防火墙拦截了
查看iptables，发现已经被封堵了，恢复时间600秒
七、总结
总之呢，wazuh这个HIDS监控系统，功能确实很强大，有可视化的告警信息和主动响应，定制性也很强，用户可以自定义规则，让你以后在HW的过程中大大减少你的工作量
当然还有其他的安全监控系统，比喻说洋葱(SecurityOnion)
还有NIDS，主要是监控网络流量，比如说Suricata
这些都是很好用的工具，多了解总是没有坏处的