0 概述

域名系统(Domain Name System, DNS)^[1]伴随互联网而诞生, 主要用于完成从域名到互联网协议(Internet Protocol, IP)地址及其他资源的映射, 是互联网的重要基础设施。域名系统的开放性导致其经常遭受网络攻击, 造成恶劣影响的重大安全事件屡见报端。尽管域名服务机构采取了各种安全防护措施, 但随着网络攻击的不断发展, 各自为战的防御方式逐渐显露出一些不足之处。

区块链具备安全、稳定、去中心化等特点, 为解决分布式网络中的一致性问题提供了新的方法^[2-4]。超级账本是Linux基金会于2015年发起的开源项目, 包含多个并行的子项目, 其中Fabric的成熟度较高, 下文提到的超级账本特指Fabric。与传统的区块链技术相比, Fabric具备无币、高效、隐私保护等特点^[5], 适合于企业级应用。本文提出基于超级账本的DNS协同防御体系, 整合各方资源共同防御网络攻击。

1 域名行业安全问题

域名系统包含权威域名服务系统(简称权威系统)和递归域名服务系统(简称递归系统)两部分, 分别由权威域名服务器(简称权威服务器)和递归域名服务器(简称递归服务器)组成。域名系统常见安全威胁包含拒绝服务攻击和域名劫持攻击^[6-7]。

拒绝服务攻击(DoS/DDoS)指攻击者直接或间接对目标主机发起请求, 大量占用其网络带宽或系统资源, 使其无法响应正常用户的请求^[8-9]。国内外对拒绝服务攻击展开了广泛研究, 相继提出基于流量监控、流量牵引、蜜罐、内容分发网络(Content Delivery Network, CDN)等^[10-12]技术的防御方法, 总体来说可分为两大类, 分别是基于特征的检测清洗和基于备份的服务镜像。

饱和流量攻击指攻击流量超过网络带宽上限的拒绝服务攻击。由于攻击流量和用户查询流量在进入目标服务器前, 已经超过其网络带宽上限, 因此路由系统会随机进行无差别丢包, 导致目标服务器无法接收到正常用户请求。在饱和流量攻击场景下, 对于进入目标系统前就丢失的流量, 传统防御模式难以有效抵御。

域名劫持攻击通过链路劫持、缓存投毒等技术手段, 将目标网站域名解析到伪造的地址, 从而达到域名劫持的目的。针对域名劫持攻击, IETF发布了DNSSEC协议^[13]保障域名数据的完整性。该协议采用中心化结构, 意味着对于任意域名而言, 要保障数据完整性, 需所有父域可信且部署DNSSEC, 而且递归服务器开启了验证。繁琐的依赖条件以及协议本身的复杂性, 制约了DNSSEC的普及。目前, 我国递归系统的DNSSEC支持率不足1%^[14]。在此现状下, 域名劫持事件依然屡见不鲜。

综上, 域名系统存在饱和流量攻击和域名劫持攻击两大安全问题, 当前防御体系难以有效抵御。

2 网络攻击数学建模 2.1 建模目的与原理

域名劫持和饱和流量攻击最终需对用户造成影响, 才能形成实质危害。本节将建立数学模型, 定量分析攻击对用户的影响程度, 为解决相关问题提供理论支撑。

对于域名数据而言, 域名劫持和饱和流量攻击分别破坏其完整性和可用性, 鉴于此, 本文定义了完整率和可用率作为定量描述指标, 如表 1所示。在此基础上, 根据饱和流量攻击和域名劫持攻击的特点, 分别建立网络流量模型和状态迁移模型, 研究影响指标的关键因素, 并指出解决问题的方向。

2.2 饱和流量攻击模型

按照攻击方式, 饱和流量攻击可分为直接攻击和间接攻击, 其中间接攻击包括反射放大攻击和递归代理攻击。上述攻击场景中包括攻击源、用户、攻击目标、路由系统和域名系统多方主体。攻击目标指一台到多台网络服务器。路由系统指转发相关流量的路由器集合。域名系统指转发或放大相关流量的域名服务器集合。

