NucleiAv/caddy-detection-rules

# caddy-detection-rules 单一检测逻辑，在四个安全工具中分别实现并独立测试：**Wazuh**、**Suricata**、**Snort 3** 和 **Zeek**。 [Caddy](https://caddyserver.com) 是一款现代且广泛使用的开源 Web 服务器，支持自动 HTTPS。尽管它被广泛采用，但在大多数安全监控技术栈中，它几乎没有开箱即用的检测覆盖。本仓库通过一套涵盖 **29 种攻击类别**的规则集填补了这一空白——包括路径遍历、SQL 注入、XSS、命令注入、Log4Shell（JNDI，涵盖 URI 和 headers）、LFI/RFI、SSRF、扫描器/工具 user-agent、敏感文件和凭证访问、源代码控制构件暴露、编码规避、危险文件上传、双重扩展名绕过、GraphQL 内省滥用、暴力破解关联以及目录枚举。 每条规则 ID（996000–996033）在所有四个引擎中均保持一致，因此无论攻击是被 Wazuh、Suricata、Snort 还是 Zeek 捕获，同一攻击都会映射到相同的规则编号。 ## 为什么是四个工具 每个引擎对流量的观察方式都不尽相同，将相同的逻辑移植到所有引擎中，暴露出了单一实现本会隐藏的、真实的、特定于工具的缺陷： - **Wazuh** — 基于日志的检测，通过自定义 decoder 解析 Caddy 的结构化 JSON 访问日志。([wazuh v4.14.6/README.md](https://github.com/NucleiAv/caddy-detection-rules/blob/main/wazuh%20v4.14.6/README.md)) - **Suricata** — 基于网络的检测，对实时/重放的数据包捕获进行匹配。([suricata/README.md](https://github.com/NucleiAv/caddy-detection-rules/blob/main/suricata/README.md)) - **Snort 3** — 基于网络的检测，使用 `http_inspect` buffer 而非 Suricata 的 buffer 模型。([snort/README.md](https://github.com/NucleiAv/caddy-detection-rules/blob/main/snort/README.md)) - **Zeek** — 事件驱动的检测，使用其脚本层而非静态签名——并且它是这四个工具中唯一需要手动处理原始 URI 与解码后 URI 区分的工具。([zeek/README.md](https://github.com/NucleiAv/caddy-detection-rules/blob/main/zeek/README.md)) ## 仓库内容 | 文件夹 | 工具 | 内容 | |---|---|---| | [`wazuh v4.14.6/`](./wazuh%20v4.14.6) | Wazuh | XML decoder + 29 条规则，使用 `runtests.py` 进行单元测试（26/26 通过），外加一个可用的 v5.0 beta2 decoder 迁移方案 | | [`suricata/`](./suricata) | Suricata 8.0.5 | `caddy.rules` 签名文件，pcap + 实时捕获测试说明，`attack_traffic.sh` | | [`snort/`](./snort) | Snort++ 3.12.2.0 | `caddy_snort3.rules`，pcap 测试说明 | | [`zeek/`](./zeek) | Zeek 8.2.0 | `caddy_detection.zeek` 事件驱动脚本，pcap 测试说明 | 每个文件夹都有自己的 README，包含完整的安装步骤、确切的命令、沿途遇到的每一个错误以及修复方法——可以把它们当作详细的实验笔记。本顶级 README 则是导航地图。 ## 规则参考 所有 29 条规则在每个引擎中都使用相同的类别和 ID 方案： | 规则 ID | 描述 | |---|---| | 996003 | 路径遍历尝试 | | 996004 | SQL 注入尝试 | | 996005 | 敏感路径探测 | | 996008 | URI 中的 XSS 尝试 | | 996009 | 命令注入尝试 | | 996010 | 已知扫描器/攻击工具 user-agent | | 996011 | HTTP TRACE/TRACK 方法 | | 996012 | Log4Shell JNDI 注入 (URI) | | 996033 | Log4Shell JNDI 注入 (headers) | | 996013 | 敏感文件访问 | | 996014 | 凭据或私钥文件访问 | | 996015 | 备份或数据库转储文件访问 | | 996016 | 源代码控制构件访问 | | 996017 | 应用程序日志文件访问 | | 996018 | 目录枚举（基于频率） | | 996019 | 激进扫描 / 重复遍历（基于频率） | | 996020 | 可疑文件名（密码、机密、token 等） | | 996021 | 认证 endpoint 访问 | | 996022 | 对认证 endpoint 的暴力破解（基于频率） | | 996023 | 编码规避 / WAF 绕过 | | 996024 | LFI/RFI 文件包含 | | 996025 | 针对内部资源的 SSRF | | 996026 | GraphQL 内省 / API schema 探测 | | 996027 | 异常/危险的 HTTP 方法 | | 996028 | 可疑 User-Agent（为空或超大） | | 996029 | 危险文件上传 | | 996030 | 超大 URI（可能正在 fuzzing） | | 996031 | 双重扩展名上传绕过 | | 996032 | 归档或启用宏的文件上传 | 其中三条规则（996018、996019、996022）是基于频率的，要求在时间窗口内发生重复匹配事件，而不是仅靠单行日志或数据包。 ## 值得提前了解的跨引擎陷阱 跨这四个工具进行开发得出的最重要教训是：**Wazuh、Suricata/Snort 和 Zeek 默认并不提供相同的 URI。** Suricata 和 Snort 暴露了一个保留编码的原始（`http.uri.raw`）buffer，这正是 SQL 注入、路径遍历和编码规避等规则要看到实际攻击字符串所依赖的。Zeek 默认的 `HTTP::Info$uri` 已经经过了 URL 解码，这会悄无声息地导致 29 条规则中的 8 条失效，除非你通过 `http_request` 事件单独捕获原始 URI。详细信息及修复方法请参阅 [`zeek/README.md`](./zeek/README.md#48-zeek-decodes-the-uri-before-the-script-ever-sees-it)。 ## 状态 - **Wazuh v4.14.6** — 完成，已进行单元测试（26/26 通过），已作为 [PR #37032](https://github.com/wazuh/wazuh/pull/37032) / [Issue #37033](https://github.com/wazuh/wazuh/issues/37033) 提交。 - **Wazuh v5.0** — decoder 已基于内置的 Apache/CloudTrail decoder 迁移至新的 JSON 资产格式；在 `wazuh-logtest` / `/logtest` API 发布 beta 版本之前，实时测试被阻塞。 - **Suricata, Snort 3, Zeek** — 所有 29 条规则均已通过 pcap 重放和实时捕获确认触发。 ## 许可证 GPL-3.0 — 详见 [LICENSE](./LICENSE)。

标签：Caddy, CISA项目, DOE合作, Metaprompt, rizin, Rootkit, Snort 3, Suricata, Wazuh, Web安全, Zeek, 反射加载, 安全规则集, 现代安全运营, 蓝队分析