上一节我们学习了 NAT 与地址隐藏技术，构建了企业网络边界的地址隐藏防线；而 Web 防火墙（WAF，Web Application Firewall）防护，则是 Web 业务的 “专用防线”—— 传统防火墙只能基于 IP / 端口过滤流量，无法识别应用层攻击，而 WAF 则专门针对 HTTP/HTTPS 协议的 Web 攻击进行防护，是 Web 业务安全的必备工具。
一、先搞懂：什么是 WAF？和传统防火墙有什么区别？
WAF 是专门针对 Web 应用的防护设备，工作在 OSI 模型的应用层（第 7 层），它通过分析 HTTP/HTTPS 请求的内容，识别并阻断 SQL 注入、XSS、CSRF 等 Web 攻击，弥补了传统防火墙无法防护应用层攻击的缺陷。
传统防火墙 vs WAF 核心对比
表格
| 维度 | 传统防火墙 / NGFW | WAF（Web 应用防火墙） |
|---|---|---|
| 工作层级 | 网络层 / 传输层（第 3-4 层） | 应用层（第 7 层，HTTP/HTTPS） |
| 核心过滤依据 | 五元组（IP / 端口 / 协议） | HTTP 请求内容（URL、参数、Cookie、Header） |
| 防护场景 | IP / 端口访问控制，阻断网络层攻击 | 专门防护 Web 应用层攻击（SQL 注入、XSS 等） |
| 对 Web 业务的价值 | 只能开放 80/443 端口，无法识别应用层恶意请求 | 识别并过滤 Web 攻击请求，保护 Web 业务安全 |
二、WAF 核心防护场景：常见 Web 攻击类型与防护方式
WAF 的核心价值，就是防护传统防火墙无法识别的 Web 应用层攻击，以下是企业高频 Web 攻击类型与 WAF 防护方式：
表格
| 攻击类型 | 攻击原理 | WAF 防护方式 |
|---|---|---|
| SQL 注入 | 攻击者在请求参数中插入 SQL 语句，欺骗数据库执行非授权查询 | 基于规则匹配和语法分析，拦截含 SQL 关键字 / 语法的请求 |
| XSS 跨站脚本 | 攻击者在页面中注入恶意脚本，在用户浏览器中执行，窃取 Cookie / 敏感信息 | 过滤请求参数中的脚本标签和恶意 JS 代码 |
| CSRF 跨站请求伪造 | 攻击者诱导用户访问恶意链接，以用户身份执行非授权操作 | 验证请求 Referer、Token，拦截跨站伪造请求 |
| 路径遍历 / 目录穿越 | 攻击者通过构造特殊路径（如../），访问服务器上的敏感文件 | 拦截包含路径遍历符号的请求，限制访问路径 |
| 暴力破解 | 攻击者通过大量请求尝试登录后台，破解账户密码 | 限制请求频率，拦截短时间内多次失败的登录请求 |
| 恶意爬虫 / CC 攻击 | 攻击者通过大量恶意请求，消耗服务器资源，导致业务瘫痪 | 限制请求频率，拦截恶意爬虫和 CC 攻击流量 |
三、企业 WAF 部署模式：三种主流方案对比
不同业务架构和防护需求，对应不同的 WAF 部署模式，以下是企业常用的三种模式对比：
表格
| 部署模式 | 原理 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 反向代理模式 | WAF 作为 Web 服务器的反向代理，所有 Web 请求先经过 WAF，再转发给后端服务器 | 完全控制流量，可修改请求 / 响应，防护最彻底 | 需要修改业务架构，配置域名 / 端口映射 | 企业级核心 Web 业务，防护要求高 |
| 透明代理模式 | WAF 串接在 Web 服务器和防火墙之间，流量直接经过，不修改网络拓扑 | 无需修改业务架构，部署简单，不影响用户访问 | 对网络性能有一定影响，故障可能导致业务中断 | 无法修改业务架构的场景，临时防护 |
| 旁路模式（仅检测） | WAF 通过镜像流量进行分析，不阻断流量，仅生成告警 | 不影响业务性能，部署无风险 | 无法主动阻断攻击，仅用于威胁检测 | 业务无法中断的场景，或用于攻击分析 |
四、WAF 核心配置要点（企业通用落地版）
1. 防护规则配置：从默认到定制
- 启用基础防护规则：开启 SQL 注入、XSS、路径遍历等通用防护规则，拦截常见攻击
- 自定义业务规则：针对业务场景配置规则，如电商网站拦截恶意爬虫、登录接口配置防暴力破解规则
- 规则优先级管理：严格规则优先，避免宽松规则覆盖防护策略
2. 白名单管理：平衡防护与业务体验
- 业务白名单：将业务正常的请求路径、参数加入白名单，避免误杀业务流量
- 可信 IP 白名单：允许内网、合作方 IP 的请求，避免正常业务被拦截
- 白名单严格管控：仅添加业务必需的白名单，定期清理过期条目，避免被攻击者利用
3. 日志与告警配置：攻击行为可追溯
- 启用全量请求日志：记录所有经过 WAF 的请求，包括攻击请求和正常请求，留存不少于 6 个月
- 配置告警策略：对高危攻击（如 SQL 注入、路径遍历）配置告警，及时通知安全人员处置
- 日志外发：将 WAF 日志同步到企业日志平台，便于后续攻击溯源和审计
4. 性能调优：避免影响业务访问
- 开启 HTTPS 卸载：将 SSL/TLS 解密工作交给 WAF，减轻后端 Web 服务器压力
- 缓存静态资源：对图片、JS、CSS 等静态资源开启缓存，减少 WAF 处理压力
- 规则优化：关闭不必要的规则，调整规则匹配模式，提升 WAF 处理性能
五、企业 WAF 落地完整流程
- 评估阶段：梳理企业所有 Web 业务，标记核心业务和普通业务，明确防护需求
- 部署阶段：根据业务架构选择部署模式，核心业务用反向代理，普通业务用透明代理
- 测试阶段：先在测试环境部署 WAF，验证业务功能是否正常，调整白名单和规则，避免误杀
- 上线阶段：分批次上线，先非核心业务，再核心业务，逐步切换流量
- 监控与优化：监控 WAF 告警和业务访问情况，定期调整规则和白名单，优化防护效果
六、企业落地常见误区（避坑指南）
- 误区 1：默认规则全开，不做业务适配：直接启用所有 WAF 规则，导致大量正常业务请求被误杀，影响用户体验
- 误区 2：白名单乱加，给攻击请求开绿灯：为了解决误杀，直接把整个域名加入白名单，导致 WAF 形同虚设
- 误区 3：只防护 HTTP，忽略 HTTPS 业务：WAF 未配置 SSL 证书，无法解密 HTTPS 流量，无法识别加密请求中的攻击
- 误区 4：部署模式选错，导致业务中断：业务无法修改架构却选了反向代理模式，或业务对性能敏感却用了透明代理模式
- 误区 5：只阻断不告警，或只告警不阻断：仅开启阻断不记录日志，无法溯源；或仅告警不阻断，攻击发生时无法及时防护
- 误区 6：部署 WAF 后就一劳永逸：随着业务迭代和新攻击手段出现，不更新规则和白名单，防护效果逐渐失效
📝 本节小结
WAF 防护的核心，不是 “规则越多越好”，而是在不影响业务正常运行的前提下，精准识别并阻断 Web 应用层攻击。反向代理模式适合核心业务，透明代理适合快速部署，旁路模式适合威胁检测；配合合理的规则配置、白名单管理和日志留存，才能真正发挥 WAF 的防护价值，筑牢 Web 业务的专用防线。
No responses yet