加密流量论文复现：《Detecting DNS over HTTPS based data exfiltration》(上)

本文将以我个人的理解去阅读该篇流量加密论文，并在下一篇尽力对其中的实验部分进行复现。话不多说，先从论文开始着手。

内容介绍

传统的DNS(Domain Name System)协议是以明文传输的。DNS作为互联网的基础设施，最初设计时主要考虑的是功能和效率，而没有充分重视安全性问题。传统DNS查询和响应通过UDP或TCP协议传输，数据未经加密，可以被路径上的任何节点查看和记录。

这种明文传输特性带来了几个显著问题：

隐私泄露风险：第三方可以监控用户访问的网站
篡改风险：中间人可修改DNS响应内容
审查风险：政府或ISP可基于DNS查询进行过滤

加上DNS协议是映射域名和IP的重要协议，诸如防火墙之类的安全设施通常不会阻止DNS数据包，这意味着攻击者经常将DNS用作秘密通道，也称为DNS隧道。

以下举个简单的DNS隧道攻击例子：

攻击场景描述：假设某公司内网有一台被入侵的服务器，攻击者试图将敏感文件"secret.txt"(内容为"ABC123")外传到外部控制的服务器。

攻击实施步骤：

域名控制准备：
◦ 攻击者注册域名"evil.com"
◦ 设置该域名的NS记录指向攻击者控制的服务器(如ns1.evil.com)
数据编码传输：
◦ 被入侵主机将文件内容进行Base64编码：“ABC123” → “QUJDMTIz”
◦ 构造特殊子域名查询：“QUJDMTIz.evil.com”
◦ 本地DNS服务器将查询转发至攻击者的NS服务器
数据接收解码：
◦ 攻击者的NS服务器记录下所有查询的子域名
◦ 从"QUJDMTIz.evil.com"中提取"QUJDMTIz"并解码还原为"ABC123"

所以检测DNS隧道吸引了过去十年来吸引研究人员的广泛关注。然而过去的检测通常基于域名的结构，语言和统计特征。这种方法通常基于一个前提，即DNS未被加密。，DNS消息以纯文本传输，允许任何第三方监视DNS流量并获取域信息。

因此，之后衍生出了经过加密的DNS协议，例如DoH(将DNS查询封装在HTTPS中传输)、DoT(在TCP协议上建立TLS加密连接，从而传输DNS协议)，本文的重心放在DoH协议上。DOH的目的是通过加密的HTTPS请求来执行DNS查询和响应，从而阻止了明文DNS查询和响应被第三方窃听或篡改。虽然如此，这也意味着基于DNS的恶意活动可以通过DoH进行加密隐藏(也就是创建DoH隧道输送恶意流量)，这是我们不想看到的，本文的重点便是如何去检测恶意的DoH流量。
对此，研究者希望建立一个有效的分类器，以区分DOH隧道流量和良性DOH流量。为了实现这一功能，需要从加密的DoH流量中提取特征。由于DoH将DNS流量包装在HTTPS中，因此观察到的DoH流可以分为两个阶段:

第一阶段由HTTPS客户端-服务器握手过程生成。
在第二阶段，客户端和服务器互相发送加密的数据包，其中包含DNS查询/响应。

是故可以从这两个阶段提取可以检测DoH隧道流量的特征。

客户端和服务器在握手过程中发送的前几个数据包包含明文信息，该信息可用于识别连接来自哪个应用程序(TLS指纹识别技术)。是故可以根据这些识别得到的应用程序构建白名单，从而初步检测基于TLS指纹的DoH隧道。对于加密流量，统计特征被认为在执行分析方面非常强大。研究者分析了DoH隧道的特点，从包含DNS查询/响应的加密流量中提取基于流的特征，并构建分类器来检测DoH隧道，后续进行详细介绍。

背景介绍

域名解析系统(Domain Name System,DNS)

DNS将易于阅读的域名解析为数字IP地址(例如www.baidu.com对应的ip为 223.109.82.16，但是一般不能直接ip访问，具体原因可查阅此篇博客)。通常，为了解析域名，客户端向递归解析器发送DNS查询。如果递归解析器没有缓存查询的域名，它将从根名称服务器递归地与权威名称服务器通信，直到解析器对用户的查询有权威答案。客户端可以使用解析的IP地址连接到目标主机。递归解析器通常由互联网服务提供商或组织提供，以服务于多个用户。

通过DNS的数据泄露

如果主机连接到万维网，那么防火墙通常被配置为允许将UDP端口53（由DNS使用）上的数据包发送到内部DNS服务器，甚至允许直接将所有数据包发送到UDP端口53上，因为DNS对于几乎所有应用程序来说都是至关重要的服务。因此，DNS是攻击者理想的隐蔽渠道。
DNS隐蔽通道或DNS隧道本质上是对DNS查询中的数据进行编码和封装。具体来说，数据被编码到目标域名的子域名中。为了接收数据，攻击者需要接管目标域名的名称服务器（NS），以便目标域名的所有子域名解析请求最终将到达受控NS。目标域名的子域名（即，编码的信息）在一段时间内（在生存时间内）不会重复，因此循环解析器无法在高速缓存中找到域名。这样，域名查询始终转发到受控NS。受控NS上的工具对查询中封装的信息进行解码，以获得过滤数据。最终，响应被发送回请求主机。具体攻击方式如图上述提到过的简单的DNS隧道攻击例子。

通过DNS的数据泄露

