🚨 重要提醒

越权（BOLA）是 OWASP Top 10 里最容易被开发忽视、却最容易在护网中被红队当突破口的一类漏洞。

本文延续本专栏「蓝队护网 / SOC 防守全套学习清单」的思路，把「损坏的对象级别鉴权漏洞（BOLA）」里的攻击类型，套进一次真实的防守复盘流程：告警发现 → 遏制隔离 → 溯源取证 → 根除恢复 → 加固复盘。

不讲虚的，只走一遍蓝队真正会踩的坑。

• 专栏：蓝队技能学习
• 话题：越权 / BOLA / 溯源取证
• 难度：⭐⭐⭐⭐
• 适合：护网备赛 / SOC 研判 / Web 安全

0 前言：为什么把这两篇笔记串起来

本专栏之前分别写过两篇笔记：

1. 一篇梳理了 BOLA（Broken Object Level Authorization，损坏的对象级别鉴权）的五种越权形态——未鉴权、参数可遍历（水平越权）、请求路径异常（路由绕过 / 垂直越权）、可遍历下载文件、鉴权凭证脆弱（伪造 Token）；
2. 另一篇是「蓝队护网 / SOC 防守全套学习清单」，按基础打底 → 安全设备 → 日志流量分析 → 应急响应取证 → MITRE ATT&CK 威胁狩猎 → 系统加固 → 脚本自动化九大模块排了优先级。

但很多同学反馈：「单看攻击类型记不住，单看防守清单又太散。」

所以这篇就用一次完整的越权防守复盘把两边粘起来——先还原攻击是怎么进来的，再看蓝队在每个阶段该干什么、用什么命令、看哪个事件 ID。你把它当成「清单的实战版」即可。

阅读建议：如果你还没看过那两篇基础笔记，建议先过一遍：BOLA 五种类型用来对号入座攻击手法，防守清单用来查每个阶段该用哪类工具。本文不再重复罗列定义，只讲「碰到时怎么办」。

1 场景还原：一次典型的水平越权告警

某周二凌晨，SOC 大屏跳了一条 WAF 告警：业务系统/api/order/detail?orderId=接口在 9 分钟内被同一源 IP 用连续递增的 orderId 高频请求，命中 WAF 的「越权 / 遍历」规则。

这是 BOLA 五种形态里最经典的「参数可遍历（水平越权）」——接口只校验了「是否登录」，没校验「这个订单是不是你的」。

1.1 攻击时间线（流量侧还原）

• 02:11:03源 IP 203.0.113.27 首次正常请求 orderId=10045，返回 200，业务正常。
• 02:11:18开始遍历：orderId=10046, 10047, 10048 …，UA 伪装成 Chrome，间隔约 0.8s。
• 02:19:51累计请求 612 次，其中 587 次返回 200 且响应体含他人订单号、手机号、地址——数据已泄露。
• 02:20:02WAF 命中「越权遍历」规则，触发告警推送至 SIEM；SOC 开始介入。

研判要点：判断「遍历」而非「正常翻页」的关键：同一会话、参数单调递增、响应体归属人与登录人不一致。三者同时成立，基本可以定性越权，不要被「用户在查自己订单」的借口带偏。

2 第一阶段：告警发现与初判

蓝队核心工作台是 SIEM（日志集中分析平台）。这条告警会同时出现在三个地方，要会关联着看：

1. WAF 侧：越权 / 遍历规则命中，附原始 Payload 与响应码分布。
2. Web 访问日志：Nginx/Apache access.log 里的高频单 IP、同 URI 不同参数。
3. 应用日志：业务系统自身日志：同一 userId 短时间内查了大量不属于自己的 orderId。

初判命令（Linux 侧）

# 1. 按源 IP 聚合访问频次，锁定可疑源 awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20 2. 看这个 IP 到底请求了哪些 orderId（参数提取） grep "203.0.113.27" /var/log/nginx/access.log | grep -oP 'orderId=\K[0-9]+' | sort -n | uniq -c 3. 关联业务日志，看响应归属是否与登录人一致 grep "203.0.113.27" /var/log/nginx/access.log | awk '{print $7}' | sed -n 's/.orderId=([0-9]).*/\1/p' | while read id; do grep "order_id=$id" /opt/app/order.log; done

如果第 2 步发现 orderId 跨度很大、且第 3 步里这些订单的 owner 与当前登录 userId 不一致——水平越权实锤，进入遏制阶段。

