配置 Azure 防火墙规则

可以使用经典规则或防火墙策略在 Azure 防火墙上配置 NAT 规则、网络规则和应用程序规则。 默认情况下,Azure 防火墙会拒绝所有流量,除非手动配置规则以允许流量。 规则正在终止,因此规则处理在匹配时停止。

使用经典规则处理规则

处理规则集合时,会根据规则类型按优先级顺序(由低编号到高编号,从 100 到 65,000)进行。 规则集合名称只能包含字母、数字、下划线、句点或连字符。 该名称必须以字母或数字开头,并且以字母、数字或下划线结尾。 名称最大长度为 80 个字符。

最好在最初以 100 为增量(100、200、300,依此类推)设置规则集合优先级编号,这样在需要时就还有空间,可以添加更多的规则集合。

使用防火墙策略处理规则

通过防火墙策略,规则组织在规则集合和规则集合组中。 规则集合组包含零个或多个规则集合。 规则集合的类型为 NAT、网络或应用程序。 可以在单个规则组中定义多个规则集合类型。 可以在一个规则集合中定义零个或多个规则。 规则集合中的规则必须属于同一类型(NAT、网络或应用程序)。

根据规则集合组优先级和规则集合优先级处理规则。 优先级为 100(最高优先级)到 65,000(最低优先级)之间的任意数字。 首先处理优先级最高的规则集合组。 在规则集合组中,首先处理优先级最高(数字最小)的规则集合。

如果防火墙策略继承自父策略,则始终优先处理父策略中的规则集合组,而无论子策略的优先级如何。

注意

应用程序规则始终在网络规则之后处理,网络规则始终在 DNAT 规则之后处理,而不管规则集合组或规则集合优先级和策略继承如何。

下面是一个示例策略:

假设 BaseRCG1 是规则集合组优先级 (200),其中包含规则集合:DNATRC1、DNATRC3、NetworkRC1。
BaseRCG2 是规则集合组优先级 (300),其中包含规则集合:AppRC2、NetworkRC2。
ChildRCG1 是规则集合组优先级 (300),其中包含规则集合:ChNetRC1、ChAppRC1。
ChildRCG2 是一个规则集合组,其中包含规则集合:ChNetRC2、ChAppRC2、ChDNATRC3。

如下表所示:

名称 类型 优先级 规则 继承自
BaseRCG1 规则集合组 200 8 父策略
DNATRC1 DNAT 规则集合 600 7 父策略
DNATRC3 DNAT 规则集合 610 3 父策略
NetworkRC1 网络规则集合 800 1 父策略
BaseRCG2 规则集合组 300 3 父策略
AppRC2 应用程序规则集合 1200 2 父策略
NetworkRC2 网络规则集合 1300 1 父策略
ChildRCG1 规则集合组 300 5 -
ChNetRC1 网络规则集合 700 3 -
ChAppRC1 应用程序规则集合 900 2 -
ChildRCG2 规则集合组 650 9 -
ChNetRC2 网络规则集合 1100 2 -
ChAppRC2 应用程序规则集合 2000 7 -
ChDNATRC3 DNAT 规则集合 3000 2 -

初始处理:

该过程首先检查编号最小的规则集合组 (RCG),即优先级为 200 的 BaseRCG1。 在该组中,它搜索 DNAT 规则集合并根据优先级对其进行评估。 在此示例中,DNATRC1(优先级 600)和DNATRC3(优先级 610)被发现并进行相应处理。
接下来,它转到下一个 RCG,即 BaseRCG2(优先级 200),但找不到 DNAT 规则集合。
接下来,它继续转到 ChildRCG1(优先级 300),同样没有 DNAT 规则集合。
最后,它检查 ChildRCG2(优先级 650),找到 ChDNATRC3 规则集合(优先级 3000)。

规则集合组内的迭代:

返回到 BaseRCG1,迭代继续,这次是针对 NETWORK 规则。 仅找到 NetworkRC1(优先级 800)。
然后,它转到 NetworkRC2(优先级 1300)所在的 BaseRCG2。
继续转到 ChildRCG1,它发现作为 NETWORK 规则的 ChNetRC1(优先级 700)。
最后,在 ChildRCG2 中,它找到作为 NETWORK 规则集合的 ChNetRC2(优先级 1100)。

APPLICATION 规则的最终迭代:

返回到 BaseRCG1,该过程以迭代方式查找 APPLICATION 规则,但没有找到。
在 BaseRCG2 中,它将 AppRC2(优先级 1200)标识为 APPLICATION 规则。
在 ChildRCG1 中,找到了作为 APPLICATION 规则的 ChAppRC1(优先级 900)。
最后,在 ChildRCG2 中,它查找作为 APPLICATION 规则的 ChAppRC2(优先级 2000)。

总而言之,规则处理顺序如下:DNATRC1、DNATRC3、ChDNATRC3、NetworkRC1、NetworkRC2、ChNetRC1、ChNetRC2、AppRC2、ChAppRC1、ChAppRC2。

此过程涉及按优先级分析规则集合组,并在每个组内根据每种规则类型(DNAT、NETWORK 和 APPLICATION)的优先级对规则排序。

因此,首先处理来自所有规则集合组的所有 DNAT 规则,按优先级顺序分析规则集合组,并按优先级顺序对每个规则集合组内的 DNAT 规则排序。 然后对 NETWORK 规则执行相同的过程,最后对 APPLICATION 规则执行相同的过程。

有关防火墙策略规则集的详细信息,请参阅 Azure 防火墙策略规则集

威胁智能

如果启用基于威胁情报的筛选,则这些规则的优先级最高,始终首先处理(在网络和应用程序规则之前)。 在处理任何已配置的规则之前,威胁情报筛选可能会拒绝流量。 有关详细信息,请参阅 Azure 防火墙基于威胁情报的筛选

IDPS

在“警报”模式下配置 IDPS 时,IDPS 引擎与规则处理逻辑并行工作,并针对入站和出站流的匹配签名生成警报。 对于 IDPS 签名匹配,会在防火墙日志中记录警报。 但是,由于 IDPS 引擎与规则处理引擎并行工作,因此应用程序/网络规则拒绝/允许的流量仍可能会生成另一个日志条目。

在“警报和拒绝”模式下配置 IDPS 时,IDPS 引擎内联并在规则处理引擎之后激活。 因此,这两个引擎都会生成警报,并且可能会阻止匹配流。 

IDPS 执行的会话删除会以无提示方式阻止流。 因此,不会在 TCP 级别发送 RST。 由于 IDPS 总是在匹配了网络/应用程序规则(允许/拒绝)并在日志中标记之后检查流量,因此,当 IDPS 决定通过签名匹配拒绝会话时,可能会记录另一条删除消息。

如果启用 TLS 检查,则会检查未加密和加密的流量。 

出站连接

网络规则和应用程序规则

如果配置了网络规则和应用程序规则,则会在应用程序规则之前先按优先级顺序应用网络规则。 规则将终止。 因此,如果在网络规则中找到了匹配项,则不会处理其他规则。 如果已配置 IDPS,则会对所有经过的流量执行 IDPS,并且在签名匹配时,IDPS 可能会警报或阻止可疑流量。

如果没有网络规则匹配项,并且协议是 HTTP、HTTPS 或 MSSQL,则应用程序规则会按优先级顺序评估数据包。

对于 HTTP,Azure 防火墙根据主机标头查找应用程序规则匹配项。 对于 HTTPS,Azure 防火墙仅根据 SNI 查找应用程序规则匹配项。

对于 HTTP 和 TLS 检查的 HTTPS,防火墙会忽略数据包的目标 IP 地址并使用主机头中 DNS 解析的 IP 地址。 防火墙期望获取主机标头中的端口号,否则它采用标准端口 80。 如果实际 TCP 端口与主机标头中的端口之间存在端口不匹配的情况,则会删除流量。 DNS 解析由 Azure DNS 或自定义 DNS(如果在防火墙上配置)完成。 