近年来，随着安全性和隐私受到越来越多的关注，安全DNS的多个协议也逐渐得到实施。早期的工作包括DNSSEC和DNSCrypt。DNSSEC在DNS中添加了签名机制来保护DNS的完整性，可以有效防止中间人对DNS的篡改。然而，DNSSEC不提供机密性，即DNS查询仍然是明文的。DNSCrypt由开源社区实施，同时提供完整性和机密性。然而，它没有提交用于标准化的FEC，支持DNSCrypt的应用程序非常有限。
之后出现了DNS over TLS（DoT）。DoT通过传输层安全（TLS）协议加密和包装DNS查询和响应。具体来说，客户端在端口853上与递归解析器建立TLS会话，并通过加密连接传输DNS查询和响应。
随之又出现了DNS over HTTPS（DoH）。DoH将DNS查询和响应封装到HTTP请求的主体中。客户端与递归解析器建立TLS会话，HTTP请求通过HTTP over TLS（HTTPS）协议传输。

与DoT相比，DoH允许将DNS集成到HTTP生态系统中，并且DoH的编程接口更加简单。DoH利用HTTP/2的功能，例如服务器推送机制，使服务器能够抢先推送客户端稍后需要的DNS响应，从而减少延迟。因此研究者相信DoH是加密DNS的主流选择，故在这项工作中重点关注DoH。

HTTPS拦截

传统HTTPS安全检查方法（透明代理的运作原理）

核心机制：

中间设备（如企业防火墙）作为透明代理拦截HTTPS流量：
- 终止客户端的TLS连接
- 用中间件的CA证书解密流量
- 分析明文HTTP内容
- 重新加密并转发到目标服务器
实现条件：

需在客户端设备预装中间件的CA证书，否则会触发证书警告。
存在的问题：
- 部署成本高：
  需大规模部署和管理CA证书（尤其对移动设备/IoT设备困难）。
- 隐私风险：
  中间人可完全查看/修改所有HTTPS流量，违反端到端加密原则。
- 安全降级：
  研究表明，多数HTTPS拦截工具会：
  - 使用弱加密算法（如降低TLS版本）
  - 错误验证证书链（引入中间人攻击漏洞）
  - 缓存敏感数据（增加泄露风险）

研究者的替代方案（仅分析DoH的未加密特征）

放弃解密：
不破解TLS加密内容，避免上述隐私与安全问题。
聚焦未加密特征：
通过以下外部可观测指标检测异常：
- TLS握手特征：客户端指纹（如JA3/JA3S）、协议版本
- 流量模式：数据包时序、大小分布、查询频率
- DNS协议元数据：查询类型（TXT记录滥用）、响应延迟
优势：
- 无需部署CA证书
- 不降低连接安全性
- 符合加密DNS的隐私设计初衷

DNS通过HTTPS的数据泄露

由于第三方无法看到DoH流量，因此将隧道隐藏在DoH中将大大增加攻击者逃避检测的可能性。甚至已经出现了将DoH作为武器的黑客组织。

威胁模型和拟议方法概述

威胁模型

研究者考虑如下图的情形，即攻击者设法危害客户端并使用DoH隧道进行数据泄露。

因此，重点是如何通过受害主机与递归解析器之间的DoH流量来检测DoH隧道。对此，不考虑去解密DoH流量，而是假设DoH流量和非加密DNS流量可以区分，再假设DoH流量和非DoH的HTTPS(标准的HTTPS)流量可以区分(这一点并不难，可以通过简单地观察数据包的IP地址和SSL握手字段中的服务器名称指示（SNI）字段来确定它是否是DoH流量)。上述两种假设并不是本文讨论的重点，而且已经有相关办法可以实现两种区分。最后，假设攻击者可以在DNS协议允许的范围内自由改变DNS查询的包长度，攻击者还可以自由设置DNS查询的包发送率。攻击者不会危害受害者主机上的其他应用程序，例如危害浏览器。

检测方法概述

DoH流的结构和所提出的检测方法如下图所示。

一般而言，DoH流可分为两个阶段。在第一阶段，客户端和递归解析器交换密钥以建立连接，这个过程称为TLS握手。在第二阶段，客户端和递归解析器开始向彼此发送DNS查询/响应。所提出的检测方法受到这样的DoH流结构的启发，该结构包括与DoH流的两个阶段相对应的两个检测步骤。

第一步是基于TLS握手的指纹，客户端一启动连接就可以执行检测该指纹，从而提供潜在DoH隧道的初步警告。
第二步是提取数据传输阶段的基于流的特征，并将这些特征输入到经过训练的分类器中以检测DoH隧道。

具体来说，对于第一个检测步骤，可以使用TLS握手期间的明文信息进行TLS指纹识别。通过测量当前支持DoH的客户端的TLS指纹，发现它们的TLS指纹都是唯一的。这意味着如果攻击者在没有模仿常见的TLS执行器（例如浏览器）的情况下发起隧道连接，那么防御者可以观察到其不同的唯一的TLS指纹。尽管这不是准确的检测，但它可以提供初步警告，特别是可以在握手阶段（数据传输之前）执行的TLS指纹识别。
在TLS握手并建立HTTPS连接后，客户端和递归解析器开始相互发送DNS查询/响应。可以在数据传输阶段提取DoH流的特征并构建分类器。由于流量是加密的，所以只能观察数据包大小和时间戳等特征。经过分析和选择与DoH隧道相关的特征，并通过实验证明，使用这些基于流的特征训练的分类器可以有效地执行检测。

