最大限度地降低使用 DoH 和 DoT 的风险
DoH 和 DoT 保护
您控制 DNS 流量吗？ 组织投入大量时间、金钱和精力来保护其网络。 然而，DNS 是一个经常没有得到足够关注的领域。
DNS 带来的风险的一个很好的概述是 在信息安全会议上。
接受调查的勒索软件类别中有 31% 使用 DNS 进行密钥交换。研究结果
接受调查的勒索软件类别中有 31% 使用 DNS 进行密钥交换。
问题很严重。 根据 Palo Alto Networks Unit 42 研究实验室的数据，大约 85% 的恶意软件使用 DNS 建立命令和控制通道，使攻击者能够轻松地将恶意软件注入您的网络并窃取数据。 自诞生以来，DNS 流量基本上未加密，可以通过 NGFW 安全机制轻松分析。
新的 DNS 协议已经出现，旨在提高 DNS 连接的机密性。 它们得到了领先的浏览器供应商和其他软件供应商的积极支持。 企业网络中的加密 DNS 流量很快就会开始增长。 未经工具正确分析和解析的加密 DNS 流量会给公司带来安全风险。 例如，此类威胁是使用 DNS 交换加密密钥的加密锁。 攻击者现在要求支付数百万美元的赎金才能恢复对您数据的访问。 例如，Garmin 支付了 10 万美元。
正确配置后，NGFW 可以拒绝或保护 DNS-over-TLS (DoT) 的使用，并可用于拒绝使用 DNS-over-HTTPS (DoH)，从而允许分析网络上的所有 DNS 流量。
什么是加密 DNS？
什么是 DNS
域名系统 (DNS) 解析人类可读的域名（例如，地址 ) 转换为 IP 地址（例如 34.107.151.202）。 当用户在 Web 浏览器中输入域名时，浏览器会向 DNS 服务器发送 DNS 查询，询问与该域名关联的 IP 地址。 作为响应，DNS 服务器返回该浏览器将使用的 IP 地址。
DNS 查询和响应以未加密的纯文本形式通过网络发送，因此很容易受到监视或更改响应并将浏览器重定向到恶意服务器。 DNS 加密使得 DNS 请求在传输过程中难以被跟踪或更改。 加密 DNS 请求和响应可以保护您免受中间人攻击，同时执行与传统纯文本 DNS（域名系统）协议相同的功能。
过去几年，推出了两种 DNS 加密协议：
-
HTTPS上的DNS（DoH）
-
DNS-over-TLS (DoT)
这些协议有一个共同点：它们故意隐藏 DNS 请求以防止任何拦截……以及组织的保安人员。 这些协议主要使用 TLS（传输层安全性）在发出查询的客户端和通过通常不用于 DNS 流量的端口解析 DNS 查询的服务器之间建立加密连接。
DNS 查询的机密性是这些协议的一大优点。 然而，它们给必须监控网络流量并检测和阻止恶意连接的保安人员带来了问题。 由于协议的实现方式不同，DoH 和 DoT 之间的分析方法也会有所不同。
通过HTTPS的DNS（DoH）
HTTPS 内的 DNS
DoH 使用众所周知的 HTTPS 端口 443，RFC 特别指出其目的是“将 DoH 流量与同一连接上的其他 HTTPS 流量混合”，“使 DNS 流量分析变得困难”，从而规避公司控制（ ）。 DoH 协议使用 TLS 加密以及常见 HTTPS 和 HTTP/2 标准提供的请求语法，在标准 HTTP 请求之上添加 DNS 请求和响应。
与卫生部相关的风险
如果您无法区分常规 HTTPS 流量和 DoH 请求，那么您组织内的应用程序可以（并且将会）通过将请求重定向到响应 DoH 请求的第三方服务器来绕过本地 DNS 设置，从而绕过任何监控，即破坏了以下功能：控制 DNS 流量。 理想情况下，您应该使用 HTTPS 解密函数来控制 DoH。
И 在最新版本的浏览器中，两家公司都致力于默认使用 DoH 来处理所有 DNS 请求。 将 DoH 集成到他们的操作系统中。 其缺点是，不仅信誉良好的软件公司，而且攻击者也开始使用 DoH 作为绕过传统企业防火墙措施的手段。 （例如，查看以下文章： , и 无论哪种情况，良好和恶意的 DoH 流量都不会被检测到，从而使组织无法发现恶意使用 DoH 作为控制恶意软件 (C2) 和窃取敏感数据的渠道。
确保 DoH 流量的可见性和控制
作为DoH控制的最佳解决方案，我们建议配置NGFW来解密HTTPS流量并阻止DoH流量（应用程序名称：dns-over-https）。
首先，确保 NGFW 配置为解密 HTTPS，根据 .
其次，为应用程序流量“dns-over-https”创建规则，如下所示：
帕洛阿尔托网络 NGFW 规则阻止 DNS-over-HTTPS
作为临时替代方案（如果您的组织尚未完全实施 HTTPS 解密），NGFW 可以配置为对“dns-over-https”应用程序 ID 应用“拒绝”操作，但效果仅限于阻止某些特定的井口。通过域名已知 DoH 服务器，因此如果没有 HTTPS 解密，DoH 流量如何无法被完全检查（请参阅 并搜索“dns-over-https”）。
基于 TLS 的 DNS (DoT)
TLS 内的 DNS
虽然 DoH 协议倾向于与同一端口上的其他流量混合，但 DoT 默认使用为此唯一目的保留的特殊端口，甚至明确禁止传统未加密 DNS 流量使用同一端口（ ).
DoT 协议使用 TLS 提供封装标准 DNS 协议查询的加密，流量使用众所周知的端口 853 ( ）。 DoT 协议旨在让组织更轻松地阻止端口上的流量，或接受流量但在该端口上启用解密。
与 DoT 相关的风险
谷歌已在其客户端中实施了 DoT ，默认设置为自动使用 DoT（如果可用）。 如果您已经评估了风险并准备在组织级别使用 DoT，那么您需要让网络管理员明确允许端口 853 上的出站流量通过其外围以用于此新协议。
确保 DoT 流量的可见性和控制
作为 DoT 控制的最佳实践，我们建议根据您组织的要求采取上述任一措施：
-
配置 NGFW 以解密目标端口 853 的所有流量。通过解密流量，DoT 将显示为 DNS 应用程序，您可以对其应用任何操作，例如启用订阅 控制 DGA 域或现有域 和反间谍软件。
-
另一种方法是让 App-ID 引擎完全阻止端口 853 上的“dns-over-tls”流量。默认情况下，这通常会被阻止，无需执行任何操作（除非您特别允许“dns-over-tls”应用程序或端口交通853）。
来源： habr.com