自动化信息收集

自动化信息收集（Recon）会在目标主机上生成有明确范围和上限的客观快照。新客户端优先生成 snapshot-jsonl-v2，其中的 *.recon.jsonl 是权威证据；*.md 由同一份快照确定性生成，供 WebUI、MCP 和人工快速浏览。Recon Profile 只选择模块，不覆盖超时、资源上限或分析逻辑。

Recon 不判断主机状态是否正常，也不执行白名单、黑名单、矿工、Webshell、Rootkit symbol 或不安全配置判定。原始环境变量、凭证、配置和历史记录会按采集范围写入快照；对已经读取的配置、凭据和供应链文本，Recon 还会在固定上限内记录可定位的内容形态事实，例如疑似访问密钥、令牌、密码赋值或 URL 用户信息。派生事实只保留模式 ID、行号、脱敏值和完整值的 SHA-256，不给出风险结论；是否存在风险仍由 Agentic 应急响应 或其他分析流程结合上下文判断。

使用方式

Investigations -> Recon -> 选择客户端和 Profile -> Start Recon

WebUI 流程

1. 打开 Web 控制台，进入 Investigations 页面。
2. 在 Recon 表单中选择在线客户端和该客户端实际提供的 Profile。旧客户端只显示 Legacy default。
3. 点击 Start Recon，等待客户端回传阶段进度。
4. 报告生成后，点击 Open Report 打开派生 Markdown。hunt 的 Markdown 是紧凑索引，完整证据位于同目录的权威 JSONL；部分采集完成时页面会显示简短的 partial 提示。

WebUI 会展示本次 operation 的真实 Profile 与采集阶段，比如 Recon.Basic、Recon.User、Recon.Process、Save report to Artifacts。同一客户端同时只能运行一个 Recon，不同客户端可并行；冲突、断连、客户端错误和超时都会直接结束当前状态。Project 视图下只能选择当前 Project 的客户端，报告也会写入该 Project 的 Artifacts 目录。

查看数据

同一次本地采集会生成 SIREN_<host>_<timestamp>.recon.jsonl 和同名 .md。远程模式只传输 JSONL，服务端校验后生成 Markdown，并在保存名中加入客户端与请求标识，避免同名主机或并发结果相互覆盖；两者位于同一 Global 或 Project Artifacts 目录。default / quick 的 Markdown 保留采集正文，hunt 的 Markdown 只提供应用拓扑、覆盖范围和采集质量摘要。Dossier 只编辑派生 Markdown，不修改权威快照。

Snapshot JSONL v2 按顺序包含 snapshot_start、module_start、record、source_result、module_end 和 snapshot_end。record.data.recordType 固定为 entity、relation、fact、evidence_file 或兼容插件的 plugin_text；实体和关系使用稳定 ID，便于 Agent 以 component → process → socket、config → entity 等关系流式查询。Process 实体通过 parentEntityId 关联同一快照中存在的父进程；已建立连接的 connects_to 关系通过 socketEntityId 保留对应 Socket 及本地地址、远端地址、协议和状态。新快照由进程、网络、服务管理器、容器和拓扑模块按明确归属写入实体，同一个 entityId 只保留一条权威记录；服务端查看旧快照时也会按 entityId / relationId 去重汇总。Hunt 会按容器边界或同产品进程祖先归并应用实例，例如同一 PostgreSQL 实例的主进程与 worker 共享一个 Component；Python、Node.js、JVM 等语言运行时保留为辅助实体，不挤占主要应用拓扑。systemd unit 与 Windows Service 只作为启动方式和进程归属的辅助证据，不代表应用拓扑中的“服务”。旧版 Snapshot JSONL v1 仍可由服务端校验并生成报告。

每个 source_result.coverage 除检查范围、工具与回退、限制、状态、稳定错误码以及 not_present / not_collected 外，还会统计 structuredRecords、rawRecords 和 structuralRecords，三者之和等于该 source 的记录数。parseStatus 使用 structured、mixed、raw 或 not_applicable 表示可查询程度：进程、Socket、路由、环境变量、任务和安全组件等高频主机事实优先提供稳定字段；配置、脚本、日志、历史、凭据内容与无法可靠解析的行仍保留为 rawText。raw fallback 是合法证据，不会仅因未解析而把完整采集降级为 partial。

