课题研究 域名与DNS安全 · DNS解析安全 子课题05 · 第6页 / 共8页
05DNS解析安全 · 子课题深度研究

DNS异常行为分析

好的检测方法论不等于好的检测能力,工程化是最后一公里。本页给出五类部署点的能力矩阵、两条绑定置信度的规则范式(示意)、拒绝"覆盖度剧场"的L1遥测可见/L2规则覆盖/L3实测验证三层度量模型、时间外推与基线自适应评估纪律、Atomic Red Team原子测试与授权红队双层验证、ATT&CK数据组件对齐表,以及递归路径毫秒级判定预算等性能工程要点。

L1/L2/L3度量Atomic Red TeamRPZ联动时间外推性能工程研究状态:深度研究中
本页焦点部署矩阵、规则范式、三层度量、红队验证
验证基准Atomic Red Team T1071.004 + 授权红队对抗
关键产出规则范式 + 三层覆盖度评估框架

01 · 检测部署位置矩阵

同样的检测逻辑部署在不同位置,可见性与处置能力完全不同。本课题给出五类部署点的能力矩阵:

部署点可见范围优势局限
递归解析器(权威旁路)全网客户端的全部解析请求聚合视角、可联动RPZ直接阻断、天然覆盖IoT哑终端加密DNS下明文可见性下降;内网本地域名不可见
权威DNS侧外部世界对本域的查询观测针对自身的随机子域DDoS、域名仿冒流量看不到内网与外发威胁
终端EDR/代理单主机进程级DNS请求可关联进程与账户,归因精度最高覆盖依赖代理覆盖率;IoT/哑终端缺席
网络NDR/出口旁路流量中的53/DoH会话不依赖终端agent;可见隧道会话形态加密流量内容不可见;旁路丢包影响特征完整性
云解析服务(企业VPC DNS)云工作负载全部解析云上原生集成、日志开箱即用仅覆盖云内;多云视角需自行汇聚

本课题的部署建议:以递归解析器为主检测点(聚合+可处置),EDR为归因点(确认感染主机与进程),NDR为隧道专项补充(会话形态)。三点数据在第5页管线中汇聚,避免任何单点视角的盲区被攻击者利用。

02 · 检测规则范式(示意)

以下为检测逻辑的结构化示意(中性YAML风格伪代码,非可直接部署的特定平台规则),用于说明规则要素与置信度绑定方式;落地时须按实际平台(Sigma/Suricata/自研引擎)语法改写并灰度验证:

规则范式示例①:单主机DGA行为锚点(NXDOMAIN聚合)
title: 疑似DGA感染主机(行为锚点)
scope: 递归解析日志,按(内网源IP, 5分钟窗口)聚合
condition:
  - unique_query_names >= 阈值A        # 唯一查询域名数,阈值按基线自适应
  - nxdomain_ratio >= 0.7               # NXDOMAIN占比
  - avg_domain_entropy >= 阈值B        # 平均字符熵(过滤拼写错误噪声)
  - rcode分布中NOERROR占比 <= 0.3
confidence: C2                           # 仅观测,待特征层复核
action: log + escalate(特征层模型复核)
规则范式示例②:DNS隧道主域候选(比值锚点)
title: 疑似DNS隧道主域(聚合漏斗二级)
scope: 按(主域, 1小时窗口)聚合全部解析日志
condition:
  - unique_subdomains >= 阈值C          # 唯一子域数量爆炸
  - txt_answer_ratio >= 基线均值 + 5σ   # TXT应答占比偏离基线
  - avg_fqdn_length >= 基线均值 + 3σ    # 平均FQDN长度偏离
  - client_asn_diversity <= 阈值D       # 排除公共知名服务域
confidence: C2→C3(时序规律性确认后)
action: RPZ阻断(C3)/ 深包采样复核(C2)

阈值A—D为占位符:严禁跨环境复用固定阈值,标定流程见§03。规则中所有统计量均来自第2—4页特征词汇表,保证规则可解释、可回溯。

03 · 评估方法论:拒绝"覆盖度剧场"

3.1 三层度量模型

参照威胁情报分析专题(姊妹课题)的检测覆盖度方法,本课题将"检测了某类异常"拆分为三层,防止"写了规则=能检测"的自我欺骗:

层级定义验证方式
L1 遥测可见产生该行为的流量能到达检测点并被记录采集覆盖率盘点(盲登记表)+ 回放测试
L2 规则覆盖针对该行为的特征规则存在且逻辑正确静态评审 + 离线样本集回放,输出混淆矩阵
L3 实测验证在授权对抗实验中真实触发并被检出红队/原子测试,记录检测延迟与取证完整性

3.2 时间外推与基线自适应

  • 时间外推评估:训练数据与测试数据按时间切片(如按月滚动),模拟真实"检测明天"场景;随机切分评估结果仅作参考。
  • 基线漂移监控:正常特征分布(唯一域名数、TXT占比、熵均值)按周滚动统计,分布突变(如企业上线新业务)自动触发阈值重标定,而非静默积累误报。
  • 分层验收指标:DGA字符模型以单域名FPR为核心验收指标(递归侧须≤10⁻³量级);行为锚点以"每千主机每日告警数"为运营验收指标;隧道漏斗以"确认隧道/分析工时"为效率指标。

