主机巡检与应急取证
主机巡检场景的核心问题是：一台可能被攻陷的 Linux 主机摆在面前，如何让 Agent 在不把环境搞坏的前提下，系统化地完成从基线收集到时间线重建的完整调查。
与告警研判不同，主机场景每一条命令都直接落到真实机器，风险远高于"查询类动作"。Flocks 的做法是：在主 Agent Rex 下面架一个专门的主机巡检 Agent，用命令白名单 / 黑名单 + 人工逐条确认这套机制，把"敏感操作"和"AI 自动化"解耦开。
场景简介
这个场景覆盖两类真实需求：
- 日常巡检：一台 / 一批机器，走一轮健康检查（CPU、内存、进程、异常登录、启动项、定时任务、网络连接……）
- 应急取证：某台机器疑似被入侵，需要在不破坏现场的情况下还原「入侵时间线」
两种用法共享同一个主机巡检 Agent，只是后者会进入「深度调查」模式，调用更多命令、输出更结构化的报告。
输入与输出
典型输入
- 目标主机列表（单台或批量）
- 已建立 SSH / 跳板机通道（主机巡检 Agent 在这基础上发起远程命令）
- 可选：历史巡检报告、资产信息、近期告警线索
典型输出
- 一轮基线报告：简短，回答"这台机器现在健康吗"
- 异常确认后的深度报告：带完整时间线、IoC、矿池地址（若挖矿）、爆破来源、持久化手段等
- 命令执行留痕：每条命令的允许 / 拒绝过程可审计
前置条件
| 依赖项 | 要求 |
|---|---|
| 模型 | 默认模型即可；推理型模型在时间线重建场景下效果更好 |
| 主机巡检 Agent | 项目内置了主机巡检 Agent 作为专家 Agent 示例；Rex 会自动委派 |
| 连通性 | Flocks 运行节点能通过 SSH / 跳板机达到目标主机 |
| 命令安全策略 | 白名单 / 黑名单 + 人工确认机制已在 Agent 中预设，不需要另配 |
| 通道 | 可选。用于把巡检结论推送到企微 / 钉钉 / 飞书 |
核心安全机制：白名单 / 黑名单 / 人工逐条确认
这是主机巡检区别于告警研判最重要的一点：
| 类型 | 行为 |
|---|---|
| 白名单 | 纯只读命令（ps、netstat、cat 只读路径、last、who 等）自动执行，无需人工介入 |
| 黑名单 | 任何写入 / 修改 / 删除动作（rm、sed -i、kill、iptables -A 等）直接拒绝 |
| 灰区（未配置） | 弹窗询问——允许一次？永远允许？或作为黑名单处理？用户不处理 = 默认走黑名单 |
这条机制让"让 AI 上机"这件事真正可落地：
- 分析员不用担心 Agent 一个幻觉把机器搞坏
- 所有高危动作必须人点过
- 留痕可审计：每条命令的决策链都留在会话里
在 Agent 的 system prompt / Skill 中可以扩展白黑名单规则。企业通常会把自己内部的合规红线以 Skill 形式注入。
操作步骤（WebUI）
步骤 1：进入一条会话并指向目标主机
在 会话管理 → + 新建会话，用自然语言描述：
「帮我巡检一下 10.10.x.x 这台机器，先看基线，如果异常就深度分析」
步骤 2：Rex 委派主机巡检 Agent
Rex 会切到「委派模式」：
- 主 Agent 的工作是"把这台机器交给专家 Agent"
- 主机巡检 Agent 接过来，拥有自己的 system prompt 和工具栈
- 两者共享整个会话上下文，但分析过程独立
步骤 3：第一轮基线收集
专家 Agent 先跑一个内置的基线收集脚本 / 命令集：
- 系统信息、CPU / 内存使用率
- 进程列表、网络连接
- 登录记录概览
- 启动项 / 计划任务 / cron
这一轮全是白名单，用户看着 Agent 跑就行，不需要交互。
步骤 4：发现异常 → 进入深度调查
如果基线阶段发现任何异常（高 CPU 未知进程、异常外联、可疑登录……），Agent 会：
- 停下来向用户说明发现了什么
- 列出接下来想执行的敏感命令
- 逐条弹窗请人工确认（允许一次 / 永远允许 / 拒绝）
这是最关键的一步：用户可以在这里拒绝任何他不想跑的命令，整个过程留痕。
步骤 5：产出结构化报告
深度调查完成后，Agent 会在 Workspace 目录里生成一份 Markdown / JSON 报告，通常包含：
- 主机画像（系统、启动时间、最近登录）
- 异常发现（进程、文件、网络）
- 完整时间线（关键）：从系统初始化到攻陷到持久化的每一步
- IoC / 矿池地址 / 爆破来源 / 用户新增的 SSH key 等
- 建议动作
步骤 6：可选——转定时任务或串进告警研判
巡检报告可以和告警研判挂钩：
- 一次性巡检 → 留在会话里即可
- 周期性巡检 → 转任务中心，每天跑一次
- 告警调查中临时发起的巡检 → 结果写回告警会话，作为证据链的一部分
真实案例走读（挖矿主机时间线还原）
节选自demo演示视频：
| 时间 | Agent 动作 | 产出 / 说明 |
|---|---|---|
| 0:10 | 确认这是一个主机巡检 / 应急 Agent | 多机快速查状态 → 发现异常再深挖 |
| 0:33 | Rex 委派主机巡检 Agent 上机 | 专家 Agent 接管 |
| 0:42 | 先跑基线脚本，收 CPU / 内存等简单指标 | 白名单，无弹窗 |
| 1:06 | 过程中出现敏感命令 → 弹窗"是否允许我仅此一次" | 关键安全机制触发 |
| 1:20 | 解释机制：白名单只读、黑名单任何写入、灰区弹窗，不处理就当黑名单 | 让用户理解边界 |
| 1:52 | Agent 发现机器上有挖矿痕迹 | 进入深度调查阶段 |
| 2:21 | Agent 写了一份报告，保存到 Workspace 目录 | 结构化 Markdown |
| 2:47 | 报告确认：机器被挖矿攻击，有矿池地址，时间线清晰 | 可直接交付给处置组 |
| 2:58 | 时间线重建：3 月 25 日系统启动 → 27 日异常登录 → 27 日 8 点挖矿启动 | 这是最有价值的产出 |
| 3:14 | 完整入侵链条：登录时间 / 软件下载 / 定时任务创建 / 文件特征 / 网络特征 | 应急取证级别的结论 |
| 3:33 | 还识别出其他爆破来源与成功登录来源 | 用户认领"有些是自己加的 key" → Agent 不把它们误判为攻击 |
产出示例（摘要）
text
主机: 10.10.x.x
结论: 确认被挖矿攻击
时间线:
2026-03-25 系统启动
2026-03-27 05:18 异常登录（爆破来源 185.x.x.x）
2026-03-27 08:04 下载挖矿程序 /tmp/xmrig
2026-03-27 08:05 创建定时任务 /etc/cron.d/update
2026-03-27 08:07 建立矿池连接 pool.xxx.com:3333
IoC:
- 矿池: pool.xxx.com:3333
- 文件: /tmp/xmrig (sha256: ...)
- 定时任务: /etc/cron.d/update
- 爆破来源 IP: 185.x.x.x, 45.x.x.x, ...
建议:
- 隔离机器
- 清除定时任务与恶意二进制
- 重置 SSH key / 账号密码
- 爆破来源 IP 加入边界封禁持续运行
| 模式 | 用法 |
|---|---|
| 一次性应急 | 留在会话里即可 |
| 周期性健康检查 | 转任务中心：每天跑一次基线，发现异常自动推送企微 |
| 批量主机巡检 | Workflow：输入主机列表，循环委派主机巡检 Agent |
| 接入告警调查 | 告警研判过程发现 host 级可疑 → 临时起一条巡检分支 |
边界与常见问题
| 问题 | 处理 |
|---|---|
| 想让 Agent 自己动手清挖矿 | 不建议。Flocks 的定位是研判 / 取证，处置动作仍由人确认执行 |
| 灰区命令弹窗太多太烦 | 在企业级 Skill 里扩展白名单，把组织公认安全的命令固化进去 |
| 主机量大 SSH 不够用 | 用 Workflow 做批次调度，不要一次丢 100 台 |
| Windows 主机 | 当前主机巡检 Agent 面向 Linux；Windows 场景可以另建一个专家 Agent |
| 报告不够深 | 在 Agent 的 system prompt 中明确要求"必须给出时间线、IoC、持久化手段"三段式 |