1. 监测

攻防演练开始前，要对监测设备的告警规则进行调优。

• 僵尸、木马、蠕虫、C2远控类告警可以直接忽略

• 挖矿病毒类告警视情况而定，如果时间充裕可以去处置

• 重点关注web层面的攻击，如SQL注入，命令执行、文件上传+中高危+攻击成功

• 各种高危CVE漏洞+攻击成功重点关注

• Webshell类告警单独设规则，设备上不一定显示攻击成功，可能显示尝试，但这并不代表它没有攻击成功，而要去看流量上下文，看命令执行和响应体，看是否持续访问固定webshell路径即关注频率

• 像类冰蝎Webshell类告警很有可能是魔改后的冰蝎马，需要持续关注

• 内存马需上机排查，在告警设备上的特征是持续告警攻击成功，但是路径不固定，响应体中无内容。上机排查关注error.log，使用脚本进行扫描。

• 真实场景中，由于网络拓扑环境错综复杂，简单的00，10判断方向往往失效，要随机应变

• frp、fscan、隧道流量单独设规则

2. 研判

一般进行研判的思路，就是通过流量上下文+手工验证+攻击频率次数来判断是否漏洞是否存在，是否攻击成功。
如下图，就可以判断访问webshell进行命令执行，可以判断攻击成功且上传了webshell：

又如最近的Nacos授权绕过漏洞，原始告警如下图：

通过查看流量原文可以确定攻击成功，如下图：

这里需要注意，很多告警如redis未授权，mongodb未授权等未授权漏洞攻击成功在流量上下文中不能体现，需要去手动验证。
如redis验证未授权redis-cli -p 端口 -h 受害者IP
其他未授权可以直接访问路径查看

但是即使你无法验证成功，也不能
就研判为误报，而要结合攻击成功告警的频率（比如说它已经告警成功了20000+），很有可能由于网络拓扑的复杂，在你当前所处的环境中无法验证成功，此时可以让其他不同的网络环境中同事帮忙验证。

3. 应急溯源

攻防中大家分工明确，应急溯源分工又不是很明确，可能多个团队在做同一件事，所有沟通非常重要。

时效性非常重要，必须尽快出报告。

原文于：https://www.freebuf.com/articles/web/372186.html原文作者:捞起月亮的渔民

 点击下方小卡片或扫描下方二维码观看更多技术文章

师傅们点赞、转发、在看就是最大的支持