如何在 AZURE 中根据域名 (FQDN) 而不是 IP 地址来允许/拒绝流量？

Question

我可以在 Azure 网络安全组中为 IP 地址添加入站/出站规则，但如何为域名 (URL) 添加入站/出站规则？

Answer 1

出于以下原因：

根据设计： 许多安全系统根本不支持使用 FQDN 创建 ACL。并且您只能使用 IP 地址（范围）信息创建 ACL。

警告：任何支持包含 FQDN 的 ACL 的系统，经过仔细检查，很可能实际上无法提供您直观期望的安全性、灵活性和/或行为级别。

一般来说，在 ACL 中使用 FQDN 的问题根源在于以下基本事实：

您的（安全）系统仅将 IP 地址视为网络流量的源和目的地。

要使用 FQDN，您的安全系统需要在包含新的未知 IP 地址的流量到达时执行反向 DNS 查找，以确定该特定 IP 地址是否解析为访问控制列表中的 FQDN，或者需要将 FQDN 解析为 FQDN。在应用访问策略之前解析为 IP 地址。

实时反向 DNS 查找

实时反向查找的问题除了速度慢之外，还在于 IP 地址的所有者可以在反向 DNS 记录上设置他们想要的任何主机名，包括来自他们不拥有的域的主机名。 ，尤其是您自己的域...所以这既慢又不可靠且不安全。

_{something.contoso.com.例如，渗透测试人员/攻击者的标准技巧是在评估 Contoso 的安全性时设置自己的 PTR 记录。然后它们将被包含在任何信任的安全策略中 *.contoso.com......}

解析 FQDN

或者，系统可以（自动）将提供的 FQDN 转换为后台/管理工具中的 IP 地址，并有效地将您的策略​​应用于 FQDN 解析到的 IP 地址。这将防止缓慢、不可靠和不安全的反向查找，但这会导致一系列不同的问题：

• 许多系统在应用规则集时不会显示 FQFN 解析到的 IP 地址。

• 确实显示 IP 地址的系统通常不再显示原始 FQDN。
  _{或者，当它们确实显示 FQDN 时，它们通常会显示 IP 地址上的反向 DNS 查找的结果，您会发现 PTR 通常与初始正向 DNS 记录不一致，这肯定​​会造成混淆。}

• 域所有者可以随时更改与 FQDN 关联的 IP 地址，新的 IP 地址将如何以及何时替换您策略中的旧 IP 地址？
  _{许多系统仅解析一次 FQDN，从那时起将“永远”使用解析后的 IP 地址。我不知道有哪个系统实现了遵守 DNS 记录的 TTL 等规则，或任何其他方法来定期检查 FQDN 是否仍解析为相同的 IP 地址，并且如果发生更改，将更新有效 ACL 中使用的 IP。}

• 一个 FQDN 甚至可以解析为多个 IP 地址。IPv4 和 IPv6 以及两者的倍数。
  _{许多系统需要 IPv4 和 IPv6 的单独规则和/或不支持以预期/一致的方式循环 DNS 记录。}

• FQDN 可能会解析为不同（范围）的 IP 地址（任播/地理 DNS），具体取决于执行解析的客户端 IP 地址，因此基于 FQDN 的策略不可能匹配所有实际 IP 地址...