纵深防御，雷池 + ModSecurity企业级双重 WAF 环境搭建
登录
标签搜索
侧边栏壁纸
博主昵称
白小羽

  • 累计撰写 184 篇文章
  • 累计收到 0 条评论
安全服务 建站

纵深防御，雷池 + ModSecurity企业级双重 WAF 环境搭建

xiaoyu
xiaoyu
2026-07-15 / 0 评论 / 16 阅读 /

对于雷池的文章我还有这几篇，包括常见的https配置、雷池+frp反代，以及其他的试用方法都有

https://mp.weixin.qq.com/s/3JLrkymD7d46IaWbQup4wQ

https://mp.weixin.qq.com/s/Nvkx7Qdacmm9wx6OpJbejA

https://mp.weixin.qq.com/s/VBD12Ttwh8JS1oQLC_4gWA

https://mp.weixin.qq.com/s/z0NU3V4RASBFoE_cG0js7A

本篇文章主要讲解halo和雷池的搭建过程，以及防护流量走向，架构设计等等

算上自己上班时间，这篇文章总耗时7天+，自认为是一篇非常不错的文章，建议收藏转发，共5k+字，防止后面找不到了

ChatGPT Image 2026年7月11日 21_55_47

在写这篇文章期间遇到过很多部署问题，不过已经被我小羽全部解决了

通过本篇文章可以避免很多问题，帮助您搭建属于自己的防护环境，即使您没有任何WAF搭建的经历，也可以通过本篇文章来学习企业级WAF环境搭建的完整流程

完整总体网络拓扑架构

互联网流量
    │
    ▼
┌─────────────┐
│  WAF-A      │  第一层（外层）
│  (如雷池)   │
└──────┬──────┘
       │ 反代
       ▼
┌─────────────┐
│  WAF-B      │  第二层（内层）
│  (如ModSec) │
└──────┬──────┘
       │ 反代
       ▼
┌─────────────┐
│  halo    │  真实后端
└─────────────┘

若读过我这篇文章的师傅们，2025最新教程，使用雷池搭建内网靶场，进行简单的WAF绕过

搭配上本篇文章的教学，完全能搭建出如下架构的企业级防护环境，再牛逼点，自己再配个系统加固的防护应用

来杯好茶摇一摇

为什么要采用这样的架构？

不同的WAF产品拦截规则、检测的算法一般都是不同的，如果攻击者绕过了第一层WAF，那么第二层就不一定能绕过了，这才是核心价值，非常恶心的是，现实环境中还真有人这么干，层层防护，做系统加固

一般这样的架构第一层WAF，用来拦截常见的攻击手法比如漏扫 / CC，第二层针对真实的业务进行定制拦截，两层分贝专注不同的威胁，如果不嫌流量太多，那你可以全开，这样做的好处就是减少日志分析的压力

服务器选购

阿里云九折优惠：https://link.aitq.net/RcgjvF

实惠海外服务器：https://link.aitq.net/RYbx8O

通过我的专属优惠链接下单的师傅们，可以添加我v信 bAIbAIxiaoyu2024，享受一对一线上技术服务，若是长沙线下较近的，可线下上门服务

image-20260710232519757

雷池WAF配置表参考

你的客户类型WAF 推荐配置
个人站长 / 小微企业2 核 2G ~ 4 核 4G
中小企业4 核 4G ~ 8 核 8G
中型互联网公司8 核 8G ~ 16 核 16G
集团 / 金融 / 政企16 核 16G+ 集群

雷池安装

首先更新系统，确保你的软件包和系统源都是最新的，这里我用的是ubuntu 24

sudo apt update -y && sudo apt upgrade -y

image-20260711145537743

一键安装脚本，新机子默认没有装Docker，雷池会自动帮你装好，无需配置代理和下载源，预计时间3分钟

sudo bash -c "$(curl -fsSLk https://waf-ce.chaitin.cn/release/latest/manager.sh)"

image-20260711000346190

出现账号密码还有地址信息，就代表安装成功了，注意这里的IP地址可能跟你的服务器公网IP地址不一致