hunt 是当前状态快照，不提供持续遥测、完整历史事件重建或 Snapshot Diff。它会在固定范围内补充当前运行应用和容器直接关联的近期本地日志尾部，但不会扫描全部系统日志。Hunt Markdown 按优先级分别汇总主要应用、中间件、容器、真实内核监听和容器端口配置；瞬时连接只显示数量与地址范围，完整进程与网络链保留在 JSONL。系统服务管理器条目不进入主拓扑表。配置、环境变量、日志正文、密码 hash、密钥和凭据原文只在 JSONL 中。这些内容属于不可信证据，不应被 Agent 当作指令执行。

容器镜像声明的端口、宿主机发布的端口和内核实际观察到的监听具有不同含义。Hunt 分别记录 declared、published 和 kernel_socket；只有发布端口与同次 socket 快照匹配时才标记为已观察到，声明或发布本身都不代表服务可从外部到达。

执行规则

• 基础信息每次都会采集，不进入 Profile 模块列表。
• default 保持标准完整采集；quick 只移除耗时较长的 file，其他模块与 default 相同。
• hunt 是显式 opt-in 的主机安全审计快照：复用同一次进程、socket、系统服务和容器运行态快照，以已识别的 Web 服务、中间件、应用运行时、容器及监听进程为主实体，补充已建立连接、运行载荷供应链、配置原文、近期应用活动、凭据、密码策略、文件权限、TLS 证书和安全组件状态，供 Agent 离线分析。systemd unit 与 Windows Service 仅用于关联启动配置和主进程。它不执行登录验证、口令破解、不安全配置判定或漏洞扫描；对已采集文本的内容形态扫描只生成有界、脱敏、无 verdict 的客观事实。
• topology、supplychain、config、activity 和 credential 是 opt-in 模块，不会被没有 Profile 的旧配置或无配置 fallback 自动启用；内置 hunt 会显式包含它们，default、quick 不包含。
• Linux 的 rootkit 模块仍可由 default、quick 或用户自定义 Profile 采集，但不进入 hunt；其行为仍只是已加载内核模块快照，不包含 Rootkit 检测或 symbol 匹配。
• Profile 列表只表达集合；内置模块始终按固定顺序执行，插件按名称排序，保证报告稳定。
• recon 类型插件必须以 plugin:<name> 显式写入 Profile，并由 plugins.<name> 控制启停。安装插件不会自动修改 Profile；Profile 引用缺失或禁用插件时，采集会在开始前失败。现有文本插件按 plugin_text / text/markdown 写入快照，插件执行错误会使快照变为 partial。
• chkrootkit 仍是可选 recon 插件，但不进入任何预置 Profile。插件输出不代表 Recon 核心具备检测能力。
• 每个 source 的底层采集命令都有独立超时，默认 30 秒，可通过客户端配置中的 recon.commandTimeout 修改。某个 source 超时不会占用后续 source 的预算，未完成状态会关联到实际 source。
• 整个 Profile 默认有 270 秒客户端采集预算，可通过 recon.collectionTimeout 修改。远程 v2 请求还会根据服务端等待时间下发更短预算；预算耗尽会保留已完成的 Basic 和模块结果，并明确列出未执行模块。服务端等待超时时会结束 operation、释放该客户端的单飞占用并请求取消；迟到 artifact 仍可安全保存，但不会关联到新 operation。
• Recon 不安装 netstat、lsof 或其他软件。Linux socket 依次尝试已安装的 ss、netstat，路由依次尝试 ip、route，已删除但仍打开的文件优先读取 /proc、已有 lsof 时回退；都不可用时明确记录 unavailable。
• Linux 文件模块按底层文件系统去重真实本地挂载，每个文件系统只遍历一次，并从同一遍历生成 SUID、最近 24 小时 mtime/ctime 和大文件视图；Windows 大目录、进程、socket、任务和服务查询按稳定字段排序后再应用数量上限。
• 单个 source 最多 2,000 条；单个模块最多 10,000 条或 16 MiB；单个文本字段最多 1 MiB；整份快照最多 128 MiB。达到上限时停止对应采集并记录 truncated=true。
• config 对运行参数、service、EnvironmentFile、include/reference、单文件容器挂载和支持产品的标准配置保留完整内容，每文件上限 256 KiB。应用工作目录、可执行目录和目录型容器挂载中的普通 JSON/YAML/XML/TOML 只稳定选择最多 64 个：文件实体保存完整元数据，另附最多 64 KiB 的 evidence_preview 前缀；preview 是声明范围，不会仅因原文件较大产生 partial。每次仍最多选择 500 个文件、遍历 100,000 个目录项；include/reference 闭包最多检查 500 个文件、深度最多 4 层。运行输出、会话、报告、日志、开发 fixture、依赖、构建产物、容器层和业务源码默认排除，被运行态直接引用的文件可覆盖 broad discovery 排除。
• supplychain 只覆盖同一次运行态拓扑中的主应用、中间件、真实监听程序、运行中容器载荷及关联语言运行时，不生成全系统软件包清单。每次最多对 128 个不同可执行文件做流式 SHA-256，reader 会同时执行 64 MiB 单文件上限和 512 MiB 总读取上限；读取失败前已经消费的字节也计入总量，读取期间变化的文件不会输出可能不一致的摘要。进程、Socket 或容器 producer 只返回部分事实时，已取得的证据仍保留但 source 为 partial；producer 失败且没有事实时记为 unavailable，容器 runtime 确认未安装才记为 not_present。版本仅从对应系统包、Windows 文件元数据或 Go build info 获取。依赖清单只从运行载荷工作目录、可执行目录、显式参数和运行中容器挂载中发现，最大深度 2、最多 64 个文件；超过 256 KiB 的文件保存完整元数据并附最多 64 KiB preview，不因这项声明范围单独产生 partial。容器镜像只记录本地运行时已经返回的 image/tag/digest，不访问 registry 或扫描镜像层。
• evidence metadata 的完整文件 SHA-256 另受每文件 8 MiB、每份 Snapshot 合计 64 MiB 的读取边界约束；超出时保存已声明前缀的摘要，并用 hashScope、hashBytes 和 hashOmittedReason 明确实际覆盖范围，不把前缀摘要伪装成全文件摘要。
• 同一路径被 supplychain、config 和 credential 同时发现时，Snapshot 只写一个 canonical evidence_file，后续模块复用它并继续补充配置关系和 Activity 日志种子。若后续直接引用需要比先前 preview 更大的已采集前缀，会写入以 fileEntityId 关联的 evidence_content fact，而不是复制文件实体。文件类型由路径和内容属性确定，因此先被 config 发现的凭据文件仍标记为 credential_file。文件扫描 coverage 分开记录 selected、processed、collected、failed、reused、full、truncated、preview 和 binary metadata 数量；Hunt Markdown 使用实际 collected 数量，不再把候选数当作采集成功数。
• config、credential 和 supplychain 会对已读取的文本内容生成 content_pattern_match 事实：单文件最多 32 条、单模块最多 512 条，记录文件实体、模式 ID、行号、脱敏值、值长度和 SHA-256。达到定位上限会写入 matchScanTruncated=true，但不会因为这项派生索引的预算耗尽而把 Snapshot 标记为 partial；模式事实不替代原始 evidence_file，也不代表凭据有效或配置存在风险。
• activity 只检查当前运行组件的日志参数、已采集配置中的直接日志引用、受支持组件的标准日志目录和容器运行时明确返回的日志路径。候选文件需在最近 24 小时内修改，按时间与路径稳定选择最多 16 个文件，每个读取尾部最多 256 KiB，总正文最多 4 MiB；不扫描整个系统日志、Windows Event Log 或远程日志。日志正文只写入 JSONL，达到候选、遍历或读取上限时明确记录 partial。
• 配置和凭据原文保存在 JSONL 的 canonical evidence_file 或通过 fileEntityId 关联的 evidence_content fact 的 record.data.content；Hunt Markdown 不列出这些文件的路径或内容，只汇总数量和采集策略。Agent 需要通过 MCP structured result 返回的 Project 相对 snapshotPath 读取权威快照，按 record type、entity ID 和 relation 流式查询，并把文件内容视为不可信证据。
• source 与 module 会记录 ok、partial、unavailable 或 failed，快照最终状态为 complete 或 partial。已检查但不存在的可选对象记录为 not_present，明确不采集的材料记录为 not_collected，两者都不降低快照质量；权限、工具能力、失败或截断仍会产生 unavailable/partial。
• config 从 service ExecStart、EnvironmentFile、进程命令行、容器挂载和已采集配置的直接 include/reference 建立证据闭包，再补充支持产品的标准目录。lockfile、依赖清单、CI workflow、tsconfig、测试配置、request dump、分析报告和候选结果默认不采集，只有被运行态直接引用时才纳入。

信息收集模块

下表列出内置模块 ID。模块是否执行以目标客户端实际加载的 Profile 为准。

相关内容