基于TLS指纹的检测

建立TLS连接时，客户端和服务器首先协商建立连接的参数，包括支持的密码套件、证书等，然后生成会话密钥来加密通信数据。此过程称为“TLS握手”。握手的第一步是客户端向服务器发送ClientHello消息，该消息以明文形式发送。

ClientHello消息为服务器提供客户端支持的密码套件和扩展列表。密码套件列表根据客户端的偏好排序，并且每个密码套件定义了一组密码算法，例如，AES-GCM-256。扩展向服务器提供促进扩展功能的附加信息，例如，服务器名称指示是一种扩展，客户端通过它指示其试图连接到哪个主机名。密码套件和扩展的多样性使得TLS具有很大的参数空间，不同的程序通常支持不同的密码套件和扩展。这允许基于ClientHello消息进行TLS指纹识别，该消息已在学术文献中进行了研究，并被开源社区使用。
通过收集TLS指纹来构建数据库，然后将观察到的指纹与数据库中的指纹进行比较。尽管这种仅基于TLS指纹识别恶意软件的方法不够有效，但TLS指纹识别提供了有价值的信息，可以与其他指标结合进行进一步检测。受这一结论的启发，研究者相信DoH连接的TLS指纹识别可能有助于DoH隧道检测。
为了弥补针对DoH客户端的TLS指纹空白，研究者针对三种客户端程序进行了测量：一、浏览器；二、DoH代理程序；三、DoH隧道的概念验证(其实就是能够实现DoH隧道加密的程序)。对于浏览器，选择Chrome和Firefox，这两个是支持DoH的最具代表性的应用程序。由于浏览器以外的应用程序通常还不支持DoH，因此开发了各种DoH代理软件。DoH代理监听和拦截本地非加密DNS查询，并将非加密DNS查询封装到DoH。DoH隧道的概念验证实现了DoH上的数据外流，可以使用特定提供的TLS指纹识别方法进行测量。使用每个DoH客户端通过三个公共递归解析器（Cloudflare、Google、Quad9）启动10个会话并记录指纹。这些应用的详细信息和指纹识别结果见表如下：

在这里插入图片描述

结果表明，测量的DoH客户端都具有不同的TLS指纹。之前的研究指出，客户端对密码套件和扩展的支持与操作系统和编程语言相关（因为通常在开发过程中调用与TLS相关的库）。DoH客户的指纹识别结果符合这一趋势。由不同编程语言实现的客户端具有不同的指纹。同一客户端在不同的操作系统上运行时可能具有不同的指纹。由于实现方法的多样性，使用相同编程语言编写的不同DoH客户端也可能具有不同的指纹。
DoH客户端指纹的唯一性为DoH隧道检测提供了一种简单但有效的初步方法，建立基于TLS指纹的白名单机制。这是因为，与常见的HTTPS不同，DoH连接是由极少数应用程序生成的（因为目前大多数应用程序并不原生支持DoH）。绝大多数DoH连接可能由浏览器生成，少数由DoH代理生成。将浏览器和DoH代理的指纹添加到白名单后，如果其指纹与白名单不匹配，则更有可能是恶意的。

指纹不能直接表明DoH隧道的存在，但为防御者提供了进一步调查的方向。特别是，指纹识别基于DoH的第一个数据包，这意味着在数据传输之前可以进行预警。在实践中，需要收集和更新指纹数据库。由于支持DoH的应用程序数量比支持TLS的应用程序少得多，因此维护DoH指纹数据库的成本相对较低，并且现有的TLS指纹相关工具链可以重复使用。为了逃避基于TLS指纹的检测，攻击者需要模仿流行的TLS实现，例如浏览器。但是由于不同的库支持不同的TLS功能，因此TLS实现可能很难正确模仿。此外，由于良性应用程序（例如浏览器）的指纹会随着版本更新而变化，攻击者知道哪些指纹是模仿的好候选者也是一个负担。总而言之，虽然仅基于TLS指纹的检测可能不够有效，但它可以为管理员提供有效的初步警告，并大大增加成功攻击的难度。

基于流量进行识别

检测的基本思想很简单：从DoH跟踪中提取特征并训练分类器，然后使用训练好的分类器进行检测。遵循这一策略，收集大量的DoH流量（包括良性和隧道流量）来训练和测试模型。

数据收集

为了收集良性和隧道DoH流量，可以采用各种设置来模拟受害者和攻击者之间可能的环境差异。这是因为实际上受害者和攻击者之间的环境是不同的，这可能会影响检测。例如，如果攻击者的服务器在地理上距离受害者较远，那么与良性DNS相比，隧道的DNS查询和响应可能具有较高的延迟，因为良性DNS查询通常由于缓存而直接由递归服务器响应，而隧道的DNS查询必须发送到攻击者的服务器。因此，这种延迟可以用作区分DoH流量是否恶意的特征。下表是不同的环境设置对比：

