从告警到攻击链路：关联分析与链路展示工程实践

值班室里最难受的时刻不是告警太少而是屏幕上一天刷过去几千条告警每一条单看都像那么回事凑在一起却完全读不出发生了什么。IDS说某台机器有异常外连终端侧说某个账号在批量试密码日志平台说某台服务器半夜多了个计划任务——三条告警分属三个系统、三个时间点值班的人凭经验觉得好像是一回事但要说清楚这条线是怎么走过来的、下一步可能落在哪就得靠脑子硬拼。关联分析和攻击链路展示这套东西本质上就是在干这件事把散的告警按实体和时间串成一条可读的故事线让研判从猜变成看。这篇东西写给三类人正在做安全运营平台、事件分析模块的研发每天要处理告警、做溯源研判的一线分析人员以及想把自家日志数据真正用起来的运维同学。我会从数据底座怎么搭、关联规则怎么设计、链路怎么画出来、性能怎么扛住这几个角度把整套思路拆开讲中间穿插大量我实际踩过的坑。不追求术语上的漂亮只求你看完能照着做出来并且知道哪些地方最容易翻车。1. 先从一条告警为什么读不出信息说起很多人一上来就问用什么图数据库、用什么可视化库这是典型的从工具出发。我建议先把问题想透链路展示到底要解决什么。想不明白这一层后面选什么工具都是白搭。1.1 单点告警天生缺少上下文一条告警的字段通常长这样时间、源IP、目的IP、规则名、严重级别。这里面缺少的东西太多了——这台机器是谁的、这个账号平时登不登这台机、这个目的地址之前有没有别的机器连过、这条规则命中的行为在整条攻击路径上处于哪个阶段。缺了这些一条高危告警和一个低危告警在研判价值上几乎一样因为你无法判断它是不是链条中的一环。我见过太多团队在告警降噪上死磕调规则、加白名单、做聚合。这些手段有效但天花板很低。因为降噪解决的是少看几条而关联分析解决的是看懂一条。这两件事不是一个维度的问题。当规则工程师把误报压到某个水平之后再压就会大量漏报这时候正确的方向不是继续拧螺丝而是把视角从单条告警抬到一组行为。1.2 关联分析要回答的三个具体问题我把关联分析的目标拆成三问这三问决定了后面所有的数据结构设计。第一问这些告警里哪些属于同一个主体主体可以是资产、可以是账号、可以是人。归错主体后面全错。第二问它们之间的先后顺序和因果关系是什么是A之后才有了B还是A和B只是碰巧落在同一个时间窗里。第三问这条链走到哪一步了还差哪几步这一问把复盘变成了预警价值最高也最难做。这三问对应三类技术实体归一、时序与因果建模、链路补全与阶段推断。很多平台只做了第一类和第二类的一半所以画出来的图永远是一堆散点加几条莫名其妙的连线分析人员看两眼就关掉了。1.3 链路展示的三层抽象点、边、时间轴攻击链路展示在视觉上其实就三个元素但每个元素背后都有讲究。点是实体包括资产、账号、进程、文件、域名、外连地址。边是行为一次登录、一次文件落地、一次网络连接。时间轴是约束它决定了边的方向也决定了你判断因果还是巧合。我特别想强调时间轴这一层。很多团队做链路图做出来是一个无向的力导向图节点之间随便连线看着很唬人实际没法研判。因为攻击是有方向的从入口到横向到外传方向错了整个故事就反了。所以链路图必须带时间轴或者至少带上明确的有向边和步骤序号。这一点在后面第4节讲渲染时会再展开。2. 数据底座实体归一与时间对齐关联分析的质量八成取决于底座。规则写得再花哨数据对不齐出来的链路就是一团毛线。这一节讲的是最枯燥但最不能省的部分。2.1 把日志字段映射成图上的节点和边不同来源的日志字段五花八门但抽象成图之后其实只有两类实体节点和动作边。我在落地时会给每类日志定义一张映射表明确哪些字段是实体、哪些字段是动作属性。以登录日志为例账号是实体源地址是实体目标主机是实体登录成功/失败是边上的属性时间戳是边的属性。这里有个容易忽略的点同一条日志可能生成多条边。比如一条进程启动日志涉及父进程、子进程、可执行文件路径、启动账号这至少是三条边父进程派生、账号执行、进程加载文件。如果你只映射一条边后面想做进程树或者文件落地溯源就断了。我一般要求映射表里对每条日志列出边清单而不是一对一的字段搬运。还有一个原则宁可多存实体不要过早合并。有些团队为了图好看在入库时就把相似实体合并了结果原始信息丢了回头想追查某一次具体登录就找不到。正确的做法是原始事件表和实体表分开存图上展示的是聚合后的视图钻取时能回到底层事件。2.2 实体归一化让同一个东西只有一个名字这是整个项目里最脏最累的活也是决定成败的地方。举几个真实场景。账号名的大小写和域前缀。同一个账号在域控日志里是DOMAIN\zhangsan在应用日志里是zhangsan在某个老系统里是ZhangSan。不做归一这三个会被当成三个不同的实体链路直接断开。主机名的写法。带域名后缀的 FQDN、短名、IP这三种表示同一台机器的情况太常见了。我通常的做法是建一张资产关系表把 IP、短名、FQDN、资产编号都挂到同一个资产ID上所有日志入库前先做一次解析解析不到就落到未知资产池子里定期人工或者自动补充。NAT 和代理带来的地址失真。这个坑最深。内网机器访问外部经过出口设备后源地址变成了出口地址你看到的所有外连日志源IP都一样。如果不提前处理关联结果会告诉你全公司所有机器都是同一台在攻击荒谬但真实发生。解决办法一般是把出口设备的会话日志也接进来通过端口和时间的映射关系还原真实源地址还原不了的就在边上标注经NAT避免误关联。还有一类隐蔽的时间格式与时区。有些设备日志是本地时间不带时区有些是UTC有些是Unix时间戳。全量统一成UTC毫秒级整数存库展示时再转。这个规范不定死后面所有的窗口计算都是错的。2.3 时间窗口和时钟漂移时间对齐不只是格式问题还有漂移。不同设备的时钟差个几十秒到几分钟是常态尤其是虚拟化环境和网络设备。如果你的关联窗口设得很窄比如30秒内检测登录后立刻执行命令那设备之间的时钟漂移就足以让这条规则完全失效。我的处理方式是两层第一层接入侧要求所有设备走统一时间源这是根治第二层在关联引擎里给窗口加一个容忍带也就是窗口时间加上一个可配置的漂移补偿量 δ实际判定区间是 [t1 - δ, t2 δ]。δ 一般设 30 到 120 秒具体看设备情况接入日志质量差的环境可以放到 5 分钟但要接受误关联率上升。这个参数必须在配置里能改别写死在代码里。注意窗口放宽和误关联是直接的权衡关系没有免费的午餐。上线初期建议把窗口调宽先把链路跑通、让分析人员看到价值等实体归一做得更准了再逐步收紧。3. 关联逻辑怎么设计三条腿走路规则设计这部分我见过两种极端一种是全硬编码几百条 if-else 堆在一个服务里改一条规则要发版另一种是妄想搞个通用推理引擎最后做出来一个谁也看不懂的东西。我倾向于中间路线三类关联逻辑分工明确配置化程度按需分级。3.1 时序关联先干什么后干什么时序关联是最基础也最有效的一类逻辑是A 动作之后 T 时间内同一主体发生了 B 动作。典型场景同一账号在一台机器上登录成功后短时间内出现了提权操作同一资产出现异常外连之后紧接着出现大量文件读取。这类规则的关键参数是时间窗口 T而 T 的取值必须有依据不能拍脑袋。我的做法是从历史数据里统计正常情况下的时间间隔分布。比如统计所有登录→第一条命令执行的间隔取 P95 分位作为窗口。如果 P95 是 90 秒窗口设 3 分钟是合理的如果你拍脑袋设 5 秒实际能命中的可能只有不到一半。计算上我用的是按主体分组的滑动窗口。每个主体维护一个近期事件队列新事件进来时往队列里回溯查找满足条件的先行事件找到就把两条边连上。队列长度按时间裁剪不需要无限增长。这个结构简单、可控比复杂的状态机实现起来省心得多。# 按主体分组的滑动窗口关联简化版 from collections import defaultdict, deque import time class SequenceLinker: def __init__(self, window_sec, tolerance_sec): self.window window_sec self.tol tolerance_sec self.buckets defaultdict(deque) # 主体ID - 近期事件 def push(self, subject_id, event): event 形如 {ts: 毫秒, action: ..., id: ...} q self.buckets[subject_id] q.append(event) # 裁剪只保留窗口 容忍带之内的事件 cutoff event[ts] - (self.window self.tol) * 1000 while q and q[0][ts] cutoff: q.popleft() def match(self, subject_id, current, pattern): pattern: 需要回溯查找的先行动作列表例如 [login_fail] 返回命中的先行事件列表边 hits [] for prev in self.buckets[subject_id]: if prev[id] current[id]: continue if prev[action] not in pattern: continue gap current[ts] - prev[ts] # 允许负间隔但不超过容忍带处理时钟漂移 if -self.tol * 1000 gap (self.window self.tol) * 1000: hits.append(prev) return hits这段代码没什么高深技巧但有两个细节值得说一是允许负的间隔并限制在容忍带内用来吃掉时钟漂移二是同一个事件 ID 要跳过避免自己和自己关联。3.2 实体关联谁和谁碰过面第二类是实体关联逻辑是不同主体之间共享了某个实体因此可能有关联。典型的图分析场景一台机器连过的外连地址另一台机器也连过两个账号登录过同一台跳板机两个进程加载过同一个可疑文件。这类关联天然适合图结构用共同邻居数量或者路径长度来衡量关联强度。我给边算权重时一般用这个思路共同实体越稀有关联越可信。所有内网机器都连过的DNS服务器共同邻居数量再多也没意义而一个只被两台机器连过的境外地址就是强信号。落地时我用倒排索引存实体→出现过的主体列表查询时取交集。规模不大的场景几百毫秒就能出结果规模上去了实体上千万、主体上十万就要考虑分片或者预计算这块在第5节讲性能时再展开。3.3 因果与评分传播给链路打分前两类做完你会得到一堆两两相连的边但还没形成链路。要把边串成链需要两个东西方向和分数。方向上我用的规则是边的方向跟随时间同一时刻按语义优先级。语义优先级来自业务常识比如认证行为优先于执行行为执行行为优先于外连行为。这套优先级要落成一张可配置的表不能散在代码里。分数上我用一个衰减加权模型链路的置信度等于各环节置信度的加权和乘上一个随时间间隔衰减的因子。衰减用指数形式decay exp(-λ * Δt)λ 的取值决定多久算太久。如果链路中两个环节间隔一小时衰减后基本就没什么关联价值了间隔10秒几乎不衰减。λ 可以根据业务调整比如横向移动场景 λ 取大一点时间敏感而慢速渗透场景 λ 取小一点可能持续数天。这里有个经验分数不是一个精确的科学指标而是排序工具。不要花大量时间去追求这个链路分数是0.73还是0.75分析人员只关心前20条里有没有真的。分数的作用是把真的排在前面够用就行。3.4 规则优先级与抑制策略规则一多必然出现多条规则同时命中同一个事件的情况。如果不做抑制一条链路会被不同规则反复拼接最后长成一个巨大的、什么都能连上的怪物图。我见过最夸张的一次一个资产关联出了四百多个节点研判价值为零。我的抑制策略分三层。第一层同源抑制同一个底层事件只允许被最高优先级的规则消费一次避免一条事件被多规则重复使用。第二层链路合并如果两条链路共享超过一定比例的节点合并成一条保留分数高的。第三层数量上限单条链路节点数超过阈值比如200就截断只保留权重最高的路径。注意抑制策略一定要留一个全量模式开关给高级用户。研判人员有时候就是需要看没被抑制的原始关联你把路堵死了反而碍事。4. 链路展示的工程实现前面都是算什么这一节讲怎么落和怎么画。我把它拆成流水线、存储、渲染三块。4.1 数据流水线的四段式结构我一般把流水线设计成四段采集接入、标准化、关联计算、视图服务。每段之间用消息队列解耦别图省事做成一个大服务。采集接入负责对接各来源处理协议差异和背压。标准化负责字段映射和实体归一输出统一格式的事件。关联计算是有状态的按主体分片处理每个分片独立维护窗口。视图服务负责把关联结果组织成链路结构并提供查询接口。分片是关键设计。关联计算必须保证同一个主体的事件落在同一个处理实例上否则窗口就断了。我用的分片键是归一化后的主体ID一致性哈希路由。这样扩容时只会迁移一部分主体影响可控。状态存储这块窗口状态放内存加定期快照别每次都落盘性能差十倍。但快照要有重启能恢复否则每次发版所有进行中的关联都丢。4.2 图存储建模与查询存储选型上我倾向于两条腿明细查询走列式或文档型存储图关系查询走图结构存储。不要指望一个存储全包。图建模我用的是最朴素的方式节点表 边表 属性。节点表存实体ID、类型、显示名、风险标签边表存起点、终点、动作类型、时间、原始事件ID、权重。这里有个重要设计边必须能回指原始事件。研判人员点开一条边要能看到对应的原始日志这是信任的基础。丢了这层引用整个链路图就变成一个不可验证的黑盒。查询接口我设计了三个主要能力按时间范围拉取某个主体的链路、按实体展开上下游N跳、按链路ID拿完整路径。N跳查询要限制深度和每跳的分支数不然一个热门实体能给你返回几十万条边。4.3 前端渲染布局、性能和交互渲染这块我吃过不少亏说几个实打实的结论。布局方式决定可读性。力导向布局好看但没用因为节点位置每次都不一样分析人员没法形成空间记忆。我最后用的是分层布局横轴时间、纵轴按实体类型分层账号层、主机层、网络层、文件层节点落格。这样一眼就能看出从账号层下到主机层再横向到另一台主机最后上到网络层外连故事线的方向感非常强。SVG 和 Canvas 要按规模切换。节点数在几百个以内SVG 交互方便、事件绑定简单上千个节点 SVG 就卡了必须切 Canvas。我的做法是阈值 800超过就自动切换渲染后端交互上做一些降级比如取消 hover 高亮改成点击选中。交互上我只保留四个动作点击节点看详情、双击展开N跳、框选高亮子图、时间轴拖拽过滤。功能再多就是给自己找麻烦用户也记不住。4.4 一个能跑起来的最小实现如果你想在一台机器上快速验证思路可以按下面这个最小路径走一遍。数据用自己造的模拟数据不接真实设备。第一步构造一份模拟事件流生成 50 个主体每个主体随机产生 20 到 50 条事件事件类型限定为登录、执行、外连、文件写入四类时间戳随机但保证同一主体内递增。第二步跑前面那段 SequenceLinker把能连上的边输出成边列表。第三步把边列表按主体聚合成链路按节点数排序。第四步用一个静态 HTML 页面把链路画出来——最简单的做法是直接把节点按层和时间算好坐标用绝对定位的 div 画方块和连线不引入任何库也能看。这个最小实现的价值在于它能在半天内让你验证窗口参数取多少合适实体归一做不做得好链路会不会长成怪物。我在正式投入资源之前一定会先做这么一版成本极低能提前暴露八成设计问题。5. 常见问题与排查实录这一节是我从实际运行中攒下来的按问题类型归一下方便你对着查。5.1 误关联链路越串越长最常见的症状是一条链路的节点数持续增长最后几乎把整个内网都连起来了。根因通常是三个。一是公共实体污染。所有机器都连的DNS、所有登录都经过的域控、所有流量都过的代理这些枢纽节点如果参与关联会瞬间把所有东西连成一片。解法是给实体打公共属性标签关联时跳过或者降权。判定公共实体的方法很简单出现频次超过总主体数一定比例比如30%的实体自动标记为公共实体。二是时间窗口过宽。窗口设成一小时那基本就是今天发生过的事都算一条链。窗口必须有依据前面讲的 P95 分位法是可用的。三是规则条件过松。比如同源IP访问这种条件在内网基本没有区分度。规则的条件里至少要有一个稀有维度比如罕见的目的端口、罕见的进程名、罕见的登录时段。5.2 漏关联明明有关联却连不上反过来分析人员说这两件事肯定是一伙的为什么没连上。排查顺序我一般是这样的。先查实体归一。八成问题出在这里。把两边日志的实体字段拉出来对比看是不是同一个东西被表示成了两种写法。我做过统计在一个没做过归一的环境里漏关联中约七成是实体不一致导致的。再查时间。把两条事件的原始时间戳和入库后的时间戳都打出来。有一次排查了半天最后发现某类日志的解析把毫秒当成了秒时间差了三个数量级。最后查抑制策略。是不是被高优先级规则吃掉了或者被数量上限截断了。这个排查起来最烦所以抑制日志一定要记哪条边被哪条规则抑制了要能查。5.3 性能与规模节点上千之后规模上来之后三个地方会先撑不住。关联计算的窗口回溯。如果每个主体的事件量很大比如一台代理服务器的连接日志回溯一遍就是几万次比较。我的优化是给窗口内事件按动作类型建二级索引用字典存动作类型到事件列表的映射回溯时只查目标类型能降一到两个数量级。图查询的N跳展开。热门实体一跳就可能上万条边。必须限流每跳返回边数上限、总节点数上限、超时熔断。宁可返回不完整结果并明确标注也不要让整个页面卡死。前端渲染。这个前面提了800节点切Canvas。另外布局计算要放到 Web Worker 里不然主线程卡住用户以为页面挂了。5.4 问题速查表症状最可能原因排查动作处理方式链路节点数暴涨公共实体参与关联统计实体出现频次标记公共实体并降权/跳过两个明显相关的事件没连上实体写法不一致对比两边原始字段补归一映射规则关联结果随重启消失窗口状态未持久化检查状态存储配置开启定期快照 恢复同一条边被多条规则命中无同源抑制查规则命中日志加同源抑制与优先级页面在大图时假死SVG 渲染瓶颈看节点数是否超阈值切 Canvas、布局移入 Worker时间总是差几个小时时区未统一对比入库与展示时间统一转 UTC 存储外连日志源地址全一样出口地址转换查是否有会话日志接会话日志还原或标注6. 落地过程中我踩过的坑先说一个最反直觉的链路图不是给人看的越多越好。项目刚上线时我们做了一个全量关联视图把所有能连上的都连上结果没有一个人用。后来砍到只展示分数前20条、节点数不超过50的链路使用率反而上去了。研判人员要的是今天有多少条值得看的事不是整个内网的关系网。默认视图一定要收敛展开是用户主动的行为。第二个坑是规则所有权。规则到底该由谁维护研发写规则业务不认业务写规则写出来全是性能灾难。我们最后的做法是把规则拆成两层底层原子关联逻辑时序、实体、评分由研发实现并保证性能上层的规则组合由分析人员用配置界面组装。这样既保住了性能又让业务能自己迭代。分界线画在能不能用配置表达上表达不了的才找研发。第三个坑是效果评估缺失。上线三个月没人能说清楚这套东西到底有没有用。后来我们补了两个指标一是被关联过的事件占比反映覆盖面二是高分数链路的人工确认率反映准确度。这两个数一个看广度一个看精度每周看一次比任何主观感受都可靠。准确率掉了就收窗口覆盖面掉了就补数据源方向很明确。最后一个想说的保存历史链路的价值远超预期。刚开始我们只存当前窗口的关联结果过期的就丢。后来做回溯分析才发现如果有三个月的历史链路复盘一次事件能快十倍。存储成本相比研判人力成本几乎可以忽略。所以我的建议是关联结果落盘保存至少留90天字段上带上生成时间和规则版本方便后续做规则效果对比。链路展示这件事做浅了就是一张花哨的图做深了是把整个安全运营的数据资产盘活。区别就在于你有没有把实体归一、时间对齐、规则可解释这三件苦活做扎实。