3. 排查前的环境准备：日志采集配置、审计策略开启、流量镜像、工具链搭建

3.1 现象识别：环境准备缺失的典型表象

排查隐式权限绕过漏洞前，若环境准备不足，往往在以下场景暴露问题：

• 日志缺失：识别到敏感操作后，在 /var/log 或 Windows Event Log 中找不到对应时间戳条目。
• 审计空白：尝试追踪 SeTakeOwnershipPrivilege 或 SeBackupPrivilege 调用时，事件ID 4672/4673 未产生。
• 流量不可见：使用 tcpdump 抓包发现无预期数据包，确认未配置端口镜像。
• 工具链报警：启动 Zeek/Wireshark 时提示“interface not found”或“no such file”。

3.2 数据采集：四类环境准备的具体配置

3.2.1 日志采集配置

目标：确保操作系统、应用服务器、中间件的关键日志能够被集中收集并保留至少 90 天。

3.2.2 审计策略开启

Windows 审计策略必须针对“对象访问”、“特权使用”、“进程创建”等子类别启用成功/失败审核。

auditpol /set /subcategory:"对象访问" /success:enable /failure:enable
auditpol /set /subcategory:"特权使用" /success:enable /failure:enable
auditpol /set /subcategory:"进程创建" /success:enable
auditpol /list /subcategory:*

Linux 使用 auditd 记录文件访问与特权调用：

auditctl -w /etc/passwd -p wa -k passwd_change
auditctl -a always,exit -S execve -F uid=0 -k root_exec
auditctl -l

3.2.3 流量镜像

在交换机或虚拟化平台上配置端口镜像（SPAN/ERSPAN），确保目标流量能够到达分析节点。

验证流量是否到达：

tcpdump -i eth0 -c 100 src 10.0.0.1 and dst port 443

3.2.4 工具链搭建

必备工具清单及安装/配置检查表：

• 抓包分析： Wireshark (tshark) + tcpdump + Zeek (Bro) 日志解析
• 日志分析： ELK (Filebeat + Logstash + Elasticsearch + Kibana) 或 Splunk
• 特权审计： Windows Sysinternals (AccessChk, Process Monitor)、Linux lsof/strace/aa-status
• 攻击模拟： Impacket (secretsdump, wmiexec), BloodHound

# Zeek 快速部署
sudo apt-get install zeek
zeekctl deploy
# 查看连接日志
cat /opt/zeek/logs/current/conn.log | head -20

# BloodHound 采集器
sudo apt-get install bloodhound.py
bloodhound-python -d target.local -u user -p password -gc dc.target.local -c All

3.3 原因定位：使用故障树排查环境缺失

当数据采集失败时，使用以下故障树快速定位根因：

• 日志未采集（根节点）
  • → 检查 syslog 服务是否启动：systemctl status rsyslog
  • → 检查目标端口连通性：telnet collector-ip 514
  • → 检查磁盘空间：df -h /var/log
• 审计策略未生效（根节点）
  • → Windows：auditpol /get /category:* 确认 “特权使用” 为 “成功和失败”
  • → Linux：auditctl -s | grep "enabled" 确认 auditd 正常运行
• 流量镜像丢失（根节点）
  • → 检查交换机 SPAN 会话状态：show monitor session 1
  • → 验证分析接口的 MTU 不小于源接口
• 工具链异常（根节点）
  • → Wireshark：没有 root 权限则无法捕获原始包，使用 setcap cap_net_raw+ep /usr/bin/dumpcap
  • → BloodHound：检查 neo4j 数据库是否运行：sudo systemctl status neo4j

3.4 修复动作：环境配置修补与重新激活

根据原因定位的结果执行相应修复：

1. 日志采集修复：重装 rsyslog / 修改 /etc/rsyslog.conf，重启服务
2. 审计策略修复：auditpol /clear 后重新配置或使用组策略推送
3. 流量镜像修复：重新创建 SPAN 会话，若 ERSPAN 需确认 GRE Tunnel 配置
4. 工具链修复：卸载冲突版本，从官方仓库或 GitHub Release 安装稳定版本

3.5 复测：验证环境可用性

执行以下命令或操作，确认所有采集链路正常：

# 日志采集复测
logger -p user.info "env_test_$(date +%s)"
grep "env_test" /var/log/syslog  # 临时本地验证，再检查集中收集端

# 审计策略复测
auditctl -m privilege_check -p root -k test_audit
ausearch -k test_audit --just-one

# 流量镜像复测
tcpdump -i eth0 -c 10 -nn host 10.0.0.1  # 源IP真实存在

# 工具链复测
zeekctl status | grep "running"
tshark -D | wc -l  # 至少显示2个以上接口

所有复测项必须返回非空且无错误输出，否则标记为失败并返回 3.2 重新配置。

3.6 预防：环境健康检查自动化

将环境准备状态纳入持续监控，建立每日/每周基线检查脚本：

• 自动巡检：使用 Ansible 或 Shell 脚本，每天早上检查四类组件状态，输出 JSON 报告。
• 阈值告警：当日志接收速率低于基线 50% 或审计事件中断超过 5 分钟时，触发告警。
• 混沌工程演练：定期模拟日志服务崩溃、交换机链路故障，测试恢复流程。

# 简易检查脚本片段
#!/bin/bash
echo "=== Log check ==="
systemctl is-active rsyslog || echo "FAIL"
echo "=== Audit check ==="
ausearch -i --start today --success yes | head -1 || echo "FAIL"
echo "=== Traffic check ==="
tcpdump -i any -c 1 -t 2>/dev/null || echo "FAIL"
echo "=== Tool chain ==="
which tshark zeek bloodhound-python 2>/dev/null || echo "MISSING"