在之前的一篇文章中，我们介绍了HackShop这个自研漏洞靶场的相关漏洞。为了深入了解开源WAF在实际环境中的防护能力，我们对当前国内口碑不错、GitHub星标超过2万的雷池WAF（SafeLine）进行了实测，看看它究竟能防住靶场中的哪些攻击。
我们首先安装了雷池WAF社区版，并将目标靶场域名 mall.nordun.io 添加为防护应用，配置代理到上游的真实服务器。
接下来，我们按照漏洞类型逐一测试防护效果。
一、 针对身份认证页面的CC攻击防护
我们首先测试WAF对高频请求（CC攻击）的防护能力。进入雷池控制台的“CC防护 -> 频率限制”模块，可以看到默认的“基础访问限制”规则：某IP在10秒内请求达到100次，再次访问需要进行人机验证。
为了触发这条规则，我们模拟针对登录接口的爆破攻击。使用Burp Suite Intruder模块，对登录接口 /auth/user/login 进行Cluster bomb攻击，设置position1为邮箱参数，position2为密码参数，尝试20个账号各5次登录（总计100次请求）。
在10秒内发送超过100次请求后，后续的访问请求被WAF重定向到了人机验证页面。
点击“确认”按钮后，系统会进行短暂的安全检测，随后恢复正常访问。
在雷池控制台的CC防护日志中，可以清晰地看到测试IP因“10秒内访问100次”而命中基础访问限制，动作为“强制人机验证60分钟”。
思考与优化：
默认的全局频率限制虽然有效，但可能课伤正常用户。例如，一个资源丰富的页面（包含数十个CSS、JS、图片）在用户快速刷新时，也可能在10秒内产生超过100次请求。更精准的做法是针对敏感接口（如登录）配置自定义规则。
我们在CC防护的自定义规则中，为登录路径 /auth/user/login 添加一条规则：10秒内请求达到100次，则直接封禁IP 5分钟。
添加此规则后，再次重复之前的爆破测试，请求被直接拦截，并显示“请求频率过高，已被管理员拦截”。
查看控制台日志，可以看到测试IP 5.34.216.213 已被封禁。
防护的局限性：
WAF的CC防护主要基于IP维度。攻击者使用IP代理池即可轻易绕过单IP的频率限制。切换一个新IP后，攻击者又能正常访问登录页面。
这本质上是安全攻防的成本对抗：攻击收益与规避成本（如购买代理IP）之间的博弈。
二、 传统Web攻击拦截测试
接下来，我们测试WAF对传统漏洞的防护能力。
1. SQL注入
尝试访问一个包含 or '1'='1 这类经典注入Payload的URL，请求被雷池WAF立即拦截。
2. 任意文件读取（SSRF）
在之前的文章里，我们利用后台商品批量导入功能的SSRF漏洞，成功读取了 /etc/passwd 文件。在部署WAF后，相同的攻击请求被拦截。
查看雷池WAF的攻击详情日志，可以清楚地看到触发拦截的Payload为 file:///etc/passwd，命中了内置的“访问系统文件的请求”防护规则。
总结与体验
经过实测，雷池WAF社区版在防护传统Web攻击方面表现出色，能够有效检测和拦截SQL注入、文件读取等常见攻击载荷，其CC防护模块也提供了基础和高阶的配置能力，能应对一定规模的洪水攻击。
然而，和所有WAF一样，它也存在天然的盲区——业务逻辑漏洞。例如条件竞争（一码多换）、Host头注入（任意账号密码重置）等漏洞，其请求在语法和频率上往往与正常业务请求无异，仅依靠请求特征分析的WAF难以有效防护。这类漏洞的发现，更多依赖于深入的业务理解和安全测试，或许需要依靠人工渗透测试或更先进的IAST（交互式应用安全测试）技术。但IAST在生产环境的广泛应用，仍面临性能和稳定性的挑战。
总而言之，部署WAF是提升Web应用安全水位的重要一步，至少能过滤掉大量的自动化扫描和已知攻击模式，为系统建立一道基础防线。对于更高级别的安全需求，则需要构建覆盖安全开发周期(SDL)、常态化渗透测试和实时监控的纵深防御体系。
欢迎在云栈社区交流更多关于WAF配置、安全防护的实战经验与心得。
发表于 19 小时前
|
查看: 1|
回复: 0