对于良性和隧道流量，使用2个不同的位置和3个不同的解析器。对于良性流量，可以通过DoH查询1500个网站的DNS记录。对于隧道流量，使用7个不同的时间间隔和227个数据包长度来模拟攻击者可能用来泄露数据的不同设置。
研究者设置了三个虚拟机，运行Ubuntu 20.04作为操作系统。两台虚拟机位于西雅图，另一台位于新加坡。新加坡的一台虚拟机和西雅图的一台虚拟机模拟受害者，位于西雅图的另外一台虚拟机模拟受攻击者控制。所有虚拟机都配置了公共IP地址，并且可以相互通信。对于递归解析器，选择Cloudflare、Google和Quad9，这些都是知名的公共解析器。研究者使用tcpdump捕获虚拟机和递归解析器之间的网络流量，并通过IP地址和端口过滤流量以获得最终的DoH流量跟踪。最终只关注具有应用程序数据的TLS数据包，并过滤没有有效负载的无关紧要的数据包，例如TCPACK数据包。
对于良性DoH流量，通过两个模拟受害者的虚拟机自动访问Alexa Top Sites中排名前1500的网站，并通过三个不同的递归解析器发送DNS请求，从而获得良心DoH流量。
要配置DoH隧道，需要向Godaddy注册一个域，使用西雅图的虚拟机作为该域的名称服务器（NS），并在此虚拟机上运行DNSExfiltrator的服务器端程序（即，此虚拟机被模拟为由攻击者控制）。另外两个虚拟机被模拟为受害者，运行DNSExfiltrator的客户端程序，并使用三个不同的递归解析器通过DoH隧道将本地文件（使用文本文件）发送到攻击者控制的服务器。每次通过DoH隧道执行数据泄露时，设置不同的DNS查询时间间隔或不同的完整域名长度。研究者将每一组执行三次并收集交通痕迹。具体来说，两个查询之间的时间间隔是随机的。DoH流的总体平均时间间隔约为1、5、10、20、100、500、1000 ms（总共7个时间间隔设置）。完整域名的长度范围从27到253（总共227个数据包长度设置）。每个DoH隧道流至少包含5组DNS查询和响应。

特征

DoH流量跟踪可以被认为是数据包的时间序列。由于DoH流量加密，只有大小、时间戳和方向对检测有用（目的端口（通常为443）是一个常数，目的IP地址属于递归解析器）。对于当前考虑的场景，DoH流可以被定义为客户端和递归服务器之间通过特定端口通过HTTPS传输的流量流。具体来说，可以将客户端表示为源，将递归服务器表示为目的地。从源发送到目的地的数据包是DNS查询，反之亦然。研究者将DoH流量跟踪重新组装到流中，并根据每个流的包大小、时间戳和方向提取流级统计特征。特别是，计算每个流量水平特征的最小、最大、平均值、标准差。特征值是小数，可以直接由机器学习模型消耗。受到之前关于DNS隧道和加密流量的工作的启发，可以结合DoH的特征来选择功能。下表列出了使用的所有功能，下面给出了每个功能的详细信息和理论分析，后面还会证明本文中选择的特征足以用于DoH隧道检测。

在这里插入图片描述

TLS记录长度

查询域名的长度在以前的工作中被用作检测DNS隧道的重要特征，这是因为通过DNS进行的数据泄漏本质上是将数据编码为子域字符串，并使用该字符串和高级域名构造查询的域名。隧道应用程序发出解析该域名的请求，然后由攻击者控制的NS将接收该请求并通过解码子域字符串来获取信息。因此，较长的域名有助于传输更多的数据
然而在加密DNS场景下，无法直接观测查询域名的长度，因此可以转而关注DoH数据包的TLS记录长度，该指标可在一定程度上间接反映域名长度特征。由于DNS查询/响应存在长度限制（域名总长度不超过255字节），即使被封装在HTTP请求中，大多数情况下仍能完整容纳于单个TLS记录内。
TLS中的加密套件可分为流加密（如ChaCha20）和分组加密（如AES）两类。对于流加密算法，其按字节加密的特性使得密文长度与明文长度相等；而分组加密算法需要对固定长度的数据块进行加密，末端数据可能需要填充以满足分组整数倍要求。虽然密文与明文长度可能不完全一致，但二者仍保持正相关关系。总体而言，当DNS查询未进行填充处理时，我们仍可通过TLS记录长度间接推断域名长度特征。具体而言，考虑以下三类TLS记录长度特征：

查询方向的TLS记录长度（src2dst）
响应方向的TLS记录长度（dst2src）
流中所有数据包的TLS记录长度（bidirectional）

时间间隔

数据包之间的时间间隔是检测DNS隧道的常见特征。递归解析器通常会缓存有关之前DNS查找的信息以减少延迟。当DNS响应包括生存时间（TLR）值时，接收的递归解析器将在TLR指定的时间内缓存该记录。然后，如果递归解析器在到期时间之前收到查询，它只需回复已经缓存的记录，而不是再次从权威DNS服务器检索。相反，递归解析器无法在缓存中找到DNS隧道生成的域名，因此接收到的每个查询都被转发到由攻击者控制的NS。相应的响应将从NS返回，而不是直接从递归解析器的缓存返回。是故，隧道流量的查询和响应的相邻对之间的时间间隔通常比正常DNS流量的时间间隔长。此外，正常的DNS流量通常是随机的，而通过DNS传输数据时，DNS请求通常以相对稳定的速率发送。幸运的是，与时间相关的特征的提取不受加密的影响。一般来说，考虑相邻的查询和响应对之间的时间间隔（双向），以及两个连续查询（SRC 2dst）和两个连续响应（dst 2SRC）之间的时间间隔。

被舍弃的特征分析