3 第二阶段：遏制与隔离

防守清单里写的标准应急 SOP 是遏制 → 根除 → 恢复 → 溯源 → 加固复盘，遏制永远第一优先，先止血再查因。

遏制动作清单

• 边界层：WAF / 防火墙把源 IP 203.0.113.27 拉黑，同时给该接口加临时限频规则（同会话 60s 内同接口 ≤ 30 次）。
• 接口层：通知研发对/api/order/detail临时加对象归属校验（先堵漏洞，根治代码后面再说）。
• 账号层：冻结发起遍历的登录态（强制下线该 token），避免被当跳板继续横向。

# 防火墙拉黑（firewalld 示例） firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.27" reject' firewall-cmd --reload iptables 方式 iptables -I INPUT -s 203.0.113.27 -j DROP

别一上来就重启：如果怀疑主机已失陷，禁止直接重启——会破坏内存里的取证证据（进程、网络连接、注入的内存马）。正确做法是先隔离网络、保留内存镜像，再决定处置。

4 第三阶段：溯源取证

这一步要回答三个问题：怎么进来的（攻击路径）、动了什么（影响范围）、还碰了什么别的（横向）。用 MITRE ATT&CK 杀伤链把行为挂上去，复盘才经得起推敲。

4.1 流量侧：Wireshark 还原攻击包

过滤语法：ip.addr == 203.0.113.27 && http.request.uri contains "orderId"

导出 HTTP 请求列表，看遍历节奏、是否带自动化脚本特征（固定 UA、无 Referer、间隔均匀）。

检查是否有二次回连：攻击者拿到数据后是否往外部 C2 发包（DNS 隧道 / ICMP 隐蔽通道）——一旦有，就不是越权这么简单了，要按失陷处置。

4.2 主机侧：Windows 事件日志（蓝队重中之重）

这几个事件 ID 是护网必背，研判失陷横向全靠它们：

# 用 wevtutil 导出安全日志，再交给 LogParser / ELK 分析 wevtutil epl Security C:\forensic\sec.evtx PowerShell 快速筛 4624 / 4625（取证时常用） Get-WinEvent -LogName Security -MaxEvents 5000 | Where-Object { $_.Id -in 4624,4625,4688,4104,7045 } | Select-Object TimeCreated, Id, Message | Format-Table -AutoSize

4.3 Linux 侧排查清单

4.4 用 ATT&CK 把行为映射到战术

把上面查到的行为挂到杀伤链上，溯源报告才完整：

取证工具速记：Windows 内存取证用 Volatility（提取内存木马、密码、隐藏进程）；磁盘镜像用 FTK Imager 保全；海量 evtx 用 LogParser 或直接进 ELK 检索。先取证、后处置，证据链不能断。

5 第四阶段：根除与恢复

• 根除：删除攻击者留下的痕迹（如有 webshell 清文件、清定时任务、删陌生 SSH 公钥、删恶意服务）。
• 恢复：从干净备份还原受影响数据；重置受影响用户凭证；修复 orderId 接口的对象级鉴权（这是根治 BOLA 的关键，不是加 WAF 规则就完事）。
• 验证：用 OWASP ZAP / Burp 复测该接口，确认遍历已被阻断；回归测试业务功能未被影响。

6 第五阶段：加固复盘

复盘不是写完报告就结束，要落到可执行的加固项上。对应防守清单里的「资产梳理与漏洞管理」和「攻击面收敛」。

7 防守反思：所谓「摸鱼」，是精准作为而非不作为

专栏名字叫「其实防守也摸鱼」，常被误解成防守就是混日子。走完这一遍流程你会发现恰恰相反：真正高效的蓝队，不是 7×24 死盯屏幕，而是把重复研判交给自动化，把人解放出来做威胁狩猎和加固复盘。

• 能自动化的别手动：爆破自动拉黑、告警自动分级、日志自动关联——靠 Shell / Python 脚本和 SOAR 剧本，别拿人肉 grep 当主力。
• 能前置的别后置：资产梳理、漏洞闭环、攻击面收敛、鉴权根治，这些事在护网前就该做完，而不是等告警来了再补。

希望这篇实战复盘能帮你把 BOLA 的攻击手法和防守流程真正串起来。下次在 SIEM 里看到「越权遍历」告警，你就能快速定位、果断遏制、精准溯源，最后把漏洞彻底堵上。