Wazuh需通过active-response调用自定义脚本实现勒索行为断网，必须绑定多源证据（文件加密+异常进程+外连）的高置信度规则（如rule_id 100200），脚本须幂等、轻量、带锁文件与30分钟自动恢复机制。
Wazuh 本身不直接执行“断网”动作，必须通过 active-response 机制调用本地脚本完成；关键不是“一检测就断”，而是确保触发条件精准、脚本幂等、断网后留有恢复路径。
怎么让Wazuh在检测到勒索行为时触发断网
Wazuh 的 active-response 是唯一合法出口。它不能靠日志关键词模糊匹配就断网（比如只看到 "README.*" 就执行），必须绑定明确、低误报的规则 ID，并且该规则需基于多源证据（如文件加密 + 进程异常 + 网络外连）综合判定。
- 先确认你已启用
active-response：检查/var/ossec/etc/ossec.conf中<active-response>段未被注释，且<enabled>yes</enabled> - 定义一个专用响应脚本，例如
/var/ossec/active-response/bin/block-ransom-egress.sh，开头加if [ -f /tmp/.ransom_blocked ]; then exit 0; fi防重复 - 在
ossec.conf里注册该脚本：<command><name>block-ransom-egress</name><executable>block-ransom-egress.sh</executable></command> - 将此命令绑定到你自定义的高置信度勒索规则（如 rule_id
100200），而非默认的通用告警规则
勒索行为检测规则该怎么写才靠谱
直接匹配 "*.locked" 或 "README.TXT" 是典型误报源——合法备份脚本、开发测试文件都可能命中。真正可用的规则必须串联至少两个独立信号：
- 信号1：在 Web 目录（如
/var/www/html）或用户主目录下，10 分钟内创建 ≥5 个带加密扩展名的文件（.crypt、.cerber、.wannacry等），由syscheck实时监控触发 - 信号2：同一时间窗口内，出现进程调用
openssl或gpg并写入大量文件，且父进程非已知可信服务（如 nginx、apache） - 信号3（可选但推荐）：该进程主动连接外部 IP:443/8080/4444，且目标不在白名单中（需配合
firewall或netstat日志采集） - 三者同时满足才生成 rule_id
100200，并启用<options>no-email, no-log, active-response</options>
断网脚本必须满足的三个硬性条件
脚本不是越狠越好，失控的断网比勒索更伤业务。以下三点缺一不可：
-
轻量且无依赖：只用
ip route del default移除默认路由（保留内网通信），避免用iptables -P OUTPUT DROP这类影响所有 socket 的操作；不调用 Python/Perl，纯 Bash + BusyBox 可用命令 -
带二次校验和锁文件：执行前再跑一次
find /var/www -name "*.locked" | head -n 1，确认原始证据仍存在；成功后touch /tmp/.ransom_blocked并记录完整上下文到/var/log/wazuh/ransom-block.log -
自带 30 分钟自动恢复开关：脚本末尾加
systemd-run --on-active=30min /var/ossec/active-response/bin/restore-egress.sh，避免因误判导致长期失联；恢复脚本只需ip route add default via 192.168.1.1 dev eth0并删锁文件
为什么不能只靠 Wazuh 自带的 firewall 响应
Wazuh 内置的 firewall-drop 响应只封源 IP，对勒索病毒无效——病毒早已在本机运行，封攻击者 IP 不解决任何问题。而 host-deny 会修改 /etc/hosts.deny，但现代勒索木马根本不用 SSH 或 inetd 服务，这条路完全走不通。必须用 active-response 调用自定义脚本，直接干预本机网络栈。
最容易被忽略的是恢复机制的设计：没有超时自动回滚，就没有真正的“应急”；没有人工确认入口（比如 echo "RUN /var/ossec/active-response/bin/restore-egress.sh TO RECONNECT" >> /dev/console），运维人员深夜收到告警却无法快速判断是否该介入。
