ModSecurity在Nginx上需确认模块加载与请求体访问：先用nginx -V验证modsecurity存在，再设SecRequestBodyAccess On和SecRuleEngine On，否则规则无效。
ModSecurity 在 Nginx 上不是“开个配置就能用”的插件，规则不生效的最常见原因就两个：SecRequestBodyAccess Off（默认值），以及 nginx -V 输出里压根没有 modsecurity。这两点没确认，后面所有规则都是摆设。
确认 nginx 已真正加载 modsecurity 模块
这是所有操作的前提。Nginx 原生不支持 SecRule 指令，报 unknown directive "SecRule" 就说明模块根本没加载成功。
- 运行
nginx -V 2>&1 | grep -o modsecurity，必须有输出（如--add-dynamic-module=../nginx-modsecurity） - Debian/Ubuntu 推荐直接装
nginx-mod-http-modsecurity包，它已预编译好 connector；CentOS/RHEL 基本得自己编译libmodsecurity+nginx-modsecurity - 验证动态链接是否生效：
ldd $(which nginx) | grep modsecurity，无输出 = 模块未真正加载 -
load_module路径必须是绝对路径，比如modules/ngx_http_modsecurity_module.so，少一个斜杠或拼错字母都会失败
必须显式开启请求体访问和规则引擎
OWASP CRS 的 SQL 注入规则（如 REQUEST-942-APPLICATION-ATTACK-SQLI.conf）默认不检查 POST body，因为 SecRequestBodyAccess 默认是 Off。漏掉这行，等于关掉了大部分检测能力。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 在
http、server或location块中写：SecRequestBodyAccess On - 同时必须启用规则引擎：
SecRuleEngine On（仅写modsecurity on不够） - 若后端是 PHP-FPM，还需在对应
location块加：proxy_pass_request_body on;和fastcgi_pass_request_body on;，否则原始 body 不传给后端，ARGS变量始终为空 - 对
multipart/form-data请求，CRS 的ARGS_NAMES可能漏匹配，建议加兜底规则：SecRule REQUEST_BODY "@rx (?i)(union\s+select|select\s+.*\s+from)" "id:1002,phase:2,deny,status:403,msg:'Raw SQLi in body'"
绕过 CRS 的常见手法及补救配置
攻击者用 sel%65ct、UNI/**/ON SEL/**/ECT 或双 URL 编码时，CRS v3.3+ 虽有 t:urlDecodeUni，但在 Nginx 请求链路中容易丢失二次解码环节。
- 确保规则中明确启用转换链，例如：
SecRule ARGS "@rx (?i)union\s+select" "t:urlDecodeUni,t:lowercase,id:1003,phase:2,deny,status:403,msg:'SQLi via ARGS'" - 不要只依赖
ARGS，还要覆盖REQUEST_COOKIES、REQUEST_HEADERS、REQUEST_BODY等变量，攻击可能藏在任意位置 - CRS 规则默认只
log不deny，必须显式加上deny,status:403动作，否则只是记日志 - 避免把
SecRuleEngine On写在http{}顶层——它必须放在server或location块内才生效
真正难的不是写规则，而是让 Nginx 把原始请求体完整、未解码、未截断地交给 ModSecurity 处理。从 nginx -V 到 SecRequestBodyAccess On 再到 fastcgi_pass_request_body on，链条上任何一环断开，规则就形同虚设。很多人调了三天发现 SELECT 还是能过，问题往往出在第二步没做全。