在直接攻击场景中, 攻击源通过路由系统直接发起攻击, 攻击目标为域名服务器。在反射放大攻击场景中, 攻击源通过域名系统放大后进行攻击, 攻击目标可以是权威、递归或应用服务器。在递归代理攻击场景中, 攻击源利用递归系统伪装后进行攻击, 攻击目标为权威服务器。

本文给出以下假设前提:1)攻击目标与路由系统之间的网络链路存在带宽限制, 流量超过其限制时路由系统将随机丢包; 2)其他链路不存在带宽限制, 流量可以自由通过; 3)进入攻击目标的用户请求都可以得到应答; 4)递归系统具备缓存, 缓存命中时直接应答, 未命中时将查询转发给相关权威服务器。依据上述分析和假设, 可对饱和流量攻击进行数学建模。图 1显示了不同场景的网络流量模型。表 2对数学建模过程中用到的符号进行说明。

根据可用率的定义以及上述假设前提可得如下定量关系

$ \left\{\begin{array}{l}{\theta=\frac{r}{q}, u=k q} \\ {r_{\mathrm{A}}=r_{\mathrm{C}}=r^{\prime}, \quad r_{\mathrm{B}}=r_{\mathrm{D}}=q(1-\gamma)+r^{\prime}} \\ {r^{\prime}=q^{\prime \prime}=\frac{\alpha q^{\prime}}{k q^{\prime}+t^{\prime}}, \quad k q^{\prime}+t^{\prime} \geqslant \alpha} \\ {q_{\mathrm{A}}^{\prime}=q_{\mathrm{C}}^{\prime}=q, \quad q_{\mathrm{B}}^{\prime}=q_{\mathrm{D}}^{\prime}=\gamma q} \\ {t_{\mathrm{A}}^{\prime}=t_{\mathrm{B}}^{\prime}=t, \quad t_{\mathrm{C}}^{\prime}=\beta t, \quad t_{\mathrm{D}}^{\prime}=\gamma^{\prime} t}\end{array}\right. $

(1)

根据式(1)可推导出各场景的可用率方程为:

$ \left\{\begin{array}{l}{\theta_{\mathrm{A}}=\frac{\alpha}{u+t}, \quad \alpha \leqslant u+t} \\ {\theta_{\mathrm{B}}=1-\gamma+\frac{\alpha}{\gamma u+t}, \quad \alpha \leqslant \gamma u+t} \\ {\theta_{\mathrm{C}}=\frac{\alpha}{u+\beta t}, \quad \alpha \leqslant u+\beta t} \\ {\theta_{\mathrm{D}}=1-\gamma+\frac{\alpha}{\gamma u+\gamma^{\prime} t}, \quad \alpha \leqslant \gamma u+\gamma^{\prime} t}\end{array}\right. $

(2)

攻击流量t和用户流量u分别受攻击者和用户控制, 可视为常数。显而易见, θ与α正相关, 与β、γ、γ′负相关。因此, 对于饱和流量攻击目标而言, 降低用户查询转发率、攻击流量转发率和反射放大率, 或者增大链路带宽, 是提高服务可用性的关键。

2.3 域名劫持攻击模型

域名服务系统采用分级授权机制对域名进行管理。各级管理机构通过授权记录(NS记录)进行逐级授权, 形成如图 2所示的授权链, 最终实现对叶子域名的授权。域名劫持通常需影响到用户查询的叶子域名, 才能造成实质危害, 因此本节主要研究的是叶子域名劫持攻击。

域名劫持发生于递归服务器外发查询过程中, 攻击者通过伪造或篡改应答报文污染域名数据, 若污染不被检出, 则可达到域名劫持的目的。因此, 域名劫持概率受外发查询概率、污染概率和检出概率的影响。其中, 外发查询概率受递归服务器的缓存大小、置换算法等影响, 污染概率受攻击方式等影响, 检出概率受安全策略等影响。域名劫持攻击可分为直接和间接劫持两类, 其中间接劫持是指以上级域名的授权记录为跳板劫持目标域名记录。

本文给出以下假设前提:1)目标记录具有正常、劫持、授权记录劫持3种状态; 2)目标记录外发查询触发自身污染事件; 3)授权记录污染事件随机发生; 4)污染检出成功使目标记录恢复正常状态; 5)间接劫持仅跳转一次; 6)各事件相互独立。依据上述分析和假设, 可对域名攻击进行数学建模。图 3显示了目标域名的状态迁移模型。表 3对数学建模过程中用到的符号进行说明。