image-20260711000609023

需要使用你服务器的公网IP地址+端口来访问，雷池后台默认使用的是ssl协议，如果有需要可以自行配置ssl证书，没有ssl证书就会出现如下界面，我们需要点击高级

image-20260711001132738

再点继续访问

image-20260711001101675

输入刚刚控制台显示的账号密码

image-20260711001215351

到此雷池安装成功，接下来搭建防护站点

Halo CMS 服务搭建

在开始之前，需要搭建一个站点，作为防守目标，这里我就用 halo 这个博客项目

首先创建如下 Docker Compose 文件，Docker-compose.yaml

services:
  halo:
    image: registry.fit2cloud.com/halo/halo-pro:2.25
    restart: on-fAIlure:3
    depends_on:
      halodb:
        condition: service_healthy
    networks:
      halo_network:
    volumes:
      - ./halo2:/root/.halo2
    ports:
      - "8090:8090"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8090/actuator/health/readiness"]
      interval: 30s
      timeout: 5s
      retries: 5
      start_period: 30s
    environment:
      # JVM 参数，默认为 -Xmx256m -Xms256m，可以根据实际情况做调整，置空表示不添加 JVM 参数
      - JVM_OPTS=-Xmx256m -Xms256m
    command:
      - --spring.r2dbc.url=r2dbc:pool:postgresql://halodb/halo
      - --spring.r2dbc.username=halo
      # PostgreSQL 的密码，请保证与下方 POSTGRES_PASSWORD 的变量值一致。
      - --spring.r2dbc.password=openpostgresql
      - --spring.sql.init.platform=postgresql
      # 外部访问地址，请根据实际需要修改
      - --halo.external-url=http://localhost:8090/
  halodb:
    image: postgres:15.4
    restart: on-fAIlure:3
    networks:
      halo_network:
    volumes:
      - ./db:/var/lib/postgresql/data
    healthcheck:
      test: [ "CMD", "pg_isready" ]
      interval: 10s
      timeout: 5s
      retries: 5
    environment:
      - POSTGRES_PASSWORD=openpostgresql
      - POSTGRES_USER=halo
      - POSTGRES_DB=halo
      - PGUSER=halo

networks:
  halo_network:

image-20260711003222409

修改源

sudo vi /etc/Docker/daemon.json

# 添加如下内容
{
  "registry-mirrors": [
    "https://docker.srv.internal.wang",
    "https://docker.1ms.run",
    "https://docker.m.daocloud.io"
  ]
}

image-20260711003634862

重启Docker

sudo systemctl daemon-reload
sudo systemctl restart Docker

根据之前创建的yaml配置文件部署halo

sudo Docker compose up -d

image-20260711004131043

启动成功后，访问你的公网IP地址和Docker-compose.yaml文件配置的外部端口，我配置的是8090端口，配置模板如下

image-20260711022615745

官网登场

image-20260711022647230

配置拒绝公网访问，然后关闭防火墙关闭 8090 端口，去你的阿里云云服务器控制面板中设置，此时我们的流量访问情况如下

互联网流量/用户访问
    │
    ▼
    X  无法直接访问
┌─────────────┐
│  halo    │  真实后端 ，http://127.0.0.1:8090
└─────────────┘

image-20260711135205648

雷池单层WAF搭建

网络拓扑

互联网流量/用户访问
    │
    ▼
┌─────────────┐
│  WAF      │  外层，IP：你的公网IP，我的是 http://175.24.181.203
│  (雷池)   │
└──────┬──────┘
       │ 反代
       ▼
┌─────────────┐
│  halo    │  真实后端 ，http://127.0.0.1:8090
└─────────────┘

1、雷池添加防护

找到防护应用模块，点击添加应用

image-20260711133822100

填好上游服务器，还有域名信息

image-20260711135355225

此时再通过IP/域名访问，这个就是反向代理出来的 127.0.0.1:8090 Halo服务

image-20260711134247559

