目录
一、什么是wazuh
二、wazuh的安装
1.仓库安装
2.虚拟机OVA安装
3.其他安装方式
三、浅析wazuh的规则、解码器等告警原理以及主动响应
1.主动响应(active-response)
2.告警信息(alerts)
3.规则以及解码器(rules and decoders)
3.1.规则
3.2.解码器
4.linux后门rootkit检测与基线检查(back door)
5.配置文件ossec.conf
四、添加代理
五、用户自定义规则
六、示例SQL注入检测
七、总结
Wazuh 是一个免费的开源安全平台,统一了 XDR 和 SIEM 功能。它可以保护本地、虚拟化、容器化和基于云的环境中的工作负载。
Wazuh 帮助组织和个人保护其数据资产免受安全威胁。它被全球数千个组织广泛使用,从小型企业到大型企业。
Wazuh的使用场景有:
此外,Wazuh 已经与 Elastic Stack 完全集成,提供了一个搜索引擎和数据可视化工具,允许用户通过他们的安全警报进行导航。
添加wazuh的官方仓库来安装wazuh的安装包
具体流程可以跟着wazuh的官方文档来一步步走
Wazuh documentation
在官方上下载OVA文件,可能比较大,几个g左右
下载完成后,可以在Vmware中直接导入虚拟机
右上角--->文件--->打开--->选择下载好的OVA文件
之后选择安装路径,跟着引导程序一步步走
可以选择镜像下载、部署在docker、k8s上、使用ES安装、使用ansible安装等等
可以根据官方文档自行选择,具体步骤跟着官方来就可以了
主动响应的主要作用是检测到危险或者是告警之后,在一定条件下(比如告警等级大于7或者触发了某条或多条规则),可以做出一系列反应来禁止入侵者访问或登录你的系统
主动响应的脚本在/var/ossec/active-response/bin目录下
这里面有许多脚本,比如
等等
当入侵者或正常用户执行了某些命令、做了某些操作,触发了wazuh的规则,那么wazuh就会在日志中记录并告警
这个日志的目录是在/var/ossec/logs/alerts目录下
分为有日期的告警日志和总告警日志
以.json结尾的文件是json格式的日志,主要用于ELK分析展示
以.log结尾的文件是我们查看起来比较方便的格式
我们来仔细看一条告警信息
这条告警信息触发了规则ID5715,告警等级3,显示ssh认证成功
源IP地址:192.168.239.1
源端口:49688
用户:root
而告警信息同样也会在wazuh的可视化界面中展示出来,而且在界面中告警信息更加清晰
浏览器URL中输入https://
用户名和密码默认为admin:admin
进入后转到如下界面,这里就是wazuh的告警信息
展开其中一条仍然可以看到我们刚刚在alerts.log日志中的信息,而且比日志看起来更方便
官方文档说告警等级可以从1-13,默认值为3
wazuh的规则在/var/ossec/ruleset/rules目录下
而用户的自定义规则是在/var/ossec/etc/rules目录下
为什么不把用户自定义的规则放在wazuh的规则目录下,而是放在单独的自定义规则目录下呢?
这是因为wazuh的规则是在实时更新的,如果用户自定义的规则放在wazuh的规则目录下,有可能在更新的时候删除掉用户自定义的规则
说完目录后,我们来看一条具体规则的内容是什么
规则ID:5715
父分类规则ID:5700
匹配方法正则: /^Accepted|authenticated.$/
描述信息:sshd: authentication success.
剩下的mitre和id等不太了解,可以查找官方文档
Wazuh documentation
5715规则使用正则匹配的ssh日志信息,以Accept开头或者以authenticated结尾,这就匹配上了
wazuh的核心配置文件在/var/ossec/etc/ossec.conf中
为什么那些规则可以匹配我们日志中的信息?
就是因为在配置文件中写入了日志的目录,便于wazuh查找和分析日志
那从日志匹配到wazuh的可视化界面的告警信息,这其中到底发生了什么?
这就不得不提到解码器的作用了
下面这是依据我的理解画的一张原理图
可以看到解码器在其中有很重要的地位
Wazuh中的解码器就是从特定类型的事件中提取相关数据。解码分为预解码阶段和解码阶段。
一旦日志事件被解码,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字段的
https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html?highlight=frequency
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开头
这样一来整个规则链就梳理通了
后门检测和基线检查的脚本在/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真的很强大
wazuh的配置文件路径在/var/ossec/etc/ossec.conf
配置文件详情最好查阅官方文档
Wazuh documentation
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注入,看wazuh如何检测和响应
首先要把Nginx的日志路径加载到client端的配置文件里面去,wazuh默认加载好了的
如果路径不同,修改即可
然后我们随便写一些注入语句
那既然已经出现了告警,我们怎么去防御呢,wazuh有它自身的Active-response
如何配置,官方文档也给出了步骤
How to configure active response - Active response
wazuh有两种封堵方式:
所以这两种方式要根据项目中的实际情况来判断
这里我们使用规则ID封堵IP方式来演示
官方文档:
File integrity monitoring and YARA - Malware detection
在wazuh服务器,也就是manager的配置文件里写入如下内容
当触发31103和31171这两条规则时,执行firewall-drop命令,600秒后恢复
firewall-drop
local
31103,31171
600
之后随便测试一些注入语句,然后再刷新,发现已经被防火墙拦截了
总之呢,wazuh这个HIDS监控系统,功能确实很强大,有可视化的告警信息和主动响应,定制性也很强,用户可以自定义规则,让你以后在HW的过程中大大减少你的工作量
当然还有其他的安全监控系统,比喻说洋葱(SecurityOnion)
还有NIDS,主要是监控网络流量,比如说Suricata
这些都是很好用的工具,多了解总是没有坏处的