Nginx + ModSecurity + OWASP CRS 是最可控WAF方案，但需开启SecRequestBodyAccess、配置后端传递请求体、启用异常分数阻断，并辅以map快速兜底，WAF仅拦截明显恶意流量，不能替代应用层防护。
直接上结论：Nginx + ModSecurity + OWASP CRS 是当前 Linux 生产环境最可控、可审计、可调优的 WAF 方案，但默认配置几乎不拦 SQL 注入——因为请求体没解析、规则没启用、异常分数没触发。
SecRequestBodyAccess 必须显式开启
SQL 注入大量藏在 POST body 里（比如 login 表单、JSON 接口），而 Nginx 默认不把请求体传给 ModSecurity。不打开这个开关，REQUEST_BODY 和 ARGS_POST 规则永远匹配不到内容。
-
SecRequestBodyAccess On要写在modsecurity.conf全局配置里，不是 location 块内 - 后端是 PHP-FPM：必须在
location ~ \.php$块中加fastcgi_pass_request_body on; - 后端是 proxy_pass（如 Node.js/Java）：对应 location 加
proxy_pass_request_body on; - 漏掉任一环节，
REQUEST-942-APPLICATION-ATTACK-SQLI.conf就等于摆设
OWASP CRS 的 REQUEST-942 规则不能直接开全
CRS 3.x/4.x 的 SQLI 规则集很强，但默认策略偏保守：只记录不拦截，且对 multipart/form-data 解析支持弱，上传接口带参数时极易漏检。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 必须手动启用异常分数阻断逻辑，例如：
SecRule TX:ANOMALY_SCORE "@gt 5" "id:1000,deny,status:403,msg:'SQLi detected'" - 首次上线务必先用
SecRuleEngine DetectionOnly运行 3–5 天，看modsec_audit.log里误报——order by id、limit 10都可能被标为高危 - 若业务大量用
LIKE '%xxx%'，需临时禁用942100（LIKE 检测规则），否则正常搜索全 403
加一层 Nginx map 快速兜底防绕过
ModSecurity 启动慢、单请求多耗 5–15ms，且规则引擎对大小写变换、十六进制编码、注释符绕过等手法响应滞后。用 map 提前拦截高频攻击特征，成本几乎为零。
- 在
http块定义：map $args $sql_flag { ~*[\"'`;\(\)\/\*%00] 1; ~*(select|union|insert|update|delete|drop|sleep|benchmark) 1; default 0; } - 在 server 或 location 中：
if ($sql_flag = 1) { return 403; } - 注意：
map只能匹配$args（GET 参数），POST body 需配合前面的SecRequestBodyAccess才完整 - 这条规则挡不住
SEL/**/ECT或%73elect，但它能快速筛掉 80% 的扫描器原始 payload
真正难处理的是二阶注入和 WAF 规则盲区——比如 FIND_IN_SET(1, column) 后面拼接闭合括号触发函数调用检测，但 WAF 只拦 sleep() 不拦 FIND_IN_SET()；这种场景靠规则永远追不上，得靠应用层预处理语句兜底。WAF 不是银弹，它只负责把“明显恶意”的流量掐在第一道门，别指望它替你修代码。
