恢复放行的检查条件
把主机放回生产环境之前要逐项确认：清理动作已完成、失陷入口已封堵、监控规则已上线、补丁与口令已更新。四项都过一遍再放行，并留下放行记录与观察期安排。观察期内若检测规则命中，要有明确的升级路径，否则观察期等于没有设置。
基本信息
| 四查 | 清理、封堵、监控、加固，逐项确认后再放行 |
|---|---|
| 清理要求 | 持久化条目已清除并通过复扫确认 |
| 封堵要求 | 入口漏洞或弱口令已修复，外联目标已在网络侧阻断 |
| 监控要求 | 针对该事件的检测规则已上线并验证生效 |
| 留痕要求 | 放行时间、复核人与观察期安排一并记录 |
典型使用场景
- 处置完成后决定该主机是否可以恢复网络
- 多台主机分批恢复时逐台执行放行检查
- 观察期内出现新告警时的处理依据
- 向上汇报处置进展时说明恢复条件
- 结案前确认恢复动作与清理动作都已完成
放行清单
放行清单
# 放行前逐项核对，全部通过才恢复网络
[ ] 持久化条目已清除并复扫确认
[ ] 入口漏洞或弱口令已修复
[ ] 外联目标已在网络侧阻断
[ ] 该主机的检测规则已上线
[ ] 观察期 72 小时，异常即回退放行检查项
| 检查项 | 通过标准 | 不通过的后果 |
|---|---|---|
| 清理 | 持久化条目复扫无残留 | 很快再次失陷 |
| 封堵 | 入口漏洞或弱口令已修复 | 同一路径被再次利用 |
| 监控 | 检测规则上线并验证生效 | 再次入侵无人发现 |
| 加固 | 补丁与凭据已更新 | 已知问题仍可被利用 |
观察期不是拖延流程，而是给检测规则一次验证机会：期间若规则从未命中任何正常业务，先确认规则接入是否真的生效，再结束观察，否则观察期起不到作用。
没有复扫就放行容易二次失陷：清理掉一个持久化点之后，主机上可能还有其它入口。复扫一遍的成本，远低于同一主机被再次入侵后的处置代价。