不同查询生成的DoH流量（如访问不同网站产生的DoH查询）可能在累计字节数或持续时间上存在差异。从直觉上看，基于流量的累计字节数或持续时间进行区分似乎是可行的。先前关于加密DNS流量的研究曾使用过此类特征。例如，有文献利用流持续时间作为区分DoH流量与非加密DNS流量的特征之一；还有文献将流中查询/响应的总数和累计字节数作为网站指纹特征。
对于用于数据外泄的DoH隧道而言，理论上其产生的字节数会多于正常流量。这是否意味着累计字节数和流持续时间可以作为检测DoH隧道的有效特征？答案是否定的。因为先前研究使用这些特征时隐含了一个重要前提：即假设每个DoH流仅包含用户单次操作（如一次网站访问）产生的查询/响应，因此不同DoH流会呈现不同的累计特征。然而实际情况是，浏览器可能同时访问多个网站，此时产生的查询/响应可能集中在单个DoH流中，这意味着正常DoH流同样可能具有较大的累计字节数或持续时间。基于此，本研究最终未采用此类特征。

简单来说：

研究人员原本考虑用"总流量大小"和"持续时间"来检测恶意流量，但后来发现这些指标不太靠谱，就像用"快递包裹的总重量"来判断是不是违禁品一样——正常快递也可能很重。

详细解释：

最初的想法：

假设：恶意软件用DoH隧道传数据时，会产生比正常浏览更多的流量（就像小偷用货车运赃物，比普通人网购的包裹多）
前人研究确实用过"流量总字节数"和"连接持续时间"这类特征（好比快递站记录每个客户的月包裹总重量）

发现问题：

这个假设有个漏洞：正常用户也可能同时开很多网页（比如你一边看视频一边刷微博），这时产生的DoH流量也会很大
就像快递站发现：有些正常客户（比如开网店的）每月包裹量可能比小偷还多

关键矛盾：

恶意软件传数据往往持续发送小包裹（比如每分钟发10个小DNS查询）
正常用户可能突然产生大流量（比如打开视频网站）
两者在"总量"上可能重叠，就像小偷的货车和网店老板的货车可能装得一样满

最终决定：

放弃这些容易混淆的特征（就像快递站不再单纯靠包裹重量抓小偷）
改用更精准的特征组合（比如同时检查"发送频率+包裹大小规律性"等）

模型的选择

与其他领域中提取高维特征的一些工作不同，由于加密，可以从DoH流量中提取的特征的数量是有限的。因此，不需要构建复杂的分类器甚至神经网络。相反，如果简单的分类器有效，它可以带来可接受的工程成本。
此外，神经网络的可解释性可能不够。在网络安全领域，可解释性可以帮助防御者分析安全事件并采取更适当的策略。是故，选择了三种可解释的监督模型：增强决策树（DT）、随机森林（RF）和逻辑回归（LR）。研究者在实验中基于模型的可解释性进行了大量分析。特别是，实验包括对抗性考虑，并证明模型的可解释性可以帮助在攻击者逃避检测时确定DoH流的优先级（越像隧道流量的优先级越高），从而为防御者提供攻击调查的有用信息。
研究者没有选择特定的模型，而是在所有实验中采用了这三个模型。从初步结果来看，发现RF和DT在大多数情况下表现更好。然而，LR作为线性模型，发现在根据LR的分数对DoH流进行优先级排序方面具有独特的优势。
此外，与仅使用良性流量进行训练的异常检测模型相比，同时使用良性和恶意流量训练模型的监督学习方法通常具有更高的准确性，因为该模型可以直接匹配两种类型数据的决策边界。但显然，所需的标记恶意流量数据增加了模型训练的难度和工作量。研究者收集的恶意流量很简单，由具有基本配置的开源工具生成（如之前所述）。在下一部分中，将评估训练模型对于试图逃避检测的更高级攻击者的有效性，从而用实验证明，在良性流量和简单恶意流量上训练的模型在大多数情况下仍然可以有效对抗高级攻击者（最多需要对模型进行一些细微的调整）。这意味着只需使用简单、易于收集的恶意流量来训练模型，而不是收集高级攻击者可能使用的恶意流量。因此，数据收集的难度大大降低，提高了该种方法的实用性。

基于流量的检测评估

评估设置

对于基于流量的检测评估，可以将数据集按照4:1的比例划分为训练集和测试集。研究者采用5重交叉验证来训练模型，并选择在验证集上F1分数最高的模型（阈值为0.5）进行测试。使用的测试指标包括准确率（accuracy）、精确率（precision）、召回率（recall）和F1分数（F1-score）。

5重交叉验证的工作原理：

数据分割：将原始数据集随机分成5个大小相等（或近似相等）的子集，称为"重"（folds）
迭代训练与验证：

每次使用其中4个折（80%数据）作为训练集
剩下的1个折（20%数据）作为验证集
这个过程重复5次，确保每个子集都被用作验证集一次

性能评估：最后将5次验证的结果进行平均，得到模型的整体性能评估

阈值0.5的工作原理：

在二分类问题中，分类器通常会输出一个0到1之间的概率值，表示样本属于正类（本文中指良性DoH流量）的概率。阈值0.5的含义是：

决策边界：

当模型输出的概率 ≥ 0.5时，样本被分类为正类（良性）
当模型输出的概率 < 0.5时，样本被分类为负类（恶意/隧道流量）

在本文中的应用：

研究人员选择在验证集上F1分数最高的模型时使用0.5作为默认阈值
这个阈值是二分类问题中最常用的默认值
它表示对正负类采取对称的重视程度

可调整性：

在实际应用中，可以根据具体需求调整这个阈值
例如，如果更重视检测率（召回率），可以降低阈值
如果更重视准确率，可以提高阈值