基于完整率的定义以及上述假设前提, 目标域名记录不被直接劫持的概率为:

$ p=1-h \alpha^{\prime}\left(1-\beta^{\prime}\right) $

(3)

目标域名记录不被间接劫持的概率为:

$ {p^\prime } = \prod\limits_{k = 0}^n {\left( {1 - {h_k}\left( {1 - \beta _k^\prime } \right){\alpha ^\prime }\left( {1 - {\beta ^\prime }} \right)} \right)} $

(4)

根据式(3)和式(4)可推导完整率方程如下:

$ \mu = \left( {1 - h{\alpha ^\prime }\left( {1 - {\beta ^\prime }} \right)} \right)\prod\limits_{k = 0}^n {\left( {1 - {h_k}\left( {1 - \beta _k^\prime } \right){\alpha ^\prime }\left( {1 - {\beta ^\prime }} \right)} \right)} $

(5)

污染率h和h_k受攻击者控制, 上级授权记录检出率β′_k受上级管理机构控制, 可视为常数。显而易见, μ与α′负相关, 与β′正相关。因此, 对于域名劫持攻击目标而言, 提高污染检出率或降低外发查询率是保障数据完整性的关键。

3 DNS协同防御体系 3.1 总体架构

通过数学模型可以看出, 在机构遭受域名劫持或饱和流量攻击时, 防御要点通常不在其自身, 影响可用率和完整率的因素涉及权威解析服务机构、互联网服务提供商(ISP)、公共递归服务机构以及应用服务商等多方机构, 但当前相关机构之间并无配套的信任和协同机制。超级账本是许可链, 在继承传统区块链技术去中心化等核心理念的基础上, 针对企业级应用场景, 大幅优化了交易性能, 加强了成员身份管理机制, 并采取通道架构和背书策略提供不同粒度的数据隐私保护机制。本节提出基于超级账本的DNS协同防御体系, 图 4显示了防御体系总体架构, 相关机构组成联盟链通过共享信息和资源, 形成对域名劫持和饱和流量攻击的联合防御。

DNS协同防御体系主要包含边缘解析、流量清洗、服务镜像3层防御策略, 分别从不同的角度针对饱和流量攻击和域名劫持攻击展开防御。表 4显示了各防御策略在区块链上交易的数据, 以及在数学模型中的影响参数。

边缘解析层可防御域名劫持攻击和针对权威的直接饱和流量攻击。权威服务机构通过联盟链发布域名信息, 包括热点域名的记录及由非热点域名构建的布隆过滤器。递归服务系统根据信息直接应答用户查询实现边缘解析, 降低用户流量转发率, 分离攻击流量和用户查询流量。除此之外, 递归服务器可利用域名信息进行污染检出, 同时可以避免相关域名的外发查询, 起到防御域名劫持攻击的作用。

流量清洗层可清洗反射放大攻击流量。域名服务机构或应用服务机构通过联盟链发布服务IP地址信息。域名系统根据信息控制发往相关地址的应答报文流量, 降低反射放大率, 实现攻击流量清洗。需要注意的是, 此场景中递归服务器需保持服务IP地址和外发查询IP地址的分离, 否则将无法接收到正常外发查询的应答。

服务镜像层可防御针对递归的直接饱和流量攻击, 通过整合联盟链中各机构的服务资源建立临时镜像, 动态提升服务能力。一般而言, 运营商本地递归域名服务由于其封闭性, 遭受饱和流量攻击的可能性较低。鉴于此, 本文主要针对公共递归域名服务的安全性展开阐述。公共递归域名服务通过联盟链发布服务IP地址信息, 运营商本地递归服务器根据信息, 通过适当的技术(如BGP)进行牵引流量, 建立公共递归域名服务的本地镜像, 动态扩展服务链路带宽, 抵抗直接饱和流量攻击。

