3.4 日志侧写：Web、DNS 与代理日志中的痕迹
3.4 日志侧写
本节摘要：不是每个环境都有全流量设备，但几乎每个环境都有日志。本节讲三类最常见日志——Web 访问日志、域名解析日志、代理日志——各自能侧写出什么、字段陷阱在哪、把 3.3 节的工序落到文本日志上要改哪些步骤。
换个问题问：日志里已经有什么
全流量分析是理想态，现实态是"手里只有一堆文本日志"。好消息是：第 2 章讲过的那些机理约束——节律、方向、次序——大多不需要看完整数据包就能观测，它们是元数据层面的存在。一次连接的发生时刻、方向、大小、目的地，在任何一份合格的日志里都有。本节的思路因此不是"教你用新工具"，而是"把旧日志看出新信息"。侧写（profiling）这个词在这里的含义是：不做逐条研判，而是对日志做统计与形状分析，让人读不动的量变成人读得动的形。
Web 访问日志：最普及的观测面
Web 服务器与中间设备的访问日志是最常见的起点。先看一段加了标注的示例：
203.0.113.7 - - [03/Oct/2025:02:11:08 +0800] "GET /wp-content/themes/style.css HTTP/1.1" 200 148 203.0.113.7 - - [03/Oct/2025:02:41:17 +0800] "GET /wp-content/themes/style.css HTTP/1.1" 200 152 203.0.113.7 - - [03/Oct/2025:03:12:02 +0800] "GET /wp-content/uploads/avatar.png HTTP/1.1" 200 310 203.0.113.7 - - [03/Oct/2025:03:39:55 +0800] "GET /wp-content/themes/style.css HTTP/1.1" 200 149
按 3.3 节的工序走一遍。采集层：字段齐全，时刻、来源、路径、状态、大小都有。基线层：这是一个对外的业务站点，它的常态画像应当是"人类浏览"——来源分散、时段集中白天、路径分布符合页面结构。评分层：上列流量的偏差立刻显形——同一来源、等距三十分钟上下、凌晨时段、路径高度重复、响应体大小近乎恒定。四项独立偏差叠在同一来源上，评分不低。值得注意的细节是大小近恒定：真实业务的响应大小随内容波动，取件型请求的应答大小只在"无任务"与"有任务"两档间跳，这个双峰分布是文本日志里也能看见的调度指纹。
侧写 Web 日志的三条要点：其一，按来源与路径组合做聚合统计，单条日志无意义，形状才有意义；其二，状态码分布要进基线——心跳常以两百状态稳定出现，与业务里正常的四零四、三零一混合分布不同；其三，对重复路径的容忍度要按站点类型设定，接口类站点天然高重复，画像必须分站点类型建。
解析日志：小容量通道的显微镜
域名解析日志记录每次查询的名字、来源与时刻。DNS 通道把数据藏在查询名里，于是查询名的统计形态成了关键侧写对象。看对照：
正常业务查询（节选） oa.corp.example.internal A 10:02:11 crm.corp.example.internal A 10:02:14 mail.corp.example.internal A 10:02:20 异常形态（节选） t4k8x2q9.mgmt-updates.example TXT 02:11:08 v7dp3mz1.mgmt-updates.example TXT 02:41:17 q2xw8k4t.mgmt-updates.example TXT 02:41:19
上下两组的差别不需要专家也能看出：上组名字稳定、类型单一、集中在工作时间；下组前缀高随机、记录类型冷门、间隔规律且出现在凌晨。把它工程化，就是三条侧写指标——前缀熵值（随机度）、名字重复率（业务名反复解析，编码名各不相同）、记录类型分布（文本类型查询在多数业务环境占比极低）。再加一条跨域指标：同一来源对单一父域的高频解析，是检验型通道的典型形状。这些指标在解析日志上计算成本极低，却覆盖了 2.3 节讨论过的 DNS 通道的主要形态。
代理日志：出向的关卡台账
在有代理出口的环境里，代理日志兼有前两者的优点——既有完整时刻与目标，又有身份与类别字段。侧写重点转向目的地图谱：把每个出向目标标注类别（业务必需、通用工具、未知），基线建立后，"未知类新目标 + 规律访问"的组合自动进入评分。代理日志还有一项独有馈赠：被拒绝的记录。通道在被封前的尝试、换端口重试、跨协议迁移的痕迹，往往先出现在拒绝日志里——把拒绝日志当一等公民分析，等于提前半步看见对手的试错过程。
三类日志的共同陷阱要专门提醒：时钟。跨设备的时间轴对齐是侧写生命线，秒级偏差足以让"取件—执行—回传"的三段式证据链散架。部署侧写工序前，先做一次全链路时钟审计，比任何分析技巧都优先。
时钟之外还有两个高频数据质量问题。其一是字段截断：日志系统对查询名或路径的长度限制会把长编码名切掉半截——切掉的恰是对侧写最有价值的部分。采集配置里把相关字段的长度上限放开，是侧写项目开工前的必查项。其二是采样与聚合：部分设备默认只记录采样后流量或对重复访问做聚合（只记首次），这对"节律统计"是致命的——间隔数据一旦缺行，走廊检测就失真。审计日志配置时，看到"聚合""采样""去重"字样都要多问一句是否可关。三类问题合起来的教训是：侧写项目的第一个里程碑不是出规则，是出一份日志质量报告——哪些源可用、哪些字段缺、哪些配置要改，这张清单决定后续一切分析的可信度。
最后补一个面向考核的练手方法：拿一段自己环境的真实日志（脱敏后），先不看任何检测规则，徒手做一次 3.3 节的四层工序——列字段、画基线假设、找三个可疑聚合、写出每项的置信度。做完对照现有规则库：你徒手发现而规则库没覆盖的，就是现成的改进项；规则库命中而你没发现的，去读规则学习思路。这个练习一轮只要一个下午，是笔者见过最快的侧写上手路径。
常见疑问
问：日志量太大，统计型侧写跑得动吗？
跑得动。侧写的计算都是聚合级——分组计数、间隔统计、熵值估算，文本日志按天滚动聚合成"来源画像表"后，日常增量分析只面对聚合结果。真正的瓶颈通常不是算力，而是字段质量：缺时刻戳精度、缺来源标识的日志，先修采集再谈分析。
问：演练环境里怎么验证侧写规则的有效性？
用紫队校准：授权演练中让已知通道按剧本运行，侧写规则应当按预期时间产生观测记录；没报的环节就是盲区，误报的环节回改画像。一套侧写工序经过两三轮演练校准后，才能说它对真实威胁有基本的覆盖置信。