注意

HTTP 和 HTTPS 协议(使用 TLS 检查)始终由 Azure 防火墙填充,其 XFF (X-Forwarded-For) 标头等于原始源 IP 地址。 

当应用程序规则包含 TLS 检查时,防火墙规则引擎会处理 SNI、主机标头以及 URL,以匹配规则。

如果在应用程序规则中仍未找到匹配项,则会根据基础结构规则集合评估数据包。 如果仍然没有匹配项,则默认情况下会拒绝该数据包。

注意

可以为 TCP、UDP、ICMP 或“任意”IP 协议配置网络规则。 “任意”IP 协议包括 Internet 数字分配机构 (IANA) 协议编号文档中定义的所有 IP 协议。 如果显式配置了目标端口,则会将规则转换为 TCP+UDP 规则。 在 2020 年 11 月 9 日之前,“任意”意味着 TCP、UDP 或 ICMP。 因此,你可能在该日期之前配置了“协议为任意”、且“目标端口为 *”的规则 。 如果不打算像当前定义一样允许任意 IP 协议,请修改规则以显式配置所需的协议(TCP、UDP 或 ICMP)。

入站连接

DNAT 规则和网络规则

可以通过配置目标网络地址转换 (DNAT) 来启用入站 Internet 连接,如使用 Azure 门户通过 Azure Firewall DNAT 筛选入站流量中所述。 NAT 规则会在网络规则之前按优先级应用。 如果找到匹配项,流量将根据 DNAT 规则进行转换并获得防火墙允许。 这意味着流量不会由其他网络规则进行进一步的处理。 出于安全原因,推荐的方法是添加特定的 Internet 源以允许 DNAT 访问网络,并避免使用通配符。

应用程序规则不适用于入站连接。 因此,如果要筛选入站 HTTP/S 流量,应使用 Web 应用程序防火墙 (WAF)。 有关详细信息,请参阅什么是 Azure Web 应用程序防火墙

示例

下面的示例显示了组合使用其中一些规则时的结果。

示例 1

由于存在匹配的网络规则,因此允许连接到 qq.com。

网络规则

  • 操作:允许
name 协议 源类型 目标类型 目标地址 目标端口
Allow-web TCP IP 地址 * IP 地址 * 80,443

应用程序规则

  • 操作:Deny
name 源类型 协议:端口 目标 FQDN
Deny-qq IP 地址 * http:80,https:443 qq.com

结果

允许连接到 qq.com,因为该数据包符合 Allow-web 网络规则。 此时,规则处理停止。

示例 2

由于优先级较高的 Deny 网络规则集合阻止 SSH 流量,因此 SSH 流量被拒绝。

网络规则集合 1

  • 名称:Allow-collection
  • 优先级:200
  • 操作:允许
name 协议 源类型 目标类型 目标地址 目标端口
Allow-SSH TCP IP 地址 * IP 地址 * 22

网络规则集合 2

  • 名称:Deny-collection
  • 优先级:100
  • 操作:Deny
name 协议 源类型 目标类型 目标地址 目标端口
Deny-SSH TCP IP 地址 * IP 地址 * 22

结果

由于优先级较高的网络规则集合阻止 SSH 连接,因此 SSH 连接被拒绝。 此时,规则处理停止。

规则更改

如果更改规则以拒绝以前允许的流量,则会删除任何相关的现有会话。

三向握手行为

作为有状态服务,Azure 防火墙为从源到目标的允许流量完成 TCP 三向握手。 例如,VNet-A 到 VNet-B。

创建从 VNet-A 到 VNet-B 的允许规则并不意味着允许从 VNet-B 到 VNet-A 的新启动连接。

因此,无需创建从 VNet-B 到 VNet-A 的显式拒绝规则。

后续步骤