3.2 联盟链模型

DNS协同防御体系的核心是其联盟链, 作为企业级安全防护应用场景, 链上交易的吞吐量及确认时间、交易及数据的机密性都需要着重考虑。Fabric设计的初衷就是企业级应用服务平台^[15-16], 相比其他区块链技术具有更高的交易性能和更加完善的隐私保护机制, 适合域名相关机构之间共享信息并协同防御。本节基于Fabric建立联盟链模型, 如图 5所示。

联盟链模型中的机构包含互联网服务提供商R₁、公共递归服务机构R₂、权威解析服务机构R₃、应用服务商R₄和多边协调委员会R₅。R₅由联盟链中所有机构选举产生, 被授权建立网络, 其成员来自多个机构。

联盟链模型继承Fabric许可链的特点^[17-18], 基于CA和MSP进行成员身份及权限管理, 每个机构都有一个CA, 用于认证管理用户。模型采用多通道进行业务隔离以保障交易及数据隐私, 通过背书策略及排序服务, 共同保障数据一致性及网络效率。目前Fabric支持Solo、Raft和Kafka 3种共识算法, 其中, Solo共识算法只支持单个排序节点, Kafka共识算法尚未实现真正的去中心化。因此, 多边协调委员会成员各自建立排序节点, 并通过Raft共识算法组成O₅, 为联盟链提供排序服务, 实现去中心化与交易性能之间的平衡。

Fabric联盟链可由一到多个联盟组成, 本节围绕协同防御体系定义服务镜像、边缘解析、流量清洗3类联盟模型:1)服务镜像联盟是由递归服务机构与互联网服务提供商组成的一对一联盟, 可有效保障相关业务的隐私性。递归服务机构负责管理联盟, 互联网服务提供商负责提供镜像服务。递归服务机构可与不同的互联网服务提供商建立相互隔离的服务镜像联盟, 防御直接饱和流量攻击; 2)边缘解析联盟是由一个权威服务机构、多个公共递归服务机构及互联网服务提供商组成的一对多联盟, 可保护权威服务机构域名数据的隐私性。权威服务机构负责管理联盟, 其他机构负责边缘解析, 防御域名劫持攻击和针对权威的直接饱和流量攻击; 3)流量清洗联盟由所有机构组成并共同管理, 域名服务机构负责流量清洗, 防御反射放大攻击。由于任一机构都有可能成为反射放大攻击的目标, 且所有域名服务机构都可能成为反射放大的跳板, 因此清洗此类攻击流量需要所有机构共同协作才能实现有效防御。

多边协调委员会R₅通过修改网络配置NC₅, 建立服务镜像联盟(R₁、R₂)、边缘解析联盟(R₁、R₂、R₃)和流量清洗联盟(R₁、R₂、R₃、R₄)。由联盟中的管理机构分别创建服务镜像通道C₁、边缘解析通道C₂和流量清洗通道C₃, 并根据通道配置NC₁、NC₂、NC₃中指定的规则将排队节点以及联盟成员的节点、客户端加入通道, 完成联盟链网络的建立。

机构具有自己的节点和客户端, 节点负责维护账本、执行智能合约、提供背书等事务, 客户端连接机构的域名服务器或应用服务器, 与相关服务器进行数据交互、发起请求协同防御的提案, 并按相关策略控制服务器执行其他机构的协同防御提案。智能合约和账本概念上从属于通道, 物理上在各个节点中存在副本。

3.3 账本及智能合约 3.3.1 账本

账本由状态数据库和区块链两部分组成。区块链即传统意义上不可更改的历史交易日志, 由记账节点负责存储。状态数据库指由历史交易导出的最新全局账本状态, 通道内所有节点同步备份, 使用Key-Value数据库存储以提高检索性能。3类通道对应的账本数据如表 5所示。

边缘解析账本的链上数据为域名信息, 主要包含域名、域名拥有者、指令、热点域名记录和非重点域名记录的布隆过滤器, 其中域名拥有者用于校验相关交易权限, 指令字段用于指示递归系统是否进行边缘解析。流量清洗账本和服务镜像账本的链上数据为IP地址信息, 主要包含IP、IP拥有者和指令。