具体而言，当一个流量被标记为良性时，我们称之为阳性（positive）。真阳性（true-positive, TP）是指被正确标记为良性的DoH流量，假阳性（false-positive, FP）是指被错误标记为良性的DoH隧道流量。相反，真阴性（true-negative, TN）是指被正确标记为恶性的DoH隧道流量，假阴性（false-negative, FN）是指被错误标记为恶性的良性DoH流量。基于这些定义，我们可以计算以下指标：
$\frac{TP + TN}{TP + FN + FP + TN}$
$\frac{TP}{TP + FP}$
$\frac{TP}{TP + FN}$
$×\frac{精确率 × 召回率}{精确率 + 召回率}$
研究者评估考虑了不同场景下的多种因素变化，包括地理位置、DoH递归解析器选择、填充方式等，以评估这些因素对模型性能的影响。为此，设计了一系列异构实验。在每个实验中，只改变一个因素（如位置或递归解析器）来评估分类器的性能，并讨论攻击者可能的规避检测方法。
具体来说，首先使用所有训练数据和特征来训练和测试模型，这是一个理想场景，展示了模型性能的上限。然后测试位置、DoH递归解析器、填充和时间间隔对模型性能的影响。此外，还模拟了攻击者可能规避检测的场景。研究者发现攻击者要实现这种规避非常困难（甚至仅在理论上可行），此时隧道的传输速率极低。更重要的是，在这种情况下，该方法仍然可以帮助管理员更快地调查安全状态。

总体数据集的评估

首先进行一个简单的实验来初步测试分类器的性能，将所有收集的数据组合到一个总体数据集中，分类器使用所有特征（总共24个特征，请参阅前面的表格）进行训练和测试。这种实验性设置意味着不考虑不同位置和递归服务器的可能影响，并假设攻击者没有采取措施来逃避检测。

实验结果总结于上表中。LR存在一些假阳性，因此其F1评分相对较低，为0.978。尽管该实验设置是在上述理想化场景中进行的，但实验结果可以证明DoH隧道流量与正常DoH流量不同，并且提取的特征可以表达这种差异以构建高效的分类器。
在上述分类器中，尤其是RF和DT，在这个实验中表现出色。这是否意味着DoH隧道可以被有效检测到？答案当然不是。事实上，攻击者可以轻松改变流的一些特征值，例如数据包发送率。理论上，攻击者可能会逃避检测。面对实际对手时，需要考虑检测方法的稳健性。
因此，除了模型本身的有效性之外，应该更关心攻击者如何逃避检测。换句话说，我们希望找到所提出方法检测能力的下限，而不仅仅是模型在理想化数据集上的性能。如果攻击者需要支付极高的成本（甚至仅在理论上可行）来规避所提出的方法，则所提出的方法对于DoH隧道检测是有效的。在随后的实验中，研究者从攻击者和防御者的角度分析了所提出的方法。通过改变一个因素（例如，位置或递归解析器），以评估分类器的性能，并讨论攻击者逃避检测的可能方法。

位置的影响

DoH痕迹可能因地点而异。对于良性DNS查询，因为网站可能会将其内容调整到特定的地理区域，并且解析器缓存的资源可能会因不同的区域而异。对于DoH隧道，通过隧道的查询将不可避免地到达攻击者控制的NS。因此，直观地说，通过隧道将数据从不同位置传输到同一NS所需的时间是不同的。

在这个实验中，通过在不同位置收集的数据集进行交叉验证。受害者分别位于新加坡和西雅图，攻击者控制的NS位于西雅图。在新加坡收集的良性DoH跟踪和DoH隧道跟踪形成一个数据集，而另一个在西雅图。这两个数据集分别作为训练集和测试集进行验证。

下表显示了交叉这些数据集进行训练和测试时的分类器性能。

当在同一位置进行训练和测试时，分类器的结果与整个数据集中的结果相似，一些F1分数甚至增加了约0.1%。当在不同地点进行训练和测试时，F1分数会下降4%至26%。下降主要发生在对新加坡收集的数据集的训练和对西雅图收集的数据集的测试中。RF的性能优于DT和LR。具体来说，研究者发现F1评分低的主要原因是大量假阳性，但假阴性并不多。例如，当LR的F1得分为0.726时，精度为0.585，召回率为0.958。当DT的F1评分为0.759时，精确度为0.611，召回率为0.999。

出现上述这一结果的原因是时间相关特征在分类器中具有更高的重要性，而不同地理位置生成的DoH流量轨迹的时间相关特征存在差异。在实验设置中，从新加坡的受害者向西雅图的NS服务器传输数据包需要较长时间，而在西雅图本地只需很短时间。因此，基于新加坡收集数据训练的分类器，其针对时间相关特征的决策边界不完全适用于西雅图收集的数据。反之，基于西雅图收集数据训练的分类器具有更严格的决策边界，因此在新加坡收集的数据上仍表现良好。
较好解释：
在西雅图训练的模型当中，一部分是使用DoH隧道访问西雅图的NS服务器，另一部分是用DoH去访问正常的网站，而访问正常的网站通常会被引导到最近的服务节点，所以上述二者的传输时间没有非常大的差别。因此，模型在构建的时候，重点会考虑除了时间以外的特征(不是说不考虑时间特征，只是权重小一点)。而对于在新加坡训练的模型来说，由于攻击者的NS服务器是在西雅图，所以传输时间往往较长，这和自己本地DoH访问正常网站产生的流量在时间上有着很大的差别，导致模型误以为时间过长的就是恶意流量，所以最后在西雅图的数据集上表现非常差。

