Coraza WAF 实战：3 步部署开源 Web 应用防火墙，拦截 SQL 注入与 XSS 攻击

痛点

Web 应用直接暴露在公网，Nginx 做反代、CDN 挡一层——但业务逻辑层面的攻击（SQL 注入、XSS、路径遍历、命令注入）依然长驱直入。传统方案是上 ModSecurity，但运维都知道它的痛：

C 模块绑定 Nginx/Apache 版本，升级互相牵制，编译出错是家常便饭
规则调试全靠翻日志，误报处理效率极低
ModSecurity v3 维护趋于停滞，安全响应速度越来越慢
内存随规则数线性膨胀，高并发下性能劣化明显

需要一个现代化的替代方案：Go 原生、与 ModSecurity 规则 100% 兼容、支持多种集成模式。

方案

Coraza WAF — OWASP 官方孵化的下一代 WAF 引擎。用 Go 重写 ModSecurity 内核，完全兼容 OWASP CRS（Core Rule Set）规则集，支持 Caddy 插件、Envoy Filter、HAProxy SPOE、独立反代等多种部署方式。

核心架构：Coraza 引擎 + OWASP CRS 规则集（800+ 条检测规则） + Caddy/Nginx 前端集成

实操步骤

第 1 步：构建带 Coraza 插件的 Caddy 并部署

Caddy 是 Coraza 官方推荐的一等集成方式，通过 coraza-caddy 插件直接内嵌 WAF 引擎，无需外部进程通信：

# 安装 xcaddy 构建工具
go install github.com/caddyserver/xcaddy/cmd/xcaddy@latest

# 构建带 Coraza 插件的 Caddy 二进制
xcaddy build --with github.com/corazawaf/coraza-caddy/v2
# 产出 ./caddy 可执行文件，约 40MB

# 下载 OWASP CRS 规则集（稳定版）
git clone --depth 1 --branch v4.7.0 \
  https://github.com/coreruleset/coreruleset.git /etc/coraza/crs

# 创建审计日志目录
mkdir -p /var/log/coraza

创建 Caddyfile 配置：

{
    order coraza_waf first
}

your-domain.com {
    coraza_waf {
        directives `
            SecRuleEngine On
            SecRequestBodyAccess On
            SecResponseBodyAccess Off
            SecRequestBodyLimit 10485760
            SecAuditEngine RelevantOnly
            SecAuditLog /var/log/coraza/audit.log
            SecAuditLogFormat JSON

            # 加载 CRS 配置与规则
            Include /etc/coraza/crs/crs-setup.conf.example
            Include /etc/coraza/crs/rules/*.conf
        `
    }
    reverse_proxy localhost:8080
}

# 启动
./caddy run --config Caddyfile

如果不想用 Caddy，也可以用 Docker 一键启动 Coraza 反代模式：

docker run -d --name coraza-waf \
  -p 443:443 \
  -v /etc/coraza/crs:/etc/coraza/crs:ro \
  -v ./Caddyfile:/etc/caddy/Caddyfile:ro \
  ghcr.io/corazawaf/coraza-caddy:latest

第 2 步：验证 WAF 拦截效果

用常见攻击向量测试——全部应返回 403：

# SQL 注入
curl -s -o /dev/null -w "%{http_code}" \
  "https://your-domain.com/api/users?id=1'+OR+1=1--"
# 403

# XSS
curl -s -o /dev/null -w "%{http_code}" \
  "https://your-domain.com/search?q=<script>alert(1)</script>"
# 403

# 路径遍历
curl -s -o /dev/null -w "%{http_code}" \
  "https://your-domain.com/../../etc/passwd"
# 403

# 正常请求 — 应正常通过
curl -s -o /dev/null -w "%{http_code}" \
  "https://your-domain.com/api/users?id=42"
# 200

查看 JSON 审计日志确认拦截详情：

tail -1 /var/log/coraza/audit.log | jq '.transaction.messages[0].message'
# "SQL Injection Attack Detected via libinjection"

第 3 步：规则调优与误报处理

生产环境最关键的一步。先用检测模式跑 1-2 周，只记录不拦截：

# crs-setup.conf 中调整异常评分阈值
SecAction "id:900110,phase:1,pass,t:none,nolog,\
    setvar:tx.inbound_anomaly_score_threshold=10,\
    setvar:tx.outbound_anomaly_score_threshold=4"

# 检测模式：只记录，不拦截
SecRuleEngine DetectionOnly

统计触发最多的规则，针对性排除误报：

# Top 10 高频命中规则
cat /var/log/coraza/audit.log \
  | jq -r '.transaction.messages[].details.ruleId' \
  | sort | uniq -c | sort -rn | head -10

# 常见场景：API JSON body 触发 SQL 注入误报
# 按路径排除特定规则段
SecRule REQUEST_URI "@beginsWith /api/webhook" \
    "id:1001,phase:1,pass,nolog,\
     ctl:ruleRemoveById=942100-942999"

# 静态资源完全跳过 WAF
SecRule REQUEST_URI "@beginsWith /static/" \
    "id:1002,phase:1,pass,nolog,ctl:ruleEngine=Off"

确认无误报后切换拦截模式：SecRuleEngine On

避坑

1. CRS 版本与 Coraza 版本兼容性

Coraza v3.x 兼容 CRS v4.x，但部分 CRS v3.x 旧规则的正则语法在 Coraza 上有差异。升级规则前必须在测试环境验证——规则解析失败会导致 WAF 启动异常或直接放行所有请求，后果比没装 WAF 更危险。

2. JSON/API 场景误报率偏高

CRS 规则默认针对 HTML 表单设计，JSON 请求体中的合法内容（代码片段、SQL 教程文本）极易触发误报。解决方案： - 对 API 路径提高异常评分阈值（从 5 调到 10+） - 设置 SecRequestBodyJsonDepthLimit 控制 JSON 解析深度 - 对已确认的误报模式用 ctl:ruleRemoveById 精确排除

3. 高并发下的性能影响

完整 CRS 规则集（800+ 条）会增加约 2-5ms 请求延迟。优化手段： - 精简规则：只加载与技术栈相关的规则文件（Go/Python 项目可去掉 PHP/Java 规则） - 路径分流：静态资源、健康检查接口直接跳过 WAF - SecRequestBodyAccess 仅对需要检查的路径开启，避免对文件上传接口做全量 body 扫描

总结

Coraza 是 ModSecurity 的现代化替代品——Go 原生实现带来更好的性能和运维体验，OWASP CRS 兼容保证规则生态无缝迁移。核心落地建议：

要点	说明
先观察后拦截	`DetectionOnly` 至少跑 1-2 周再切 `On`
精简规则集	只加载技术栈相关规则，减少误报 + 降低延迟
审计日志 JSON 化	配合 Loki/ELK 做规则命中趋势分析
持续更新 CRS	关注 coreruleset GitHub Release，覆盖新攻击向量

WAF 不是装上就完事——规则调优才是 80% 的工作量。但有了 Coraza + CRS 的基座，至少不用从零造轮子，把精力放在业务规则白名单上就够了。