在中小型企业或初创企业中做安全运营，往往面临资源有限和人手不足的情况，很可能一个人把控全公司的安全建设。而为了提升安全运营效率，另一方面还要省钱，不想要手动处理很多问题吗，以我上家公司为例，那就需要把 Wazuh（基于 OSSEC 的开源 HIDS）、Cloudflare 的 WAF 与 企业微信做联动，方便随时看问题并自动化做响应，举个例子：
自动化封禁某个 IP + 企业微信推送
这种自动化流程只要想清楚思路之后做起来就会很简单很快，思路如下：
写脚本把 CF 的日志导入 Wazuh，这一步稍微复杂一点，需要转发、再用 Filebeat 配置好输入日志，最后再解析就行；
用 Cloudflare 的 API + token 写一个用于 Wazuh 的 Active Response 脚本，用于封禁相应的 IP 地址；
再用企业微信的 API + token 写一个用于在封禁 IP 或者其他重要安全事件发生时发送通知的机器人脚本；
写一条 Wazuh 规则，当识别到某些恶意日志时自动响应，调用上面的脚本；
测试、验证、部署、监控等后续工作
以上内容几乎只需要自己写 Wazuh 上的脚本，因为无论是企业微信还是企业内部用的各种 IM，内部一定有现成的告警、打电话服务，修改一下就能用；CF 的 API 也是到处都有现成的代码，所以整体工作量不大。
我比较推崇 Wazuh，很多人只把他当作 HIDS 来用，确实，它是一套优秀的主机型入侵检测系统，但他的能力不仅限制在这里，把 Wazuh 用好就是个 SIEM，能给安全运营团队省很多事儿。因此我在上家公司的设计就是以 Wazuh 为核心做自动化响应。
先说说 Wazuh 的整体架构把：
Wazuh Indexer：基于 OpenSearch Fork 出来的版本，它是一个水平拓展性很高的全文搜索和分析引擎，它的工作内容主要是对 Wazuh Server 生成的 Alert 进行索引建设和存储，并提供"几乎"实时的数据搜索和分析功能；
Wazuh Server：Wazuh Server 分析数据，在检测到威胁或异常时触发一个 Alert；它还能远程配置客户端配置、实时监控客户端状态等；
Wazuh Dashboard：看板，基于 Kibana 做的 Web UI，可以做出很多漂亮的表格、折线图之类；
Wazuh Agent：安装在主机上的 HIDS，主要负责收集日志和对事件做出 Active Response等等；
看上图说话，Wazuh 工作的大体流程就是通过运行 Agents 在被监控的终端上，Agent 包含很多模块，负责把将安全数据转发到 Server；而且它还支持无代理设备，如防火墙、交换机、路由器和接入点，并且可以通过Syslog、SSH 或使用它们的API主动提交日志数据。
Wazuh Server 负责解码并分析传入的信息，然后将结果传递给 Wazuh Indexer 以进行索引和存储。Wazuh Indexer 集群是一个由一个或多个节点组成的集合，这些节点相互通信以执行对 Indexer 的读写操作。
我认为对于大部分中小型公司，单节点集群就足够了。当监控的终端较多、预期数据量大或需要高可用性时，再使用多节点集群。
对于生产环境，我是比较建议将 Wazuh Server 和 Wazuh Indexer 分开部署在不同的主机上，然后再使用 Filebeat 通过 TLS 加密安全地将 Wazuh Alert 和 Archive 事件转发到Wazuh Indexer。
再说说我们做的自动化监控：
日志数据分析：将 syslog 日志存储在一个纯文本文件中并使用 Wazuh 进行监控：将日志存储在纯文本文件中并监视该文件, 需先改 /etc/rsyslog.conf 配置文件并且定义存储系统日志的位置, 配置一个以 syslog 作为日志格式的 <localfile> 块来监控
文件完整性、异常监控：这里要配合 AuditD，对 /bin, /sbin, /usr/bin, /usr/sbin, /dev, /lib, /etc, /root, /var/log, /var/mail, /var/lib, /var/www, /usr/lib, /usr/include, /tmp, /boot, /usr/local, /var/tmp and /sys 主要是这些目录
系统调用监控：也是修改 Agent 上的 ossec.conf
Active Response 脚本：主要是做自动化响应和对高危操作的阻断
安全配置评估 SCA：NGINX 和 Centos 的评估
容器监控：包括容器的 pause 和 stop 等
最重要的是 Agent 连接状态的监控
如果是从 0 开始，建议还是先把 Wazuh 默认开箱即用的规则看一遍，然后再针对自身做相应的增加和修改等，目录如下：
/var/ossec/
├─ etc/
│ ├─ decoders/
| | └─ local_decoder.xml
│ └─ rules/
| └─ local_rules.xml
└─ ruleset/
├─ decoders/
└─ rules/ruleset/ 目录中存放通用规则和解码器，假设你想修改一个规则的告警级别，级别分为0 - 16，数字越大级别越高，例如 /var/ossec/ruleset/rules/0095-sshd_rules.xml 这个规则，简单的修改 level 字段从 5 到 16，并设置 overwrite 为 yes：
<group name="syslog,sshd,">
...
<rule id="5710" level="16" overwrite="yes">
<if_sid>5700</if_sid>
<match>illegal user|invalid user</match>
<description>sshd: Attempt to login using a non-existent user</description>
<mitre>
<id>T1110</id>
</mitre>
<group>invalid_login,authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,pci_dss_10.6.1,gpg13_7.1,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,nist_800_53_AU.6,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
</rule>
...
</group>最后重启服务端就 OK 了。
再说 decoder，它的作用是自定义去解析上报日志内容的功能，以便后续规则可以识别对应的日志，Wazuh 自带 JSON、动态字段、Sibiling三个解码器，修改解码器的目录就在 decoders 内，假设你想收集防火墙日志，就需要自己实现一个解码器咯。
最后说几句 Decoders 和 Rules 之间的关系：
在 Wazuh 的架构中，Decoder 和 Rule 是用来处理和分析从代理和其他数据源接收到的日志信息的两个关键组件。
Decoder：
Decoder 的主要功能是解析和预处理日志数据。当 Wazuh 收集到日志时，它首先通过一系列预定义的 Decoder 处理。Decoder 能够识别和解析特定格式的日志（如 JSON、Syslog 或特定应用的日志格式）。每个 Decoder 都会根据其配置抽取日志中的关键信息，例如源 IP、用户名、动作类型等，并将这些信息格式化为内部处理的标准格式。Decoder 还可以进行数据转换，比如把日期和时间从一种格式转换到另一种。
Rule：
处理过的日志数据会传递到 Rules。Rule 是定义特定条件和阈值的逻辑单元，用于分析 Decoder 提取的数据。如果传入的数据匹配了某个 Rule 的条件，那么就会触发相应的警报。例如，一个 Rule 可以设定在某个 IP 地址短时间内多次失败的登录尝试超过一定次数时触发警报。Rules 可以是非常简单的匹配，也可以是复杂的逻辑，包括多个条件和阶段性的检查。
二者关系：
Decoder 和 Rule 在 Wazuh 中的关系可以这样理解：Decoder 负责“理解”日志内容，即将日志数据分解成可识别的格式；而 Rule 则基于这些格式化的数据来“判断”是否满足定义的安全策略或标准，从而决定是否需要触发警报。
简而言之，Decoder 是数据的预处理和格式化工具，而 Rule 则是基于这些预处理数据的决策和响应机制。两者共同构成了 Wazuh 安全监控的核心逻辑，使得系统能够有效地识别和响应潜在的安全威胁。