对于良性DoH流量，解析器通常会缓存热门资源，且解析器和CDN会使用地理位置方法来实现请求的负载均衡（例如访问同一个网站，会被引导访问最近的一个服务节点）。因此良性DoH轨迹在不同位置变化不大，交叉验证的召回率没有显著下降。至于模型的性能表现，研究者认为RF能保持相对较好效果的原因是其多数表决机制降低了时间相关特征的影响，且TLS记录长度相关特征对检测有所帮助。

根据本实验结果，对防御者而言，需要使用本地训练的分类器来确保有效性。对攻击者而言，需要使受控的NS服务器尽可能在地理位置上接近受害者，从而减少从受害者到NS服务器的DoH隧道延迟。然而，仅靠地理位置的接近并不足以逃避检测（在同一位置训练和测试模型时仍可获得较高的F1分数）。

DoH递归分解器的影响

研究者基于三个公共递归解析器（Cloudflare、Google、Quad9）收集数据，这些数据分别作为训练集和测试集进行验证。由于篇幅限制，下表仅展示了西雅图主机使用随机森林（RF）模型获得的部分F1分数结果。基于决策树（DT）和逻辑回归（LR）模型的结果与下表相似（差异在5%以内）。新加坡主机的测试结果也与下表相似（差异在3%以内）。

总体而言，使用相同解析器数据进行训练和测试时获得最佳结果，这符合预期。在其他情况下，模型性能会出现下降。具体表现为：基于Cloudflare数据集训练的模型在Google和Quad9数据集上仍能保持相对良好的效果（F1分数下降1.6%-3.7%）。而基于Google或Quad9数据集训练的模型在其他数据集上的F1分数会显著下降25%-44%。

为探究这种不对称的性能下降现象，研究者根据特征重要性对分类器进行了排序分析。下图展示了西雅图主机使用不同解析器数据集训练随机森林模型时的归一化特征重要性（由于篇幅限制，仅展示前6个重要特征）。发现，Cloudflare数据集中的重要特征在Google和Quad9数据集中同样重要（如bidirectional_mean_length）。而Google或Quad9数据集中的某些重要特征（如dst2src_min_time是Quad9数据集中最重要的特征）在其他数据集中并不突出（在Google数据集的前6重要特征中未出现）。这种特征重要性分布的差异可能是由于不同解析器的实现方式和部署策略不同所导致，例如在解析域名时采用不同的缓存策略会导致响应时间特征的差异。特征重要性的差异可能导致决策树在早期分裂时产生错误划分，从而引起性能下降。

在这里插入图片描述

根据这些实验结果，防御者应当收集来自不同递归解析器的数据进行训练。对于攻击者而言，则需要了解不同解析器的特性差异，并尝试利用这些差异来规避检测。

EDNS(0)填充的影响

之前的实验模拟了攻击者试图通过改变受控NS的地理位置和递归解析器来逃避检测的情况，结果表明这些变化不足以逃避检测。从攻击者的角度来看，有必要从分类器的特征中找到可能的逃避方法。一般来说，分类器的特征由两种类型组成：与TLS记录长度相关的特征和与时间相关的特征。在本实验中，研究者评估了TLS记录长度对检测的影响。

显然，逃避检测的基本思想是使TLS记录长度与良性DoH数据包的记录长度相似。如果攻击者仅调整域名的长度和编码信息的长度，则不容易确定最佳长度值来逃避检测。如前所述，我们希望找到所提出方法的检测能力的下限。因此，我们假设对攻击者最有利的场景，即良性DoH流量和DoH隧道流量都使用EDNS(0)填充选项进行了完美填充。

DNS扩展机制(EDNS)是一种增加DNS功能的规范[39]。EDNS(0)填充用于将DNS查询和响应填充到所需的大小，这使得基于数据包长度的流量分析更加困难。预计填充将与DoH一起使用以更好地保护隐私。在严格的填充策略下，所有DoH数据包都具有固定长度。因此，在本假设场景中，所有与TLS记录长度相关的特征都无效。在本实验中，评估了仅基于时间相关特征的分类器的性能。分类器分别使用整体数据集、西雅图和新加坡数据集进行训练和测试。实验结果总结在下表中。与之前的实验相比，所有分类器的性能都有所下降。LR模型的F1分数下降了13%。相比之下，RF和DT的性能下降较小，F1分数下降了约1%。

这一实验结果表明，虽然与TLS记录长度相关的特征确实会影响检测结果，但分类器仍能保持可接受的性能。此外，最近的工作指出，目前支持填充的客户端并不多，而且填充的实现还不够标准化。这意味着在当前的现实世界中，攻击者不太可能具备假设的理想条件。总之，防御者应该**仅基于时间相关特征训练分类器**，以检测潜在的基于填充的逃避，而攻击者仅通过修改TLS记录长度很难逃避检测。

时间间隔的影响

根据上述实验结果，攻击者只能基于时间相关特征寻找可能的规避检测方法。在本实验中，研究者假设攻击者已经使用了前一实验中描述的EDNS(0)填充选项，在此基础上攻击者进一步调整DoH隧道的时间相关特征以规避检测。做出这一假设的原因是，虽然单独使用填充不足以规避检测，但它确实降低了分类器的性能。因此，在使用填充的同时修改时间相关特征是对攻击者最有利的场景。

