深色模式
安全复盘与红蓝对抗：演练提升
摘要：检测能力不是配置出来的，是演练出来的。本文给出红蓝对抗的组织方式、攻击场景库、蓝队量化指标（MTTD/MTTR）和复盘模板，让演练真正转化为能力。
适用环境
bash
cat /etc/os-release
systemctl is-active falco auditd rsyslog
command -v /usr/local/bin/sec-baseline.sh && echo "基线脚本可用"
command -v restic && restic version # 演练后的恢复能力1
2
3
4
2
3
4
操作步骤
1. 先定规则：演练的边界
演练必须有书面授权、明确范围与中止条件
未经授权的安全测试可能违法，也可能误伤生产。演练前必须确定：目标清单、禁止动作、时间窗口、中止联系人。
禁止动作建议：不对生产数据做破坏性操作；不外传真实用户数据与口令字典；不做可能造成服务不可用的压力测试；不触碰第三方系统。
2. 组织分工与关键原则
| 角色 | 职责 |
|---|---|
| 红队 | 模拟攻击，达成既定目标 |
| 蓝队 | 检测、分析、响应（正常值班，不额外提示） |
| 紫队/裁判 | 记录时间线、判定有效性、确保不越界 |
关键：蓝队不能提前知道具体时间与手法，否则测不出真实检测能力；但要知道"近期可能有演练"，避免误判为真实攻击引发混乱。
3. 攻击场景库（由易到难）
| 场景 | 手法示例 | 检测期望 |
|---|---|---|
| 弱口令登录 | 字典爆破 SSH/Redis | 失败登录告警、爆破封禁 |
| 凭据泄露 | 用泄露的密钥/token 登录 | 异常来源/异地登录告警 |
| 反弹 Shell | 从 Web 服务反弹 | Falco/HIDS 告警 |
| 权限维持 | 加计划任务、加账号 | FIM、auditd 告警 |
| 横向移动 | 从跳板机扫内网 | 网络策略拦截、流量告警 |
| 容器逃逸 | 提权至宿主 | Falco 容器规则告警 |
| 日志清理 | 删除/清空日志 | 日志删除审计告警 |
bash
# 蓝队自检：这些检测点是否真的存在
ausearch -k log_delete --start this-month 2>/dev/null | tail -3
journalctl -u falco --since "7 days ago" | grep -c CRITICAL
grep -c "Failed password" /var/log/secure 2>/dev/null1
2
3
4
2
3
4
4. 执行：记录每一分钟
裁判用统一时间源记录五个时刻：T0 红队开始行动（首次留痕）、T1 蓝队首次发现告警、T2 确认是攻击而非误报、T3 完成遏制、T4 完成根除与恢复。
bash
# 统一时间，避免时间线错乱
chronyc sources | head -3
date -Iseconds1
2
3
2
3
5. 量化指标
- MTTD（检测时间）= T1 − T0；MTTA（确认时间）= T2 − T1；MTTR（响应时间）= T3 − T2。
- 检出率 = 被检测到的攻击步骤 / 总步骤。
- 误报率 = 误报告警 / 总告警。
bash
# 用日志时间戳回算（示例）
grep -E "Accepted|Failed" /var/log/secure | head -5
journalctl -u falco --since "2 hours ago" --output=short-iso | head -51
2
3
2
3
目标不是"零失守"，而是"缩短检测与响应时间、提高覆盖率"。
6. 复盘模板
bash
cat >/root/security-review-template.md <<'EOF'
# 演练复盘 <日期>
## 1. 基本信息
- 演练范围 / 参与角色 / 时间窗口 / 场景清单与授权编号
## 2. 时间线
| 时间 | 事件 | 来源（哪条日志/告警） | 处置动作 | 负责人 |
## 3. 红队路径
- 入口 → 提权 → 持久化 → 横向 → 目标
- 每一步是否被检测到（是/否/延迟多久）
## 4. 蓝队表现
- MTTD / MTTA / MTTR；检出率与误报率
- 卡点（工具、权限、信息缺失、协作）
## 5. 改进项
| 编号 | 问题 | 改进措施 | 类型(检测/防护/流程/培训) | 责任人 | 期限 |
## 6. 结论
- 本次相比上次的变化
- 遗留风险与下次演练重点
EOF1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
7. 改进闭环：演练的唯一价值
改进项分四类，都要有责任人与期限：检测类（补 Falco/auditd 规则与告警阈值）、防护类（补隔离、改权限、打补丁）、流程类（明确升级路径与决策人）、培训类（针对暴露的意识短板）。
bash
# 例：演练发现反弹 Shell 未告警 → 补 Falco 规则
cat >/etc/falco/rules.d/drill-findings.yaml <<'EOF'
- rule: 应用进程发起外连到非常用端口
desc: 演练发现：Web 进程对外发起连接未被检测
condition: >
(inbound=false and fd.sport>1024 and fd.sip!="10.0.0.0/8") and
proc.pname in (nginx, java, python, node)
output: "可疑外连 cmd=%proc.cmdline dst=%fd.sip:%fd.sport"
priority: CRITICAL
tags: [network, drill]
EOF
falco --validate /etc/falco/rules.d/drill-findings.yaml && systemctl restart falco1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
8. 演练节奏
每季度一次小型演练（单场景）；每年一次综合演练（多场景、跨团队）；每次真实安全事件后，把事件当成一次"实战演练"做复盘。
验证
bash
# 演练后确认：新规则生效
falco --validate /etc/falco/rules.d/drill-findings.yaml && echo OK
systemctl is-active falco auditd rsyslog
# 确认基线未被演练破坏
/usr/local/bin/sec-baseline.sh; echo "exit=$?"
# 确认恢复能力可用
restic -r /backup/restic-repo check --read-data-subset=2%
# 改进项跟踪
grep -c "" /root/security-review-template.md1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
判定标准：有完整时间线；每项改进有责任人与期限；下次演练的 MTTD 相比本次下降；演练后基线无劣化。
常见坑
无授权、无边界的"实战演练"
可能触犯法律并造成生产事故。必须有书面授权、明确禁止动作与中止机制。
提前通知蓝队具体时间与手法
测不出真实能力。正确做法是只告知"近期有演练"，保留不确定性。
只记录结论不记录时间线
没有时间戳就无法计算 MTTD/MTTR，复盘会退化成主观评价。
复盘变成追责
会导致隐瞒与美化数据。强调"对事不对人"，重点是流程与技术改进。
改进项没有跟踪，下次演练同样问题重犯
改进项必须进看板，下次演练的第一个动作就是核对上次的改进是否生效。