3.3.2 智能合约

智能合约通过状态数据库对账本进行操作^[19], 为通道中的客户端提供服务。3类通道分别对应边缘解析合约、流量清洗合约和服务镜像合约, 各合约定义相关信息的交易及背书策略。智能合约取得多数通道成员认可后方可在相关通道实例化。

边缘解析智能合约包含创建、删除、更新和查询4项交易, 并按照背书策略规定需取得多数通道成员的背书方可认定交易的有效性。创建交易比较特殊, 需要核实现实世界中域名的权属关系, 本文解决方案是:域名持有机构用超级账本中的私钥对域名进行签名, 通过Base32算法编码生成DNS标准的TXT记录, 并在相应的权威服务器上为域名添加该TXT记录; 在此基础上, 智能合约中的ownership接口通过标准DNS查询取得域名的TXT记录, 利用机构在超级账本中的公钥即可核实域名在现实世界中的权属。流量清洗合约和服务镜像合约定义了相同的交易和背书策略, 不同之处主要是需通过反向域名解析机制核实IP地址的权属关系。由于在创建交易中已经核实了资源的权属关系并记录在账本中, 因此更新和删除交易只需确认提案机构的身份即可。而查询交易对于链上数据而言是只读操作, 不需要额外的验证。状态数据库接口定义为get(读取对象)、put(写入对象)、delete(删除对象), 边缘解析智能合约的伪代码具体如下:

domain contract:

create(name):

if ownership(name)!= proposal.organization:

return null;

domain.name = name;

domain.owner = proposal.organization;

return put(domain);

remove(name):

domain = get(name);

if domain.owner!= proposal.organization:

return null;

return delete(domain);

update(name, order, records, filter):

domain = get(name);

if domain.owner!= proposal.organization:

return null;

domain.order = order;

domain.records = records;

domain.filter = filter;

return put(domain);

query(name):

return get(name);

domain interface:

Transactions:

create, remove, update, query

Endorsement Policy:

OutOf(2, R1, R2, R3)

边缘解析合约的创建交易关键流程如下:1)权威服务机构的客户端生成创建域名交易提案, 并根据背书策略, 通过SDK连接通道内的一半以上的节点并调用智能合约的create交易; 2)背书节点执行该接口并通过ownership接口核实现实世界中域名的权属并为提案签名背书; 3)权威服务机构的客户端集齐背书之后将提案及其背书提交给排序服务; 4)排序服务集中来自相同通道的交易, 根据通道配置验证身份和权限验证后进行排序, 然后打包生成区块并分发给通道中的所有节点; 5)各节点按照智能合约的背书策略验证交易的有效性, 无论交易是否有效, 记账节点都将其写入区块链, 通道内所有节点依据交易的有效性更新其状态数据库; 6)将结果返回给权威服务机构的客户端。

边缘解析合约的删除交易和更新交易流程与创建交易类似。查询交易不涉及修改链上数据, 其交易流程只需两步:1)通道内任意机构的客户端生成查询域名交易提案, 通过SDK连接若干节点并调用query交易; 2)收取节点的回应及其背书。

基于智能合约可实现边缘解析, 联合权威和递归服务机构实现协同防御:1)权威服务机构通过智能合约创建域名; 2)在链上发布并更新热点域名记录信息; 3)递归服务机构的客户端通过查询交易获取信息, 并分发给机构内的递归服务器; 4)递归服务器利用信息实现热点域名的边缘解析。当权威服务机构检测到递归代理攻击时, 可实时通过智能合约进一步加强防御:1)发布由非热点域名构建的布隆过滤器; 2)递归服务机构的客户端获取信息递归服务器更新信息后分发给机构内的递归服务器; 3)递归服务器利用布隆过滤器实现非热点域名的边缘否定应答。

通过边缘解析合约, 在提高权威服务器抵抗饱和流量攻击能力的同时, 降低递归服务器的域名劫持风险。流量清洗及边缘镜像合约基于类似流程, 可以提升相关服务器抵抗反射放大攻击和饱和流量攻击的能力, 本文不再赘述。

4 实验与评估 4.1 可行性评估

