1. 引言 —— 为什么「单一设备日志」远远不够 #

在安全日志监控运维中，「某个 IP 地址是否可疑」的判断，通常是基于各设备各自独立的日志做出的。

• FW 扫描多个端口 → 阻断
• Web 服务器收到漏洞扫描 → 告警
• VPN 认证多次失败 → 账户锁定

各设备各自独立判断，这是标准的运维方式。

然而，真实的攻击要有组织得多，是跨越多个层、以协同场景展开的。

例如，假设攻击者按照以下顺序尝试入侵。

1. Reconnaissance via FW (port scan)           ← L1 Network Layer
2. Vulnerability scan on public web port       ← L4 Application Layer
3. Brute force against SSH or VPN              ← L3 Authentication Layer
4. After intrusion, lateral movement in internal network  ← L5 Endpoint Layer

如果各设备分别独立检测，每一起事件都只会显得是「有点可疑的孤立行为」。FW 团队会认为「不过是又一次常规扫描」，Web 服务器团队会认为「不过是又一个扫描器」，VPN 团队会认为「又一次暴力破解尝试」，各自独立应对。

然而，这四个活动实际上是同一名攻击者的一连串连续动作。若将其作为一个连续场景来看，响应优先级、阻断范围与告警等级都会发生巨大变化。

BASTION 的多层相关活动检测，正是一种「以单一 IP 为轴心，将多台设备在时间与层级上的各自检测结果叠加起来」的机制。本文将在不涉及我们专利申请（2026 年）所涉数学公式的前提下，说明其设计理念与机制。

2. 「层」的概念 —— 从五个维度梳理日志 #

BASTION 将日志梳理为以下五个「层」。

这种层级分类并非机械式的设备分类，而是映射到「攻击推进阶段」的分类。L1 对应侦察，L2 对应路径探测，L3 对应认证突破，L4 对应应用漏洞利用，L5 对应内部活动。一般而言，攻击的推进会沿着这些层级向上移动。

「某个攻击 IP 在多个层被同时观测到」这一事实，正是「攻击正在向下一阶段推进」的有力信号。

3. trace-registry —— 按 IP 汇总跨层观测状况 #

在对各设备日志进行分析的过程中，BASTION 会持续累积「该 IP 何时、在哪一层、被观测到多少次」的信息。这被称为 trace-registry。

其结构在概念上大致如下（实际数值为示例）。

{
  "traces": {
    "203.0.113.42": {
      "layers": {
        "L1_network": {
          "first_seen": "2026-05-10T13:01:23+09:00",
          "last_seen":  "2026-05-10T13:42:11+09:00",
          "count": 47,
          "context": ["FW block: port_scan", "FW block: ssh_attempt"]
        },
        "L4_app": {
          "first_seen": "2026-05-10T13:35:08+09:00",
          "last_seen":  "2026-05-10T13:41:55+09:00",
          "count": 12,
          "context": ["webserver 404: vuln_scan", "webserver 403: forbidden_path"]
        }
      },
      "layer_count": 2,
      "total_count": 59
    }
  }
}

这一结构的关键点在于，它是按「层」而非「设备」进行汇总的。若存在多台 FW，它们都会被统一归入 L1 网络层。反之，若同一台服务器同时输出 Apache（L4）与 auditd（L5）日志，则会被视为来自两个层的信号。

此外，各层的观测记录都沿时间轴以能够读出攻击推进过程的粒度被保存下来。

4. 一致性函数 —— 将「跨层协同」量化 #

接下来便进入 BASTION 的核心部分。

仅仅「某个 IP 在多个层被观测到」这一事实，尚不足以构成一次活动（campaign）。它可能同时出现在 L1 与 L4，但这两者也可能只是时间上相互独立、互不相关的行为。

因此，我们定义了一个用数值来评估「跨层协同程度」的函数，称为一致性函数 C(i,t)。

该函数在概念上综合了以下四个要素。

1. 跨层耦合强度 —— 哪些层被同时观测到
2. 时间上的接近程度 —— 观测时机彼此相隔多近
3. 观测量的大小 —— 各层观测到的规模（次数）
4. 时间衰减 —— 越久远的观测，影响力越小

具体的数学形式（跨层耦合矩阵 K_ℓk、衰减率 γ、强度项 Φ 等）因涉及我们的专利申请（2026 年）而不公开，但概念上可表示为如下形式：

C(i,t) = function of "cross-layer coupling × temporal proximity × observation magnitude × temporal decay"

C(i,t) 取 0 到 1 之间的值。数值越大，表示该 IP 的行为「跨层协同」的可能性越高。

5. 活动判定 —— 超过阈值时的自动响应 #

在计算出各 IP 的 C(i,t) 后，超过阈值的 IP 会被判定为「攻击活动（campaign）正在进行中」。

这里的重要设计决策如下：

1. 判定是确定性的：一致性数值是否超过阈值，是机械式判定的，不依赖 LLM 的推理
2. 阈值可按环境调整：默认值是根据内部验证得出的，但可针对客户环境进行精细调整
3. 判定依据可解释：所有输出都会显示「哪些层各被观测到多少次，因此判定为一次活动」的依据