直观来看，当DoH隧道的数据传输速率较慢时，其伪装效果可能更好。目前使用的DoH隧道数据集中最大的DNS查询发送间隔为1秒。在本实验中，进一步收集了时间间隔为2、4、8和20秒的DoH隧道流量（这些是流上的平均时间间隔，两个查询之间的时间间隔是随机的）。流量在位于西雅图的主机上收集，每个DoH流至少包含5组DNS查询/响应。

对于实验，首先使用先前训练的模型来检测新收集的数据下表显示了每个分类器对不同发送间隔的DoH隧道流的平均预测概率。结果显示，RF和DT仍然能准确检测所有发送速率的DoH隧道（F1-score>0.99），而LR仅能检测发送间隔为2秒的DoH隧道（当间隔为2秒时F1-score约为0.92，其余间隔的DoH隧道流被分类为良性）。相比之下，RF和DT对DoH隧道流的预测概率在前面的实验中通常超过0.9。因此，虽然增加发送DNS查询的时间间隔不会导致这些分类器出现假阳性，但它确实有助于规避检测。DT的预测概率是一致的。这表明当DT检测具有不同发送间隔的流时，它可能已经到达相同的内部节点（即一个特征和决策条件），然后将流分类为DoH隧道。这进一步表明攻击者需要调整其他特征来规避检测。对于LR，作为一个线性模型，时间间隔的增加直接导致其对DoH隧道流的预测概率下降，从而导致假阳性。

然后使用新数据与之前的数据一起重新训练和测试模型。RF和DT获得的结果几乎与上表中的结果相同。LR却实现了0.909的精确度，0.956的召回率和0.932的F1-score。与仅检测发送间隔为2秒的DoH隧道相比，重新训练的LR模型的性能有了很大提高。每个分类器的精确度没有显著下降，这意味着在添加新数据进行训练后，分类器仍然可以找到一个清晰的决策边界。上述结果表明，防御者应尽可能多地收集多种速率的DoH隧道流量来训练模型。即使攻击者使用比训练集更慢的速率，模型仍然可能有效。

对检测到的流进行优先级排序

攻击者可以调整很少的剩余参数来逃避检测。由于收集的DoH隧道流包含多个DNS查询，因此研究者最后考虑DoH隧道流仅包含一个DNS查询的场景。直觉上，这样的设置可能会使与时间相关的特征的某些统计数据（例如，平均值、标准差）无效。与前面的实验过程相同，使用训练模型和重新训练模型来测试新收集的流量。发现此时没有一个模型可以检测到隧道。看来攻击者终于有办法逃避检测了。由于一个流只包含一个DNS查询/响应，因此建立的DoH隧道的传输率非常低。具体来说，假设子域名的长度为100（对于DNS来说这并不是一个很短的长度）并且采用base64编码，那么每个查询可以传输大约75个字节。每个新DoH连接的TLS握手都需要一些时间（取决于网络环境和计算能力）。因此，即使两个连接之间几乎没有间隔，隧道的总体速率也只有每秒数百个字节左右。

然而，研究者发现在之前的实验中表现相对较差的LR此时可以帮助防御者。当查看LR的分数时，发现尽管DoH隧道流的分数大于0.5（DoH隧道流为0，良性DoH为1，阈值0.5），但DoH隧道流的分数通常仍然较低（例如，0.6至0.7）比良性DoH流的值。而RF和DT对DoH隧道的评分通常在0.9至1.0之间，这与良性DoH流的评分相似。

对于DoH隧道，一些固有特征难以模仿。例如，DoH隧道的查询必然会到达攻击者控制的NS，而良性查询可能由于缓存而仅到达解析器。在这种情况下，DNS查询/响应时间是不同的。虽然特征较少且特征的差异可能不足以让分类器找到一个好的决策边界，但这种差异仍然会反映在线性模型（如LR模型）的最终分数中。然而，RF和DT可能会在内部节点直接将DoH流分类为良性，这无法反映这种差异。

根据实验结果，防御者可以基于LR模型的分数对DoH流进行优先级排序，并优先调查更可疑的流。虽然在这种实验设置下分类器无法准确检测DoH隧道，但研究者相信基于优先级的调查可以大大帮助防御者更快地确认安全状态。

总结

可以从防御者和攻击者的角度总结实验结果：

对于防御者，应监控TLS指纹进行初步检测。应尽可能多地收集不同类型的数据来训练分类器，包括来自不同解析器的流量、具有不同数据包发送速率的DoH隧道流量等。如果受保护的主机位于不同的地理位置，则应在不同的地理位置分别训练模型。除了关注已被分类器识别为隧道的流量外，防御者还应关注具有高异常分数的流量。

对于攻击者，为了规避所提出的检测方法，首先，受控的NS应在地理位置上足够接近受害主机。交付给受害主机的DoH隧道工具需要模仿浏览器等流行的TLS实现。此外，攻击者需要使用填充等手段来伪装数据包长度。而且，攻击者应以较慢的速度发送数据包，且DoH流中的数据包数量应较少（甚至一个流中只有一对DNS查询和响应）。为了实现上述所有条件，攻击者需要付出巨大代价，其中一些条件甚至可能仅在理论上可行。即使攻击者规避了检测，建立的DoH隧道的传输速率也非常低。因此，所提出的方法对于检测基于DoH的数据外泄是有效的。

到这里，论文的解读就结束了，下一篇我们着手进行该篇论文的复现工作。