怎样在Linux服务器层级加固SQL注入防护_安装ModSecurity Web防护模块-SQL-PHP中文网

modsecurity 不自动拦截 sql 注入，必须满足四前提：模块成功加载、secrequestbodyaccess on、secruleengine on、规则含 deny,status:403；缺一不可，否则防护失效。

怎样在linux服务器层级加固sql注入防护_安装modsecurity web防护模块

ModSecurity 本身不自动拦截 SQL 注入，装上模块、加载规则、重启服务 ≠ 防护生效。真正起作用的前提是：模块加载成功 + 请求体解析开启 + 规则引擎设为 SecRuleEngine On + 规则明确含 deny,status:403 动作。

常见错误是配置了 SecRule 却报 nginx: [emerg] unknown directive "SecRule"——这说明模块压根没加载进 nginx 进程里。

运行 nginx -V 2>&1 | grep -o modsecurity，输出必须含 modsecurity 字样；否则说明编译或安装失败
检查 nginx.conf 的 http 块中是否写了 load_module modules/ngx_http_modsecurity_module.so;（路径需与实际 .so 文件位置一致）
modsecurity on; 必须放在 server 或 location 块内，不能只写在 http 块顶层

CRS 的 SQL 注入规则（如 REQUEST-942-APPLICATION-ATTACK-SQLI.conf）默认不生效，因为它们依赖 ARGS 和 REQUEST_BODY 变量，而 nginx-modsecurity 默认关闭请求体读取。

PyCharm 2026.2.0.1 Linux版

PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。

下载

在 modsecurity.conf 中必须设置 SecRequestBodyAccess On，否则 POST 表单、JSON body 全部为空
若后端为 PHP-FPM，还需在 location ~ \.php$ 块中加 fastcgi_pass_request_body on;，否则 nginx 不转发原始 body
用 modsecurity_rules_file /path/to/crs/rules.conf 加载规则，不要用 Apache 风格的 Include
CRS v3.3+ 默认 SecRuleEngine DetectionOnly，需改为 On 才能执行 deny 动作

即使规则命中，CRS 默认只记录日志（log,auditlog），不会返回 403。攻击者看到页面照常响应，误以为防护失效。

检查 CRS 中是否启用异常评分兜底规则，例如：SecRule TX:ANOMALY_SCORE "@gt 5" "id:1000,deny,status:403,msg:'SQLi detected'"
若使用旧版自定义规则（如 modsecurity_crs_41_sql_injection_attacks.conf），务必补上 deny,status:403 动作，例如：SecRule ARGS "@rx (?:union\s+select|or\s+1\s*=\s*1)" "id:1001,deny,status:403,msg:'Legacy SQLi pattern'"
phase:2 是必须的，它表示在请求体解析完成后执行，否则 ARGS 不可用

最容易被忽略的是 SecRequestBodyAccess On 和 fastcgi_pass_request_body on 这两个开关——缺一不可。很多环境看似“规则都配了”，但 POST 数据根本没进 ModSecurity 引擎，等于在防火墙外建了个假哨所。