访问第一篇hellow halo文章，注入sql注入规则，若出现如下界面，则代表防护成功

http://175.24.181.203/archives/hello-halo' or 1=1 --+

image-20260711135818774

对应的防护数据，在攻击防护中查看

image-20260711140141605

可视化统计面板

image-20260711140200913

双层WAF搭建

若雷池被攻破了，会直接影响业务，我们可以在雷池之下再搭建一层WAF，不同的waf规则不同，防护的强度也会增大，在hvv期间很多人会这么干

那为什么要用 雷池 作为最外层，因为雷池的强大是总所周知的，花耗时近10年打造的WAF产品，由长亭独创的智能语义分析算法驱动

第二层waf，推荐使用ModSecurity WAF，网络架构

互联网流量/用户访问
    │
    ▼
┌─────────────┐
│  WAF-A      │  第一层（外层）http://175.24.181.203
│  (雷池)     │
└──────┬──────┘
       │ 反代
       ▼
┌─────────────┐
│  WAF-B      │  第二层（内层）
│(ModSecurity)│  监听端口：http://127.0.0.1:8080
└──────┬──────┘
       │ 反代
       ▼
┌─────────────┐
│  halo       │  真实后端，http://127.0.0.1:8090
└─────────────┘

ModSecurity WAF 搭建

安装命令

sudo apt install -y nginx libnginx-mod-http-modsecurity modsecurity-crs

image-20260712002255744

配置 ModSecurity 主规则文件

sudo tee /etc/modsecurity/modsecurity.conf << 'EOF'
# 全局开关：On=开启拦截，DetectionOnly=仅日志不拦截
SecRuleEngine On
# 开启请求体检测，覆盖 POST 参数
SecRequestBodyAccess On
SecResponseBodyAccess Off

# 日志配置
SecAuditEngine RelevantOnly
SecAuditLog /var/log/nginx/modsec_audit.log
SecDebugLog /var/log/nginx/modsec_debug.log
SecDebugLogLevel 0

# 临时目录配置
SecTmpDir /tmp/
SecDataDir /tmp/

# CRS 核心必需变量（修复 901001 自检 500 报错）
# 版本号对应 OWASP CRS 3.3.5
SecAction "id:900000,phase:1,pass,nolog,\
    setvar:tx.crs_setup_version=3033500,\
    setvar:tx.anomaly_score=5,\
    setvar:tx.paranoia_level=1,\
    setvar:tx.sql_injection_score=5,\
    setvar:tx.xss_score=5"

# 按依赖顺序加载 CRS 核心规则
Include /usr/share/modsecurity-crs/rules/REQUEST-901-INITIALIZATION.conf
Include /usr/share/modsecurity-crs/rules/REQUEST-913-SCANNER-DETECTION.conf
Include /usr/share/modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf
Include /usr/share/modsecurity-crs/rules/REQUEST-921-PROTOCOL-ATTACK.conf
Include /usr/share/modsecurity-crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf
Include /usr/share/modsecurity-crs/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf
Include /usr/share/modsecurity-crs/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf
Include /usr/share/modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf
Include /usr/share/modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf
Include /usr/share/modsecurity-crs/rules/RESPONSE-950-DATA-LEAKAGES.conf
Include /usr/share/modsecurity-crs/rules/RESPONSE-959-BLOCKING-EVALUATION.conf
EOF

创建nginx反向代理站点，监听8080断开，将 ModSecurity 流量转发到 Halo 后端

