文章总结： 本文分析Azure私有端点DNS配置不当引发的DoS风险，指出强制私有解析可能导致服务中断。建议通过启用回退到互联网功能、手动添加DNS记录进行缓解，并利用AzureResourceGraph扫描识别脆弱配置，以保障云环境网络安全。 综合评分： 86 文章分类： 云安全,漏洞分析,解决方案,漏洞预警,安全运营
Azure私有端点DoS风险：DNS配置不当引发的服务中断
Dubito Dubito
云原生安全指北
2026年1月22日 08:35 江苏
注：本文翻译自 Unit42 的文章《DNS OverDoS: Are Private Endpoints Too Private?》[1]，可点击文末“阅读原文”按钮查看英文原文。
全文如下：
摘要
我们发现 Azure Private Endpoint（私有端点）[2] 架构的一个特点，可能导致 Azure 资源面临拒绝服务 (DoS) 攻击的风险。在本文中，我们将探讨有意或无意的行为如何通过 Azure Private Link 机制导致对 Azure 资源的访问受限。我们在调查 Azure 测试环境中的异常行为时发现了此问题。
该风险存在于以下三种场景：
- • 无意 – 内部人员：网络管理员为了增强 Azure 环境内的网络安全而部署私有端点。
- • 无意 – 供应商：第三方供应商作为其解决方案的一部分部署私有端点，例如，为了让安全产品能够扫描资源。
- • 恶意 – 攻击者：已获得 Azure 环境访问权限的威胁行为者，有意部署私有端点作为 DoS 攻击的一部分。
我们的研究表明，目前超过 5% 的 Azure 存储账户因其配置而受此 DoS 问题影响。在大多数环境中，以下每个服务中至少有一个资源存在此风险：
- • Key Vault
- • CosmosDB
- • Azure 容器仓库(registry)（ACR）
- • Function Apps
- • OpenAI 账户
此问题可能以多种方式影响组织。例如，对存储账户拒绝服务可能导致 FunctionApps 中的 Azure Functions[3] 以及对这些应用的后续更新失败。另一种情况是，此风险可能导致对 Key Vault 的 DoS 攻击，进而对依赖密钥库中secrets信息的进程产生连锁反应。
微软提供了 fallback to internet（回退到互联网）[4] 的建议，可以部分解决此问题及其他与 Private Endpoints 相关的 已知问题[5]。
我们将讨论这些问题，提供潜在的解决方案，并建议防御者如何扫描环境中易受 DoS 攻击的资源。
一、Azure Private Link 核心组件、概念与流程
作为 Azure 网络服务的一部分，微软创建了 Azure Private Link（私有端点）[6]。该机制提供了一种通过 Azure 骨干网连接到受支持的 Azure 资源和 Azure 托管的客户服务的私有、安全方式。
1.1 定义
为了理解该解决方案及其如何安全连接资源，我们首先定义关键组件和概念。
- • Service（服务）：建立连接的目标。
- • Private Link（私有链接）：允许并处理连接的 Azure 实现。
- • Private Endpoint（私有端点）：客户虚拟网络中的一个网络接口，用于连接到服务。
- • 私有DNS区域：与私有端点配合使用的默认域名系统 (DNS) 服务。
- • 虚拟网络链接：默认在 Private DNS zone 与虚拟网络之间创建的链接。
- • DNS A 记录：将域名或主机名映射到 IP 地址的 DNS 记录。
- • Network ACL：网络访问控制列表 (ACLs) 定义了允许或限制访问服务的流量规则，它与 Private Link 解决方案是分开的。
Azure 资源默认暴露公共端点。这些端点通过标准 DNS 基础设施解析 —— 可以是公共 Azure DNS，也可以是客户管理的 DNS 解析器。当客户端查询像 mystorageaccount.blob.core.windows.net 这样的服务名称时，DNS 解析器会返回一个属于微软的公共 IP 地址。根据应用的网络访问控制，该 IP 地址允许通过公共互联网或 Azure 服务端点进行连接。
当引入 Azure 私有链接后，DNS 解析行为会发生变化。一个私有 DNS 区域 —— 例如 privatelink.blob.core.windows.net —— 可以链接到一个或多个虚拟网络。如果某个虚拟网络链接到了一个针对特定服务类型的私有 DNS 区域，那么 Azure 的 DNS 解析逻辑在解析匹配的服务名称时，会优先使用该区域。如果存在匹配的记录，该名称将解析到私有端点的私有 IP 地址，而不是公共端点。
组织通常部署以下架构之一：
- • 纯公共架构：资源通过其公共端点和标准 DNS 解析进行访问，访问权限由 Network ACLs、防火墙或服务端点进行限制。
- • 纯私有架构：所有对资源的访问都通过私有端点进行。公共网络访问被禁用，DNS 解析完全通过私有 DNS 区域控制。
- • 混合架构（公共与私有并存）：部分虚拟网络或工作负载通过私有端点访问资源，而其他则继续使用公共端点。这种模型常用于迁移、分阶段部署、第三方集成或共享服务环境。
我们将以存储账户为例，说明私有端点在 Azure 网络中的使用方式。不过，相同的概念适用于任何支持私有链接的服务。默认情况下，当网络管理员或拥有适当 Azure 基于角色的访问控制 (RBAC) 权限的用户创建一个链接到某个资源的私有端点时，系统会自动创建一个私有 DNS 区域，并建立一条指向与该私有端点相同虚拟网络的虚拟网络链接。
该 DNS 区域的名称基于 私有端点的目标服务[7]，具有预定义的结构（例如，用于 Blob 存储的 privatelink.blob.core.windows.net）。此外，会在该 DNS 区域中创建一条 A 记录，将目标资源的名称与该私有端点的 IP 地址关联起来。
对于配置了 Network ACL 的存储账户，虚拟机与其之间有两种连接方式：
- • 不使用私有端点（使用公共或服务端点）
- • 使用私有端点
1.2 连接流程
图 1 展示了如何连接到不使用私有链接解决方案的资源。
图 1. 未使用私有链接解决方案的连接流程。
此情况下的流程如下：
- 1. 当尝试访问存储账户时，虚拟机试图将账户名称解析为 IP 地址。这通常通过外部 DNS 解析器进行，且流量会经过公共互联网。
- 2. 如果解析器有该存储账户的记录，它将返回相应的 IP 地址。
- 3. 一旦获得地址，虚拟机便尝试连接到存储账户。
- 4. 存储账户随后根据其 Network ACL 评估虚拟机的 IP 地址。如果允许连接，存储账户将返回所请求的信息。
图 2 展示了使用私有端点时，建立相同连接的流程。
图 2. 使用私有链接解决方案的连接流程。
- 1. 首先，虚拟机尝试将账户名称解析为 IP 地址。如果虚拟网络 (VNET) 中存在指向私有链接服务的私有 DNS 区域的虚拟网络链接，Azure 的私有链接机制会强制使用该私有 DNS 区域进行解析。当连接到同类型的私有链接服务（例如 Blob 存储）时，就会发生这种情况。
- 2. 当 DNS 解析器找到匹配的 A 记录时，它向虚拟机提供相应的 IP 地址。
- 3. 随后，虚拟机连接到该 IP 地址，该地址属于私有端点。
- 4. 私有端点充当存储账户的网络接口，评估流量后将其转发到存储账户。
- 5. 存储账户评估请求，并通过私有链接解决方案提供响应。
- 6. 响应被呈现给虚拟机，本质上，虚拟机是通过 Azure 骨干网络访问存储账户的。
二、私有链接 DNS 的潜在危险
如上所述，从某个虚拟网络与私有链接服务产生交互，如果该网络为特定服务类型配置了私有 DNS 区域，则会被强制通过该私有 DNS 区域进行解析。
考虑这样一个环境：VNET1 中的 VM1 正在使用公共端点成功访问一个存储账户。DNS 解析通过默认的公共 DNS 基础设施进行，且存储账户的 Network ACLs 允许此访问。此时，工作负载运行正常。
后来，该存储账户在 VNET2 中创建了一个私有端点 —— 无论是出于有意、无意还是第三方部署。作为此过程的一部分，用于 Blob 存储的私有 DNS 区域 (privatelink.blob.core.windows.net) 被链接到了 VNET1 或在多个虚拟网络之间共享。
一旦这个 DNS 区域被链接，Azure 的 DNS 解析逻辑就会强制 VNET1 中所有对 Blob 存储名称的解析都通过该私有 DNS 区域进行。然而，由于在该区域的上下文中，对于 VNET1 内的存储账户并不存在对应的“A”记录，DNS 解析会失败。VM1 再也无法解析存储账户的主机名，因而无法连接 —— 即使公共端点依然可访问且未作任何更改。
这种配置变更，实际上为 VNET1 中先前运行正常的工作负载造成了拒绝服务的状况。这种中断仅仅是由私有链接配置引入的 DNS 解析副作用触发的，而目标资源本身没有任何变化。
图 3 演示了这个例子。
图 3. 使用私有链接解决方案可能引发的问题。
上图显示，VM1 尝试连接到存储账户。该存储账户在 VNET2 中有一个私有端点，但在 VNET1 中没有。假设 VM1 试图使用存储账户的公共端点进行连接。如果 VM 所在的虚拟网络没有指向同一资源类型的私有 DNS 区域，这种方式本应可行。但在本例中，由于私有 DNS 区域和服务都已在私有链接中注册，私有链接机制强制解析通过该私有 DNS 区域进行。
图 3 所示的过程如下：
- 1. 私有链接机制识别出 VNET1 中存在 Blob 存储的私有 DNS 区域，并判定该存储账户已注册了私有链接。私有链接强制 DNS 解析必须通过该私有 DNS 区域进行。
- 2. 图 3 的配置显示，在链接到 VNET1 的私有 DNS 区域中，并未为该存储账户创建记录。因此，虚拟机无法解析该服务。
- 3. 由于步骤 2 中的 DNS 解析问题，后续步骤 —— 即 VM1 向存储账户发送请求并接收响应 —— 不会发生。
这种情况导致了部分拒绝服务：VNET1 中任何试图访问该存储账户的资源都将无法访问。
在使用本地 DNS 解析器时，根据具体的配置和添加的记录，同样可能存在此风险。此外，尽管我们的示例特指 Blob 存储，但任何支持 Azure 私有链接[8] 的服务都潜在此风险。
三、缓解措施与建议
Azure 私有链接原本被设计为一个二元解决方案，要么完全启用，要么完全禁用。当服务按预期实现时，用户只能通过这些资源的私有端点来访问使用私有链接的资源。这种方法消除了同时使用私有、公共和服务端点的需要。然而，由于超过 5% 的 Azure 存储账户的配置方式使其受此问题影响，我们认为有必要提供解决方案来应对这些实施方式带来的风险。
3.1 缓解措施
微软承认该解决方案的二元特性是一个已知问题，并在 其文档[5] 中提及了这一点。微软也提供了一个部分解决方案：在创建虚拟网络链接时启用 fallback to internet（回退到互联网）[4] 选项。使用此回退方案后，当 DNS 解析器找不到匹配请求服务的记录时，它会回退到公共互联网。虽然这个方案解决了问题，但它不一定符合 Azure 私有链接的核心概念，即通过 Azure 骨干网络而非公共互联网进行传输。
第二个部分解决方案是，在必要的私有 DNS 区域中为受影响的资源手动添加一条记录。此选项不太适合大型生产环境，因为它会带来额外的运维开销。
尽管回退和手动添加记录都不是彻底的解决方案，但将上述方法与全面的发现过程相结合，将有助于映射、查找并修复受影响的配置。
3.2 全面发现与扫描
有两种方法可以扫描和识别潜在风险的资源：
- 1. 针对每项服务单独扫描资源
- 2. 使用 Azure Resource Graph Explorer[9]
第二种扫描方法效率更高，并且可以轻松修改以适应大多数资源类型。我们创建了一个图查询，用于检索环境中所有链接到 Blob 存储私有 DNS 区域 (privatelink.blob.core.windows.net) 的虚拟网络列表。当这些虚拟网络与已注册私有链接的资源通信时，它们会被强制通过其私有端点解析 Blob 存储资源。
resources
| where type == "microsoft.network/privatednszones/virtualnetworklinks"
| extend
zone = tostring(split(id, "/virtualNetworkLinks")[0]),
vnetId = tostring(properties.virtualNetwork.id)
| join kind=inner (
resources
| where type == "microsoft.network/privatednszones"
| where name == "privatelink.blob.core.windows.net"
| project zoneId = id
) on $left.zone == $right.zoneId
| project vnetId
此外，识别哪些虚拟网络与那些没有私有端点连接的 Blob 存储资源交互也很重要。为此，我们创建了以下查询。该查询检索允许访问其公共端点且没有私有端点连接的存储账户。
Resources
| where type == "microsoft.storage/storageaccounts"
| extend publicNetworkAccess = properties.publicNetworkAccess
| extend defaultAction = properties.networkAcls.defaultAction
| extend vnetRules = properties.networkAcls.virtualNetworkRules
| extend ipRules = properties.networkAcls.ipRules
| extend privateEndpoints = properties.privateEndpointConnections
| where publicNetworkAccess == "Enabled"
| where defaultAction == "Deny"
| where (isnull(privateEndpoints) or array_length(privateEndpoints) == 0)
| extend allowedVnets = iif(isnull(vnetRules), 0, array_length(vnetRules))
| extend allowedIps = iif(isnull(ipRules), 0, array_length(ipRules))
| where allowedVnets > 0 or allowedIps > 0
| project id, name, vnetRules, ipRules
该查询不仅识别被允许的虚拟网络，还能检索允许特定 IP 地址访问的资源。当虚拟网络的 DNS 配置可见性有限，难以判断配置是否受影响时，此方法非常有用。
防御者应注意，即使没有配置 Network ACLs 的资源也可能存在风险。然而，无法仅通过配置来判断哪些虚拟网络（如果有的话）正尝试与这类资源通信。为了应对此风险，可以利用网络日志来识别从 Azure 网络范围连接到易受攻击资源的连接。
防御者可以通过修改上述 Resources 查询中的资源和私有 DNS 区域详细信息，来检测存在风险的私有链接支持资源。
四、结论
充分理解 Azure 私有链接的局限性，对于保障依赖它的网络安全至关重要。在某些组件和架构的配置下，Azure 私有链接的二元特性可能导致连接丢失，在某些情况下还可能促成拒绝服务 (DoS) 攻击。
针对此风险保护私有端点的两种可行解决方案包括：
- • 启用回退到公共 DNS 解析的功能
- • 为受影响的资源手动添加 DNS 记录
防御者可以通过查询资源、进行全面的网络扫描以识别有风险的资源，并实施必要的防护措施，来提高这些解决方案的效力。
五、Palo Alto Networks 的防护与缓解措施
Palo Alto Networks 客户可通过以下产品获得针对本文所述威胁的更好保护：
- • Cortex Cloud[10] 客户通过在云环境中正确部署 Cortex Cloud XDR 端点代理[11] 和 无服务器代理（serverless agents）[12]，可以更好地防范本文所讨论的 Azure 私有端点被滥用行为。Cortex Cloud 旨在保护云的配置状态和运行时操作免受此类威胁。它有助于检测和预防本文讨论的恶意操作、配置更改或利用行为。
Unit 42 云安全评估[13] 是一项战略评估服务，它会审查您组织的云基础设施，以识别错误配置和安全漏洞，使团队能够增强其应对基于云威胁的安全状态。
Palo Alto Networks 已将以上发现与我们的网络威胁联盟 (CTA) 成员分享。CTA 成员利用这些情报为其客户快速部署防护措施，并系统性地干扰恶意网络攻击者。了解更多关于 网络威胁联盟[14] 的信息。
六、其他资源
- • Azure 私有端点私有 DNS 区域值[7] – Microsoft 文档
- • Azure 私有链接可用性[8] – Microsoft 文档
- • Azure Resource Graph Explorer[9] – Microsoft 文档
- • 对于使用私有端点的虚拟网络内客户端的存储访问约束[5] – Microsoft 文档
引用链接
[1] 《DNS OverDoS: Are Private Endpoints Too Private?》: https://unit42.paloaltonetworks.com/dos-attacks-and-azure-private-endpoint/
[2] Private Endpoint（私有端点）: https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-overview
[3] FunctionApps 中的 Azure Functions: https://learn.microsoft.com/en-us/azure/azure-functions/functions-overview
[4] fallback to internet（回退到互联网）: https://learn.microsoft.com/en-us/azure/dns/private-dns-fallback
[5] 已知问题: https://learn.microsoft.com/en-us/azure/storage/common/storage-private-endpoints?toc=%2Fazure%2Fstorage%2Fblobs%2Ftoc.json&bc=%2Fazure%2Fstorage%2Fblobs%2Fbreadcrumb%2Ftoc.json#storage-access-constraints-for-clients-in-virtual-networks-with-private-endpoints
[6] Azure Private Link: https://learn.microsoft.com/en-us/azure/private-link/private-link-overview
[7] 私有端点的目标服务: https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns
[8] Azure 私有链接: https://learn.microsoft.com/en-us/azure/private-link/availability
[9] Azure Resource Graph Explorer: https://learn.microsoft.com/en-us/azure/governance/resource-graph/
[10] Cortex Cloud: https://www.paloaltonetworks.com/cortex/cloud
[11] XDR 端点代理: https://docs-cortex.paloaltonetworks.com/r/Cortex-CLOUD/Cortex-Cloud-Runtime-Security-Documentation/Endpoint-protection
[12] 无服务器代理（serverless agents）: https://docs-cortex.paloaltonetworks.com/r/Cortex-CLOUD/Cortex-Cloud-Runtime-Security-Documentation/Serverless-function-posture-security
[13] Unit 42 云安全评估: https://www.paloaltonetworks.com/unit42/assess/cloud-security-assessment
[14] 网络威胁联盟: https://www.cyberthreatalliance.org/
交流群
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：云原生安全指北 Dubito Dubito《Azure私有端点DoS风险：DNS配置不当引发的服务中断》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论