04 · 红队验证与原子测试

检测规则未经对抗验证不得进入生产。本课题采用两层验证:

4.1 原子化测试

MITRE Engenuity社区维护的Atomic Red Team项目为T1071.004提供了默认原子测试用例(公开仓库可查),用nslookup等标准工具向测试域发起已知形态的DNS查询,用于验证"检测链路是否通电"——成本低、可随时回归。本课题建议将DGA/T1071.004相关原子测试纳入检测CI流水线,规则变更必须原子测试全绿方可合并(受控环境执行)。

4.2 授权红队对抗

在年度演练中,由红队在授权范围内复现第3页实验矩阵中的"低慢隧道"与第4页"短TTL轮换"组合手法,检验漏斗完整链路与SOC处置剧本(发现→确认→RPZ→EDR隔离→通报)。红队报告与蓝队检测日志对照分析,产出L3层覆盖度缺口清单,进入下季度规则迭代 backlog。

授权纪律重申:原子测试与红队动作均须书面授权、限定目标域与源段、全程留痕;使用公网测试域(如测试专用域名)而非第三方真实域名。

05 · ATT&CK检测策略对齐

检测覆盖度评估需对齐 MITRE ATT&CK 的检测数据需求。注意:ATT&CK 自 v18(2025年10月)起已用"检测策略(Detection Strategies)+ 分析规则(Analytics)"体系取代旧版 Data Sources / Data Components 体系(v19 于 2026年4月发布),引用时须注明版本。按新体系,与本课题相关的检测目标与所需遥测映射如下:

检测目标ATT&CK技术所需遥测/检测策略(示例)本课题层级
DGA回连检测T1568.002DNS解析遥测、被动DNS历史、递归日志聚合L2—L3
DNS隧道检测T1071.004DNS记录载荷与类型、进程级DNS请求(EDR侧)L1—L3
Fast-Flux识别T1568.001被动DNS解析历史、连接元数据L2—L3
感染主机归因T1071.004进程/命令行日志、EDR事件(进程级遥测)L3(依赖EDR)

ATT&CK 技术条目命名以引用时版本为准(v18/v19 起检测数据需求改由 Detection Strategies 表达);引用时固定版本号与日期。

06 · 性能工程要点

  • 递归路径判定预算:特征模型推理须≤5ms且常驻内存;无法满足的模型(如深度模型)只能部署于异步分析层,同步路径仅用轻量特征。
  • 熵等特征的常数优化:字符熵可用查表法预计算单字符贡献,流式更新滑动窗口,避免每次全串重算。
  • 聚合状态内存控制:"按主域计数"类状态用(count-min sketch + 精确复核双层)控制内存;热主域哈希冲突可接受,告警复核阶段精确重算。
  • 加密DNS背景下的采样:DoH出口日志量巨大,对明确信誉域(知名DoH解析商)可先采样降级,把算力留给未知与可疑目标。

07 · 检测工程常见失败模式与对策

失败模式典型表现对策
阈值一刀切新上线规则误报爆炸,数周后静默失效被关闭阈值一律由本地基线标定(§03.2),灰度期只观测不阻断;标注阈值来源与标定日期
基线污染感染主机流量混入"正常基线",特征漂移不可见基线剔除告警命中域名的查询;基线按网段/终端类型分层,不混用
加密盲区终端绕开企业递归直用公共 DoH,遥测断链受管解析出口 + 对未授权 DoH 出口的阻断/引导策略(与子课题03衔接),登记可见性盲区
告警疲劳漏斗分级失效,C1 低质告警淹没值班告警负荷 KPI(第8页)硬约束;C1 只进分析池不进值班队列;每月复盘告警性价比
规则无回归特征管线升级后旧规则悄悄失效原子测试纳入 CI(§04.1),规则变更必须回放样本集并输出混淆矩阵
归因断链检出恶意域名却无法定位感染主机递归日志须携带内网源 IP 且与 DHCP/IPAM 租约联动;EDR 覆盖度纳入 L1 可见性登记

本节参考来源(第6页)

[1]

MITRE Engenuity Atomic Red Team(T1071.004公开原子测试):github.com/redcanaryco/atomic-red-team

[2]

MITRE ATT&CK 版本更新说明(v18 检测体系变更、v19 2026-04 发布):attack.mitre.org/resources/updates

[3]

Mandiant (Google Cloud)《M-Trends》年度报告系列(检测能力度量与全球驻留时间方法论参照):Google Cloud威胁情报官方博客

[4]

L. Bilge, S. Sen, D. Balzarotti, E. Kirda, C. Kruegel, "EXPOSURE: A Passive DNS Analysis Service to Detect and Report Malicious Domains", ACM TISSEC 16(4), 2014(被动DNS特征工程经典参照,DOI 10.1145/2655620.2655623):ACM数字图书馆

[5]

SigmaHQ通用检测规则项目(规则范式与多平台转换):github.com/SigmaHQ/sigma

[6]

RPZ(Response Policy Zones)技术说明(ISC BIND官方文档):kb.isc.org