声明本文所有测试均在本地搭建的DVWA/SQLi-Labs训练靶场中进行仅用于安全学习与WAF防护能力验证请勿用于未授权环境。漏洞类型SQL注入漏洞编号CWE-89 / OWASP A03:2021测试环境DVWA本地靶场安全等级Low测试目的蓝队WAF防护能力验证Payload1 UNION SELECT database(),version()#漏洞类型跨站脚本攻击XSS漏洞编号CWE-79 / OWASP A03:2021测试环境DVWA本地靶场测试目的WAF防护与白名单绕过验证Payloadscriptalert(document.cookie)/script正文在网络安全攻防演习护网中蓝队研判人员面对海量告警日志需要在最短时间内区分真实攻击与误报并做出精准处置决策。这不仅考验对攻击手法的技术理解更考验对业务场景的判断能力——一次错误的放行可能导致系统被攻破一次过度的拦截又可能中断正常业务。本文以雷池SafeLineWAF为核心防护设备以DVWA靶场为攻击目标完整复现了从环境搭建、攻击测试、告警研判到误报处置的全流程。通过有WAF防护与无WAF直连的对照实验直观展示WAF对SQL注入和XSS攻击的拦截效果并深入剖析了正常HTML请求被误判为XSS攻击时的研判思路与处置策略。无论是护网备战的入门学习还是日常安全运维的参考借鉴希望本文都能为你提供一份可落地的实操指南。一、环境搭建测试环境采用双机虚拟化架构Windows宿主机运行DVWA靶站通过phpStudy提供Web服务Ubuntu虚拟机运行雷池WAF通过Docker容器化部署。雷池以反向代理模式部署所有访问DVWA的流量必须经过WAF检测。1、部署docker容器:国内直接访问docker仓库扒取因为网络原因会比较困难所有我们直接实用ubuntu自带源安装docker如下图安装完之后使用enable命令使其开机自启动并且使用restart命令重启此服务。最后使用docker version和docker compose version查看docker的版本如下下图2、部署雷池:通过此命令部署雷池:bash -c $(curl -fsSLk https://waf-ce.chaitin.cn/release/latest/manager.sh)进入此界面之后根据默认的选项一步一步往下进行即可。雷池安装完之后通过此命令获取admin账户密码docker exec safeline-mgt resetadmin获取admin账户密码之后在浏览器访问:https://192.168.44.136:9443/根据自己的ip来但是后面的端口都是默认9443。如果打不开则在虚拟机上检查是否放开了9443端口打开9443端口:ufw allow 9443/tcp进入之后显示此页面则点击高级然后点击继续前往即可。进去之后输入刚刚获取的admin账户密码即成功安装雷池。随后点击左边的防护应用此界面右上角添加应用开始配置需要防护的站点。域名填写你phpstudy上配置的靶场即可上游服务器填你后端服务的地址和端口注意不要选https和443端口否则会需要证书提交之后雷池对你靶场的保护就正式开始了雷池的部署到这一步就结束了。部署完docker和雷池即可开始本次的实验了。二、研判过程当环境部署完成之后我们即可开始本次的实验啦。我们先验证雷池是否开始保护打开浏览器进入http://dvwa.local/dvwa登录进去登录之后找到左边那一栏最下面的DVWA Security将防护等级设置为low随后选择点击左边那一列中的的Sql Injection进行验证在其界面输入adminor 11 --进行测试--后面有一格空格否则会报语法错误。由此可知雷池已经对我们开始进行防护则做好了实验前的最后一步。注意本次实验设置了对照组请仔细观察上方的url。http://dvwa.local/***这是我部署了雷池防护的域名对照组http://192.168.44.1/dvwa/***则未部署雷池防护对照组就算是漏洞复现和部署雷池的域名进行对比。1、使用Sql注入获取当前数据库名和版本:1 UNION SELECT database(),version()#CWE-89 / OWASP A03:2021在设置了雷池防护的域名中图一使用此命令时被雷池拦截未能获取到数据库名和版本而在对照组中图二由于未设置任何有效的措施而被直接渗透获取到数据库名和版本。在雷池的界面进入攻击防护中的攻击日志中可以清楚的知道此次攻击的信息比如攻击者ip、攻击载荷、攻击方式等。在真实的研判工作时不仅仅要盯着雷池的界面还要对其拦截下来的攻击进行处理判断其为真攻击还是误报、攻击是否被拦截成功雷池拦截了不代表所有攻击都被拦截了可能有漏报、此次攻击的风险等级。这些都是需要我们去进行人为判断的。我们还要对告警进行复现我们在未部署雷池的域名处进行了被其轻易的拿到了数据库名和版本这就属于真攻击而非雷池的误报。在真实的研判工作中一旦确定其为真实的攻击之后我们还要对其ip进行下一步处理可以通过雷池进行ip封禁或者假如黑名单等手段使其无法对我们域名造成威胁。进行这些操作之后我们还要记录研判台账如下表每发现一处告警就记录一处最后进行汇总生成分析报告并上报。序号时间攻击类型源IP目标urlPayloadWAF动作研判结论风险等级漏洞复现结果116:10Sql注入192.168.44.1http://dvwa.local/dvwa/vulnerabilities/sqli/1\ UNION SELECT database(),version()#拦截真实攻击高危绕过WAF后获取成功漏洞存在2.....XSS*********************************************2、XSS攻击反射型:scriptalert(document.cookie)/scriptCWE-79 / OWASP A03:2021由两图可知此命令被雷池完完整整的拦截下来在未部署雷池的域名则成功获取用户的cookie在真实的渗透中客户的cookie被红队方获取是极其高危的漏洞。我们可以在雷池的攻击日志界面获取此次攻击的数据以及类型通过对照组我们能得知其为真实漏洞并非误报我们可以重复和第一组最后的操作对其ip进行封禁和拉进黑名单等操作。接下来我们来接触研判工作的重中之重对于误报怎么操作。3、雷池误报:我们使用此命令:a hrefjavascript:void(0)菜单/a此命令为合法HTML链接但含javascript从而导致被误报。通过图一可知其被雷池拦截并进行告警可通过图二我们又可知其为正常代码不包含漏洞可依旧被雷池拦截。由前面两张图对比以及对代码进行分析我们可以肯定这是一次误报在下图1的左下角有误报按钮真实的护网研判时点击这是误报即可。由于这是实验且我们的雷池是个人版点击误报没反应所以我们对此误报命令加入白名单使其不会误报。我们对误报的分析不仅于此我将误报的处置流程整理成下图2以供参考。我们按照上图1将此命令加入白名单加入白名单后刚刚被拦截的界面变成了如下图可以正常执行代码进入dvwa后端。可是将此命令加入白名单就没风险了吗事实上不一定。一旦让红队获取到了我们的白名单他就可以在xss攻击的命令中加入白名单的命令特征来规避雷池的防护比如这条命令:a hrefjavascript:void(0)菜单/ascriptalert(document.cookie)/script这条命令中前面是我们的白名单是之前被误报的正常命令a hrefjavascript:void(0)菜单/a可是在后面加入了我们xss攻击的命令我们一起来看看此方法能不能绕过白名单对我们的dvwa后端进行攻击吧。在有Waf防护的情况下执行此命令依旧被拿到了cookie这就代表此命令成功的绕过了白名单对我们的dvwa后端进行了渗透。所以说白名单有好处也有风险设置白名单能使误报的概率变小能使客户日常使用中更便捷报错概率更小但是一旦让红队人员获取到我们的白名单他们就可以在某些渗透的命令中加入白名单的特征以此来绕过我们部署的Waf所以在真实的HW中我们作为蓝队的研判人员如果出现了误报的情况我们不能一味的增加白名单我们可以根据误报的情况来决定我们如何进行操作。我将操作流程整理成下图。hw期间一切以服务器的安全为先优先考虑服务器的安全。三、总结至此本次实验就到此结束啦我们来对本次模拟web告警蓝队研判的实验流程做一个总结。1、雷池发出警告对其具体信息进行研判。分析其payload等信息2、判断其是否为真实攻击如为真实攻击看其攻击是否攻击成功攻击成功则开启应急响应攻击未成功我们则进行对其ip封禁或者持续监控。如为误报我们则按文中讲到的流程进行操作。3、对所有的误报和真实攻击进行台账记录hw结束后进行研判报告的输出以便业务人员对漏洞进行优化。