判定依据输出示例（数值已打码）：

[COHERENCE_CAMPAIGN] ip=203.0.113.42  C=███
  L1_network: count=███ first=████ last=████
  L4_app:     count=███ first=████ last=████
  reason: layer_count=2 + coherence > threshold

由于判定依据被明确展示出来，运维人员可以自行确认所观测到的事实，从而在理解的基础上批准自动化防御措施，而不是盲目信任 AI 的黑箱判断。

6. 协同攻击组检测 —— 检测「作为群体的协同行为」 #

到目前为止，我们探讨的是「单个 IP 是否在多个层上表现出协同」。仅凭这一点已经很有威力，但现实中的攻击更加精密。

例如，利用云服务商上的多个 IP 进行的有组织漏洞扫描。每个 IP 单独来看频率都太低，不足以超过活动检测的阈值，但若在整个子网或 ASN 范围内汇总来看，其活动的组织性就一目了然。

因此，BASTION 具备一种「以群体为单位评估 IP」的机制。

• 按子网分组 —— 将同一 /24 网段内的 IP 群组视为一个集合
• 按 ASN 分组 —— 将同一 ASN 内的 IP 群组视为一个集合

针对每个群组，我们会计算群体一致性（GC，Group Coherence）。GC 是将各成员 IP 的一致性数值汇总后，再乘以基于群组规模的增益系数得到的。

具体的数学形式同样不公开，但概念很简单：

GC = Σ C(i,t) × boost(group_size)

由 10 个 IP 组成的群组，比由 3 个 IP 组成的群组更有可能是「有组织的攻击」，因此增益系数会发挥作用。

这一机制被称为群体相关检测（协同攻击组检测）。它以数学方式建模了这样一个理念：「单独来看微不足道的信号，作为群体来看时可能承载着重大意义」。

7. 实际运维检测案例（匿名化处理） #

以下是我们内部生产环境（截至 2026 年 5 月）中，经群体相关检测捕获到的一个群组示例，IP 与组织名称均已打码处理。

[GROUP_CAMPAIGN] type=asn group=AS█████  size=17  GC=███
  Member IPs: ████.██.██.███,  ████.███.██.██,  ███.███.███.███, ... (17 items)
  Observed layers: L1_network (FW block), L4_app (vuln scan)
  Time window: 24 hours
  Action: All 17 IPs auto-blocked across boundary FW + DMZ Agents

这是一个案例：某主要云服务商的 17 个 IP，在 24 小时内跨越 2 个层（FW 扫描与 Web 漏洞扫描）表现出有组织的活动。每个 IP 单独来看，其量级都不足以触发传统 SIEM 的活动检测，但作为一个群体来看，其活动明显表明是有意为之。

检测到后，这 17 个 IP 被同时下发并在边界 FW 与面向公网的服务器端 DMZ Agent 群组中一并阻断（级联防御，详情将另文发布）。

8. 与 SIEM／SOAR 的区别 #

传统 SIEM 或 SOAR 通过编写关联规则，其实也能实现「综合多台设备做出检测判断」。那么区别在哪里？

最大的区别在于「能够检测未知场景」。SIEM 会遗漏未写入规则的攻击。多层相关检测审视的是跨层协同这一普遍性特征，因此能够适应新的攻击手法。

9. 设计上的权衡 #

坦率地说，这一机制也存在若干权衡取舍。

1. 计算成本：随着被观测 IP 数量的增加，为所有 IP 计算 C(i,t) 会增加处理时间。BASTION 通过将计算范围限制在 trace-registry 中记录的近期活跃 IP 上来缓解这一问题。

2. 阈值调整：降低阈值会增加误报，提高阈值则会增加漏报。这与具体环境相关，稳妥的做法是先将阈值设置得偏保守偏高，再根据观察逐步下调。

3. 已知 IP 的漏判：白名单上的 IP（自有服务器、业务伙伴、CDN 等）必须从判定中排除，这通过另一套独立机制进行管理。

4. 大型云 ASN 的特性：AWS 或 Microsoft 等大规模 ASN 中包含大量合法用户。即便群体相关检测显示出较大的群组规模，也不应立即予以阻断，而是通过 CAP（每个群组的最大阻断 IP 数）加以安全约束。

这些问题在设计阶段便已被认识到，并已配备相应的对策。BASTION 的设计原则之一便是「安全包络（safety envelope）」——始终内置在失控情况下能够从物理层面限制损害的机制。

10. 未来发展 #

多层相关检测引擎本身已达到充分的运维成熟度，但仍有改进空间。

• 自适应阈值：通过学习环境的正常水平来自动调整阈值（构想阶段）
• 按时段调整灵敏度：在夜间与工作时间应用不同的灵敏度
• 拓展至其他运维领域：将其应用于安全以外的运维领域（质量、性能）（评估中）
• ASN 信任评分：基于以往行为，为各云服务商的 ASN 计算信任等级

这些将逐步落实。