你的 SecRule 规则真的拦得住攻击吗ModSecurity-nginx 集成测试实战入门【免费下载链接】ModSecurity-nginxModSecurity v3 Nginx Connector项目地址: https://gitcode.com/gh_mirrors/mo/ModSecurity-nginxModSecurity-nginx 是 ModSecurity v3 在 Nginx 上的连接器负责把 libmodsecurity 接进 Nginx 的请求生命周期。要验证一组 SecRule 规则在这个环境里是否按预期拦截攻击靠的是tests/目录下的集成测试——它们用 Perl 和 Test::Nginx 框架拉起一个真实的 Nginx 进程发送真实 HTTP 请求再逐条断言响应。读一遍这套测试比读十页文档更知道规则应该怎么表现。下图是连接器以插件方式接入 Nginx 的架构示意也是这套测试框架最终验证的对象备齐三样东西测试跑道跑测试之前需要凑齐三样测试脚本、Test::Nginx 框架、可用的 Nginx 二进制。测试脚本随仓库提供全部在tests/目录Test::Nginxnginx 官方测试套件中的 Perl 模块cpan Test::Nginx即可安装自编 Nginx必须编译了 ModSecurity-nginx 模块并链接 libmodsecurity原版 Nginx 不认识modsecurity指令。第一次接触的话clone 仓库拿到测试脚本是关键一步git clone https://gitcode.com/gh_mirrors/mo/ModSecurity-nginx把第一个测试跑起来 测试文件不能孤立运行需要放进 nginx-tests 测试套件目录——Test::Nginx 模块和公共配置模板都住在那里。把 ModSecurity 的测试文件复制过去再用prove指定 Nginx 二进制的路径来跑cp tests/*.t /path/to/nginx-tests/ cd /path/to/nginx-tests TEST_NGINX_BINARY/path/to/your/nginx prove .TEST_NGINX_BINARY告诉框架该用哪个 Nginx。两种常见跑法对比跑法命令适用场景单个测试prove modsecurity.t只想确认规则拦截行为全量回归prove .改动连接器代码后提交前拆开一个 .t 文件看它怎么工作每个.t文件结构都一样读懂tests/modsecurity.t就算掌握了全部套路。它分四步声明测试对象my $t Test::Nginx-new()-has(qw/http/);表示本测试依赖 http 模块写 Nginx 配置$t-write_file_expand(nginx.conf, ...)生成临时配置其中%%TEST_GLOBALS%%一类占位符由框架自动填充配置里modsecurity on;加modsecurity_rules两条指令就开启了一套规则准备资源并启动$t-write_file(/phase1, should be blocked...)写入测试用的静态文件$t-run()启动 Nginx发请求、断言例如like(http_get(/phase2?whatblock403), qr/^HTTP.*403/, block 403 - phase 2);这一行发一个请求并断言响应以 403 开头。modsecurity.t用阶段 1~4 × 重定向/拦截组合出 21 条断言验证规则在正确的阶段生效、不多拦也不少拦。顺着套件认识规则验证的场景tests/下有 15 个.t文件文件名基本就是功能地图测试文件验证的内容modsecurity.t核心拦截阶段 1~4 的重定向与拦截行为modsecurity-request-body.t/-h2请求体检查含 HTTP/2 场景modsecurity-response-body.t阶段 4 检查响应体modsecurity-proxy.t/-h2反向代理下的规则行为modsecurity-config-merge.thttp/server/location 多层配置如何合并继承modsecurity-config-auditlog.t、-debuglog.t审计日志、调试日志写到哪里、写了什么modsecurity-scoring.t绝对计分与迭代计分是否数得对modsecurity-transaction-id.t各日志中的事务 ID 是否一致modsecurity-limits.t请求体大小等限制是否生效写你自己的规则验证测试 ✍️掌握上面的套路后加测试就是套模板改断言。最小骨架长这样use Test::More; use Test::Nginx; my $t Test::Nginx-new()-has(qw/http/); $t-write_file_expand(nginx.conf, EOF); %%TEST_GLOBALS%% daemon off; events {} http { %%TEST_GLOBALS_HTTP%% server { listen 127.0.0.1:8080; modsecurity on; modsecurity_rules SecRuleEngine On SecRule ARGS streq attack id:100,phase:2,deny,status:403 ; } } EOF $t-run(); $t-plan(2); like(http_get(/?aattack), qr/^HTTP.*403/, 攻击请求被拦截); like(http_get(/?asafe), qr/200/, 安全请求放行);几个约定值得注意日志路径用%%TESTDIR%%占位符如SecAuditLog %%TESTDIR%%/auditlog-root.txt框架保证每个测试目录互相隔离写完还能直接读日志内容来断言$t-plan(N)的数目必须和断言条数一致对不上测试直接失败需要手工构造原始请求时可以像tests/里的 H2 测试那样用http(EOF)块发送裸请求。用转换脚本跑一遍被动回归除了专用测试项目还提供tests/nginx-tests-cvt.pl这个小转换脚本它把modsecurity on;和一段基础规则自动插进 nginx 官方功能测试的server_name行之后让整个 nginx 功能测试集带着 ModSecurity 模块一起跑验证模块不会改变 Nginx 本身的行为perl tests/nginx-tests-cvt.pl original.t modified.t改过连接器的 C 代码后建议把这类被动回归也跑一轮再提交。测试红了怎么排查失败先别慌测试框架会在/tmp/nginx-test-*留下临时目录答案多半在里面Nginx 没起来看error.log常见原因是TEST_NGINX_BINARY指向了没编译 modsecurity 模块的普通 Nginx规则像没生效把SecDebugLogLevel 9配上调试日志路径再核对日志里有没有该规则 id 的命中记录断言数目或结果不符先核对$t-plan()条数再确认listen端口模板里是 8080没和本地进程冲突。当第一个测试变绿之后剩下的事就是照着套件里的模式一条断言一条断言地往上加。【免费下载链接】ModSecurity-nginxModSecurity v3 Nginx Connector项目地址: https://gitcode.com/gh_mirrors/mo/ModSecurity-nginx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考