域名系统涉及的机构数量庞大, 需要结合实际情况选择联盟成员, 防止网络过于复杂。分析CNNIC公共递归服务器一个月的解析日志, 大多数查询集中在少量域名上, 如表 6所示, 对域名访问近似遵从Zipf分布。我国的权威服务系统超过了10万台套^[20], 但用户查询服务集中在少量主要权威服务系统。CNNIC统计报告显示, 手机网民占90%以上^[21], 手机用户主要通过各大运营商的本地递归服务器进行域名解析。我国递归服务系统超过了10万台套, 而属于主要电信运营商和公共递归服务机构的仅有500余台套。由此可见, 少量的主要权威、递归及应用服务系统覆盖了绝大部分用户, 将这些主要机构组成联盟链防御网络攻击, 即可保障大部分用户的正常域名解析服务。

对于区块链技术, 全球各国态度及监管程度各有不同, 许多国家都已出台了相关法律。在同一地域内建立区块链, 具有相同的法律依据, 易于实施。此外, 同一地域内的用户拥有相同的文化背景, 对域名系统的应用需求相对集中, 便于评估机构的重要性, 选取联盟链的组成主体。

综上所述, 基于Fabric联合区域内主要相关机构构建联盟链, 具有较高的成本效益和可操作性, 能够有效支撑信息共享, 进行协同防御。

4.2 安全性实验与评估

协同防御体系在解决域名行业安全问题的同时也会对现有域名系统产生一定的影响。在数据层面, 联盟链账本成为域名系统一个新的数据源; 在业务层面, 边缘解析、流量清洗和服务镜像也会引入相应的业务逻辑。本节将从数据层面和业务层面展开实验与分析, 从安全角度评估协同防御体系对域名系统的影响。

联盟链账本包含域名信息和IP地址信息两类数据, 相关数据的真实性、完整性和保密性对于域名系统的安全至关重要。在真实性和完整性方面, 智能合约的ownership接口通过现有域名系统的基本服务(域名查询和反向域名查询), 确认域名和IP地址的链外权属, 并通过智能合约附加的背书策略保证相关信息链外权属的真实性, 在此基础上, 进一步通过超级账本的CA和MSP等机制确保链上数据不被伪造或篡改, 从而实现对数据真实性和完整性的全流程保障。在保密性方面, 根据不同应用场景建立的联盟, 利用多通道机制实现联盟之间的隔离, 联盟外成员无法访问联盟内的交易和数据, 能够最大限度地保护相关机构的隐私信息。

对于业务层面而言, 协同防御体系要求域名系统能够支持边缘解析、流量清洗和服务镜像。本文对当前主流DNS开源软件ISC BIND、Unbound、NSD、Knot以及常用的动态路由开源软件Quagga进行测试, 结果如下:

1)主流DNS递归开源软件可以基于转发功能实现域名信息本地化, 在递归服务器上进行边缘解析。

2) 主流DNS开源软件可以通过访问控制列表功能, 在权威服务器和递归服务器上实现基于IP地址的流量清洗。

3) 通过Quagga的BGP牵引功能, 实现递归服务镜像。

实验结果表明, 对于协同防御体系的功能需求, 目前相关主流开源软件都具备成熟的机制。转发、访问控制列表、BGP牵引都是被业界广泛使用并经过长期实验验证的, 在业务层面能够大幅降低引入新安全问题的概率。

综上, 本文提出的协同防御体系能够有效保障数据的真实性、完整性和保密性, 且无需对当前域名系统进行大规模改造, 在数据层面和业务层面都具有较强的安全性。

5 结束语

本文从全局角度研究域名行业的安全问题, 基于超级账本的通道机制和背书策略等, 实现对网络攻击的协同防御。在大数据时代探索区块链技术的行业应用, 对提升网络空间防护能力具有重要作用, 也能为其他领域的研究者提供借鉴。DNS协同防御体系的基础是超级账本, 后续需紧跟相关技术的发展进行不断完善。与此同时, 下一步将结合大规模实际部署需求构建原型系统, 分析并研究本文方案在边缘解析、流量清洗、服务镜像等场景中可能面临的安全问题。