什么是wazuh

Wazuh是一个免费、开源和企业级的安全监控解决方案，用于威胁检测、完整性监控、事件响应和合规、也就是一套开源的完善的edr。
Wazuh是一个安全检测、可视化和安全合规开源项目。它最初是OSSEC HIDS的一个分支，后来与Elastic Stack和OpenSCAP集成在一起，发展成为一个更全面的解决方案。

Wazuh的功能有：
入侵检测
日志数据分析
完整性检查
漏洞检测
配置评估
应急响应
云、容器安全等。

如何搭建wazuh

1.首先你需要下载VMware软件
2.在github上找到在不同系统的虚拟机下的安装方法（寻找一个适合你自己的系统方式）
3.在github开源网站上下载一个OVA镜像
官方文档：
https://documentation.wazuh.com/current/index.html

实验环境

wazuh的规则

wazuh的规则，在我们wazuh-server的/var/ossec/rulerset/rules这个路径下

可以清楚的看到有这么多跳规则。
而用户的自定义规则是在/var/ossec/etc/rules目录下。
为什么不把用户自定义的规则放在wazuh的规则目录下，而是放在单独的自定义规则目录下呢？

这是因为wazuh的规则是在实时更新的，如果用户自定义的规则放在wazuh的规则目录下，有可能在更新的时候删除掉用户自定义的规则。

这是其中一条规则。
ruleid是65260，风险等级为0级。解码器为f5-bigip，description则为它的描述。
其他规则就自行查找，查找自己想要了解的规则。
解码器
说到规则，我们就要了解到解码器，它是十分重要的，以上图片我们已经了解到了解码器是什么东西。

Wazuh中的解码器就是从特定类型的事件中提取相关数据。解码分为预解码阶段和解码阶段。

预解码阶段：从已知字段(如syslog记录头中的字段)提取静态信息。这通常包括时间戳、主机名和程序名，这些值通常在所有syslog消息中都能找到，而不管哪个应用程序生成它们。
解码阶段：将从事件中提取更多的动态信息，如源IP地址、用户名、URL等等。一个或多个解码器专门用于从许多不同的应用程序和日志源中提取字段数据。

我自己的一个理解的它的工作过程：在规则触发后，我们可以看到wazuh给我们报警的实时信息而产生的日志。而解码器呢，通过这个产生的日志，根据解码器自身所编写的规则，将这个日志进行匹配，匹配一些解码器自己想要的字段，然后在将这些字段放到解码器所对应的规则上，在这个规则的一些正则表达式的匹配或者过滤下，进行产生动作，进行拦截或者进行报警。

简单来说，解码器能够从日志中提取一些关键信息，比如时间，主机ip，用户名，端口号等等

然后发送给规则，规则再进行匹配，生成告警，最后发送到可视化界面。

解码器在/var/ossec/ruleset/decoders目录下

配置代理

我这里是直接下载的一个OVA镜像，然后用软件打开就好了。

顺序：
左上角—>文件—>打开—>选择下载好的OVA文件

这样就装完成一台wazuh服务器了。

光有一台wazuh肯定是不够了，这样就不能体现出它强大的功能了。
我这里使用的centos7的代理。

填写wazuh service address就是你wazuh-server的ip地址

我这里是10.0.0.100。
然后直接copy下来安装路径，在centos7代理机下直接安装。

显示安装成功。
接着
按照给定你的步骤进行重启服务。

sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

在wazuh-server的服务机上，查看是否有这个代理。

可以看到是已经有的。

注:客户端的目录在/var/ossec/下。

可以很清楚的看到已经产生了一台代理。

wazuh中的配置了解

<global>
    <jsonout_output>yes</jsonout_output>
    
    预警记录
    <alerts_log>yes</alerts_log>
    
    不记录所有
    <logall>no</logall>
    不记录所有的json格式
    <logall_json>no</logall_json>
    邮件相关配置
    <email_notification>no</email_notification>
    <smtp_server>smtp.example.wazuh.com</smtp_server>
    <email_from>wazuh@example.wazuh.com</email_from>
    <email_to>recipient@example.wazuh.com</email_to>
    <email_maxperhour>12</email_maxperhour>
    <email_log_source>alerts.log</email_log_source>
    
    代理100分钟离线
    <agents_disconnection_time>100m</agents_disconnection_time>
    代理告警时间为实时
    <agents_disconnection_alert_time>0</agents_disconnection_alert_time>
  </global>

 <alerts>
  只要预警>=3级及以上就会记录到alert.log中
    <log_alert_level>3</log_alert_level>
    只要>=12级就会发邮件
    <email_alert_level>12</email_alert_level>
  </alerts>

 <remote>
    <connection>secure</connection>
    <port>1514</port>
    <protocol>tcp</protocol>
    <queue_size>131072</queue_size>
  </remote>

上述是客户端连接的端口。

监控root相关
  <!-- Policy monitoring -->
  <rootcheck>
  关闭为no，说明开启了
    <disabled>no</disabled>
    <check_files>yes</check_files>
    <check_trojans>yes</check_trojans>
    <check_dev>yes</check_dev>
    <check_sys>yes</check_sys>
    <check_pids>yes</check_pids>
    <check_ports>yes</check_ports>
    <check_if>yes</check_if>

    <!-- Frequency that rootcheck is executed - every 12 hours -->
    每12小时执行一次
    <frequency>43200</frequency>

监控rootkit（维持root权限的后门）
    <rootkit_files>etc/rootcheck/rootkit_files.txt</rootkit_files>
    <rootkit_trojans>etc/rootcheck/rootkit_trojans.txt</rootkit_trojans>

    <skip_nfs>yes</skip_nfs>
  </rootcheck>

可以看到有很多基线检查，比如

debian_linux操作系统的基线检查、MySQL的基线检查

rhel_linux操作系统的基线检查、Windows2012R2操作系统的基线检查等

wazuh可以检测了很多后门或者蠕虫可能存在的文件位置，基本上涵盖了百分之90的后门

ssh的暴力破解

我们使用kali进行暴力破解

查看wazuh的报警信息。

可以看到有报警日志，风险等级为5，规则的id是5710。

用户自定义规则

除了在wazuh服务器上自带的规则外，我们还可以自己编写一些我们自己想要进行防御的规则。

在wazuh的官方文档，我们可以进行清楚的了解如何编写我们想要的规则。

https://wazuh.com/blog/detecting-common-linux-persistence-techniques-with-wazuh/

SQL注入的检测

在你的代理机centos上装上apache服务器。


然后我测试，写一些注入语句。

我们可以看到wazuh-server出现了报警信息。

已经出现了告警，显示尝试SQL注入

我们怎么去防御呢？wazuh有它自身的Active-response。

wazuh有两种封堵方式：

根据告警等级来封堵，比如说当告警等级大于7时，自动进行封堵，但这也容易造成误判，范围太大
根据规则ID来封堵，当触发了某条规则时，自动进行封堵，但这范围太小，面对多条规则不便于写配置文件。

在wazuh服务器，也就是manager的配置文件里写入如下内容

当触发31103和31171这两条规则时，执行firewall-drop命令。

<active-response>
    <command>firewall-drop</command>
    <location>local</location>
    <rules_id>31103,31171</rules_id>
    <timeout>600</timeout>
</active-response>

然后我们同样进行测试。
可以发现这次进行SQL注入时直接就被进行了拦截了。