网站被SQL注入、XSS跨站脚本、恶意扫描攻击?这些针对Web应用的攻击,普通防火墙(参考防火墙篇)拦不住——它们藏在正常的HTTP请求里。拦截它们需要WAF(Web应用防火墙)。本文讲清WAF是什么、怎么用ModSecurity自建。
一、WAF是什么?和普通防火墙的区别
普通防火墙工作在网络层,管的是”哪个IP能连哪个端口”(参考防火墙篇)。但SQL注入、XSS这类攻击是通过正常的80/443端口、正常的HTTP请求发起的,恶意代码藏在请求内容里——普通防火墙看不出来。WAF工作在应用层,检查HTTP请求的内容,识别并拦截其中的攻击特征。它是网站安全的重要一层。
二、WAF能防哪些攻击?
- SQL注入:防止攻击者通过输入注入恶意SQL窃取/破坏数据库;
- XSS跨站脚本:防止注入恶意脚本攻击访客;
- 恶意扫描和探测:拦截漏洞扫描器的探测;
- 文件包含、命令注入等常见Web攻击;
- 配合规则还能防部分CC和恶意爬虫(参考反爬虫篇)。
三、ModSecurity:开源WAF的标杆
ModSecurity是最著名的开源WAF,可以配合Nginx/Apache使用。它的强大之处在于配合OWASP核心规则集(CRS)——一套由安全社区维护的、覆盖常见Web攻击的规则库。装上ModSecurity + OWASP CRS,就有了一个能拦截主流Web攻击的防护层。
四、部署思路(Nginx + ModSecurity)
部署方式(概念性,具体按版本文档):
- 为Nginx安装ModSecurity模块(编译或用带模块的版本);
- 下载并配置OWASP核心规则集(CRS);
- 在Nginx配置中启用ModSecurity、加载规则;
- 先用”检测模式”(DetectionOnly)运行:只记录不拦截,观察一段时间看会误拦哪些正常请求;
- 调整规则、排除误报后,再切换到”拦截模式”正式防护。
用Docker的话,也有集成好ModSecurity + CRS的Nginx镜像可以直接用,省去编译。
五、关键:处理误报(WAF的主要工作)
WAF最大的挑战是误报——把正常请求当成攻击拦了,影响业务。所以:
- 务必先用检测模式跑:观察日志,看哪些正常操作被规则命中;
- 调整规则等级和排除:CRS有偏执度(Paranoia Level)设置,按需调整;对确认是误报的规则做排除;
- 持续观察:上线后继续看日志,平衡”拦得严”和”不误伤”。
WAF不是装上就完事,调优误报是持续工作。
六、自建WAF vs 云WAF
- 自建ModSecurity:免费、可控、可深度定制,但要自己部署、调优、维护规则,有一定门槛;
- 云WAF(如Cloudflare的WAF):开箱即用、规则由厂商维护更新、还兼顾CDN和DDoS防护(参考Cloudflare篇),但高级功能可能付费。对多数网站,Cloudflare的WAF是更省心的选择——在边缘就拦截攻击,不用自己维护;
- 结合:云WAF在边缘挡一层,源站ModSecurity再挡一层,纵深防御。
七、WAF是安全体系的一环
WAF很重要,但不是万能的,它是整体安全的一层(参考各安全篇):应用本身要安全(如WordPress加固,参考WP安全篇)、服务器要加固(SSH、防火墙)、要及时更新补漏洞、要做好备份。WAF拦截攻击流量,但不能替代其他防护。
结论
WAF(Web应用防火墙)拦截藏在HTTP请求里的应用层攻击(SQL注入、XSS等),是普通防火墙管不了的一层。自建用ModSecurity + OWASP CRS(先检测模式调误报再拦截),省心用Cloudflare云WAF。对多数网站,云WAF更实用;有深度定制需求或想纵深防御则自建。WAF是网站安全的重要一层,配合应用加固、服务器加固、备份构成完整防护。