sudo tee /etc/nginx/sites-avAIlable/modsec-waf << 'EOF'
server {
    listen 8080;
    server_name _;

    # 启用 ModSecurity WAF
    modsecurity on;
    modsecurity_rules_file /etc/modsecurity/modsecurity.conf;

    # 反向代理到 Halo 后端
    location / {
        proxy_pass http://127.0.0.1:8090;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}
EOF

释放 80 端口，不然会和雷池冲突

sudo unlink /etc/nginx/sites-enabled/default

启用站点并重启 ModSec 服务

# 启用 ModSecurity 站点
sudo ln -sf /etc/nginx/sites-avAIlable/modsec-waf /etc/nginx/sites-enabled/

# 检查配置语法
sudo nginx -t

# 重启 Nginx 
sudo systemctl restart nginx

雷池 WAF 配置

点击删除防护站点

image-20260711195806813

注意此时本地应用是8080端口，原来是 halo 8090 端口

image-20260711195902188

访问站点，能够正常访问

image-20260711200036290

拦截测试，注意，此次攻击流量没有走到第二层waf，已经被雷池给拦截了所以你在第二层waf中看不到此请求

image-20260711200148659

所以我们为了能直观的看到ModSecurity WAF是否搭建成功，我们需要去阿里云的控制台放行 8080 端口防火墙

直接访问8080端口，真实情况下我们是不会开放这个端口的

http://175.24.181.203:8080/

image-20260711200930373

sql注入测试

http://175.24.181.203:8080/archives/hello-halo' or 1=1 --+

image-20260711204131009

对应的拦截日志

# 实时查看拦截日志
tAIl -f /var/log/nginx/modsec_audit.log

image-20260711204222020

我用AI写了一个批量测试脚本 waf_test.sh

赋予执行权限

chmod +x waf_test.sh

执行文件

image-20260711220836692

image-20260711220858332

双层WAF，Agent 攻击测试

最近热门的就是agent自动渗透了，我用的是strix这个开源项目，自己用rust魔改了一版

./strix-rs -t http://175.24.181.203/ -m quick  -i "请只对带雷池waf防护的80端口halo应用进行全面的渗透测试，和waf绕过，最后告诉我你使用了哪些规则，是否绕过，打印在终端中"

image-20260711223356466

来看看agent怎么讲？几乎全是正面反馈

image-20260711224239384

image-20260711224308606

经过50次的会话迭代，未发现漏洞和绕过雷池的规则

image-20260711224600049

来看看雷池防护了多少攻击次数

image-20260711230643124

攻击日志分析，每一条未拦截的日志，咱们都可以在第二层modsec waf中添加自定义规则，从而达理想的到防护效果

image-20260711230807148

用之前AI生成的攻击脚本，将端口去掉，打雷池

image-20260712003143117

image-20260712004557388

常见问题

1、运维人员如何规避重复告警？

对于双重waf，一个sql注入的请求，可能会被两个waf一起拦截，从而两个waf都产生大量告警

应对方法，我们可以把每一个waf进行分工，比如WAF-1负责黑白名单、CC、通用攻击；WAF-2负责敏感信息泄露、业务逻辑漏洞等等。

2、延迟增加

每个请求都会经过一层反向代理，两层waf如果不在同一个机房，延迟会显著增加，我们可以将三台服务器尽量部署在同一个内网或者同一个机柜中，这样延迟能下降不少

3、真实IP地址丢失

第一层waf流量转发给第二层时，源IP变成WAF-1的内网IP。第二层waf和业务服务看到的全是127.0.0.1之类的地址，通常用 X-Forwarded-For 或 X-Real-IP 头传递真实IP

需要在防护应用中的高级配置中，为上游服务器传递 X-Forwarded-Host、 X-Forwarded-Proto

image-20260712012952510

如何获取授权？

雷池社区版开箱即用，但如果需要更加专业的防护，可以打开下面短链扫码登录获取授权，通过我的专属链接下单，可享受一对一专属技术顾问进行答疑，欢迎咨询 / 项目合作

https://link.aitq.net/mt2nFu

image-20260709001129529

登录后找到雷池授权商店，打开这个应用

image-20260709001828432

点击购买授权

image-20260709001905386

这里支持专业版和商业版的试用套餐，点击申请试用即可

image-20260709001925277

同样的，也可以扫描下方二维码，加入雷池社群，寻找工作人员获取授权，感谢阅读

0
暂无标签
版权属于： xiaoyu
本文链接： https://longyusec.com/archives/207/
作品采用： 《 署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0) 》许可协议授权

评论 (0)

取消