Configuración de las reglas de Azure Firewall

Puede configurar reglas NAT, reglas de red y reglas de aplicaciones en Azure Firewall mediante las reglas clásicas o la directiva de firewall. Azure Firewall deniega todo el tráfico de forma predeterminada, hasta que se configuren reglas manualmente para permitirlo.

Procesamiento de reglas con reglas clásicas

Las colecciones de reglas se procesan según el tipo de regla en orden de prioridad, de números inferiores a números mayores desde 100 hasta 65 000. El nombre de una colección de reglas solo puede contener letras, números, guiones bajos, puntos o guiones. Debe comenzar con una letra o un número y terminar con una letra, un número o un guion bajo. La longitud máxima del nombre es de 80 caracteres.

Es mejor espaciar inicialmente los números de prioridad de la colección de reglas en incrementos de 100 (100, 200, 300, etc.) para disponer de espacio para agregar más colecciones de reglas si es necesario.

Procesamiento de reglas con la directiva de firewall

Con la directiva de firewall, las reglas se organizan en colecciones de reglas y grupos de colecciones de reglas. Los grupos de colecciones de reglas contienen cero o más colecciones de reglas. Las colecciones de reglas son de tipo NAT, de red o de aplicaciones. Puede definir varios tipos de colecciones de reglas dentro de un único grupo de reglas. En una colección de reglas, puede definir cero o más reglas. Las reglas de una colección deben ser del mismo tipo (NAT, de red o de aplicación).

Las reglas se procesan en función de la prioridad del grupo de colecciones de reglas y de la prioridad de la colección de reglas. La prioridad es cualquier número entre 100 (prioridad más alta) y 65 000 (prioridad más baja). Los grupos de colecciones de reglas de prioridad más alta se procesan en primer lugar. Dentro de un grupo de colecciones de reglas, se procesan en primer lugar las colecciones de reglas con prioridad más alta (número más bajo).

Si se hereda una directiva de firewall de una directiva primaria, los grupos de colecciones de reglas de esa directiva siempre tienen prioridad, independientemente de la prioridad de una directiva secundaria.

Nota

Las reglas de aplicación siempre se procesan después de las reglas de red, que a su vez se procesan después de las reglas DNAT, independientemente de la prioridad del grupo de colecciones de reglas o de la colección de reglas, así como de la herencia de directivas.

A continuación, se proporciona una directiva de ejemplo:

Suponiendo que BaseRCG1 es una prioridad de grupo de recopilación de reglas (200) que contiene las colecciones de reglas: DNATRC1, DNATRC3,NetworkRC1.
BaseRCG2 es una prioridad de grupo de recopilación de reglas (300) que contiene las colecciones de reglas: AppRC2, NetworkRC2.
ChildRCG1 es una prioridad de grupo de recopilación de reglas (200) que contiene las colecciones de reglas: ChNetRC1, ChAppRC1.
ChildRCG2 es un grupo de recopilación de reglas que contiene las colecciones de reglas: ChNetRC2, ChAppRC2,ChDNATRC3.

Según la tabla siguiente:

Nombre Tipo Prioridad Reglas Heredado de
BaseRCG1 Grupo de colección de reglas 200 8 Directiva principal
DNATRC1 Colección de reglas DNAT 600 7 Directiva principal
DNATRC3 Colección de reglas DNAT 610 3 Directiva principal
NetworkRC1 Recopilación de reglas de red 800 1 Directiva principal
BaseRCG2 Grupo de colección de reglas 300 3 Directiva principal
AppRC2 Recopilación de reglas de aplicación 1200 2 Directiva principal
NetworkRC2 Recopilación de reglas de red 1300 1 Directiva principal
ChildRCG1 Grupo de colección de reglas 300 5 -
ChNetRC1 Recopilación de reglas de red 700 3 -
ChAppRC1 Recopilación de reglas de aplicación 900 2 -
ChildRCG2 Grupo de colección de reglas 650 9 -
ChNetRC2 Recopilación de reglas de red 1100 2 -
ChAppRC2 Recopilación de reglas de aplicación 2000 7 -
ChDNATRC3 Colección de reglas DNAT 3000 2 -

Procesamiento inicial:

El proceso comienza examinando el grupo de recopilación de reglas (RCG) con el número más bajo, que es BaseRCG1 con una prioridad de 200. Dentro de este grupo, busca colecciones de reglas DNAT y las evalúa según sus prioridades. En este caso, se encuentran DNATRC1 (prioridad 600) y DNATRC3 (prioridad 610) y se procesan en consecuencia.
A continuación, se mueve al siguiente RCG, BaseRCG2 (prioridad 200), pero no encuentra ninguna colección de reglas DNAT.
Después, continúa con ChildRCG1 (prioridad 300), también sin una colección de reglas DNAT.
Por último, comprueba ChildRCG2 (prioridad 650) y busca la colección de reglas ChDNATRC3 (prioridad 3000).

Iteración dentro de grupos de recopilación de reglas:

Volviendo a BaseRCG1, la iteración continúa, esta vez para las reglas NETWORK. Solo se encuentra NetworkRC1 (prioridad 800).
A continuación, se mueve a BaseRCG2, donde se encuentra NetworkRC2 (prioridad 1300).
Al pasar a ChildRCG1, detecta ChNetRC1 (prioridad 700) como regla NETWORK.
Por último, en ChildRCG2, busca ChNetRC2 (prioridad 1100) como la colección de reglas NETWORK.

Iteración final para las reglas de aplicación:

Volviendo a BaseRCG1, el proceso recorre en iteración las reglas APPLICATION, pero no se encuentra ninguno.
En BaseRCG2, identifica AppRC2 (prioridad 1200) como regla APPLICATION.
En ChildRCG1, ChAppRC1 (prioridad 900) se encuentra como regla APPLICATION.
Por último, en ChildRCG2, busca ChAppRC2 (prioridad 2000) como regla APPLICATION.

En resumen, la secuencia de procesamiento de reglas es la siguiente: DNATRC1, DNATRC3, ChDNATRC3, NetworkRC1, NetworkRC2, ChNetRC1, ChNetRC2, AppRC2, ChAppRC1, ChAppRC2.

Este proceso implica analizar los grupos de recopilación de reglas por prioridad y, dentro de cada grupo, ordenar las reglas según sus prioridades para cada tipo de regla (DNAT, NETWORK y APPLICATION).

Por lo tanto, todas las reglas DNAT se procesan primero de todos los grupos de recopilación de reglas, analizando los grupos de recopilación de reglas por orden de prioridad y ordenando las reglas DNAT dentro de cada grupo de recopilación de reglas por orden de prioridad. A continuación, el mismo proceso para las reglas NETWORK y, por último, para las reglas APPLICATION.

Para obtener más información sobre los conjuntos de reglas de directiva de firewall, consulte Conjuntos de reglas de directiva de Azure Firewall.

Información sobre amenazas

Si habilita el filtrado basado en la inteligencia sobre amenazas, esas reglas tienen la prioridad más alta y siempre se procesan primero (antes que las reglas de red y de aplicación). El filtrado de inteligencia sobre amenazas puede denegar el tráfico antes de que se procesen las reglas configuradas. Para más información, consulte Filtrado basado en inteligencia sobre amenazas de Azure Firewall.

IDPS

Cuando IDPS se configura en modo de alerta, el motor de IDPS funciona en paralelo con la lógica de procesamiento de reglas y genera alertas sobre las firmas correspondientes para los flujos entrantes y salientes. Para una coincidencia de firma de IDPS, se registra una alerta en los registros del firewall. Sin embargo, dado que el motor de IDPS funciona en paralelo con el motor de procesamiento de reglas, el tráfico denegado o permitido por las reglas de aplicación o de red aún puede generar otra entrada de registro.

Cuando IDPS se configura en el modo de alerta y denegación, el motor de IDPS está en línea y se activa después del motor de procesamiento de reglas. Por tanto, los dos motores generan alertas y pueden bloquear los flujos que coincidan. 

Las interrupciones de sesión que realiza IDPS bloquean el flujo silenciosamente. Por lo tanto, no se envía ningún RST en el nivel TCP. Puesto que IDPS inspecciona el tráfico siempre después de que la regla de red o aplicación haya coincidido (Permitir/Denegar) y se haya marcado en los registros, se puede registrar otro mensaje Drop donde IDPS decida denegar la sesión debido a una coincidencia de firma.

Cuando la inspección de TLS está habilitada, se inspecciona tanto el tráfico cifrado como sin cifrar. 

Conectividad de salida

Reglas de red y reglas de aplicaciones

Si configura reglas de red y reglas de aplicación, las reglas de red se aplican en orden de prioridad antes que las reglas de aplicación. Las reglas están terminando. Por lo tanto, si se encuentra una coincidencia en una regla de red, no se procesa ninguna otra regla. Si se ha configurado, IDPS se aplica a todo el tráfico recorrido y, tras la coincidencia de firma, IDPS puede alertar sobre tráfico sospechoso o bloquearlo.

Las reglas de aplicación evalúan el paquete en orden de prioridad si no coincide ninguna regla de red y el protocolo es HTTP, HTTPS o MSSQL.

Para HTTP, Azure Firewall busca una coincidencia de regla de aplicación en función del encabezado host. Para HTTPS, Azure Firewall buscar una coincidencia de regla de aplicación solo en función de SNI.

En los casos de HTTPS inspeccionados por HTTP y TLS, el firewall ignora la dirección IP de destino del paquete y usa la dirección IP resuelta por DNS del encabezado de host. El firewall espera obtener el número de puerto en el encabezado host; de lo contrario, asume el puerto estándar 80. Si hay un error de coincidencia entre el puerto TCP real y el del encabezado de host, el tráfico se interrumpe. Azure DNS o un DNS personalizado realizan la resolución DNS si se ha configurado en el firewall. 

Nota:

Azure Firewall siempre rellena los protocolos HTTP y HTTPS (con inspección de TLS) con un encabezado XFF (X-Forwarded-For) igual a la dirección IP de origen original. 

Cuando una regla de aplicación contiene la inspección de TLS, el motor de reglas de firewall procesa SNI, el encabezado host y también la dirección URL para coincidir con la regla.

Si sigue sin haber coincidencias en las reglas de aplicación, el paquete se evalúa con la colección de reglas de infraestructura. Si sigue sin haber coincidencias, el paquete se deniega de forma predeterminada.

Nota:

Las reglas de red se pueden configurar para los protocolos TCP, UDP, ICMP o cualquier protocolo IP. La opción "cualquier protocolo IP" incluye todos los protocolos IP tal como se definen en el documento Números de protocolo de autoridad de asignación de números de Internet (IANA). Si se configura explícitamente un puerto de destino, la regla se traducirá a una regla TCP y UDP. Antes del 9 de noviembre de 2020, la opción Cualquier significaba TCP, UDP o ICMP. Por lo tanto, es posible que haya configurado una regla antes de esa fecha con los valores Protocolo = Cualquiera y puertos de destino = "*" . Si no quiere permitir ningún protocolo IP como el definido actualmente, modifique la regla para configurar explícitamente los protocolos que quiera (TCP, UDP o ICMP).

Conectividad de entrada

Reglas DNAT y reglas de red

Para habilitar la conectividad a Internet entrante, configure Traducción de direcciones de red de destino (DNAT) como se describe en el Filtro del tráfico entrante con la DNAT de Azure Firewall mediante Azure Portal. Las reglas NAT se aplican en orden de prioridad antes que las reglas de red. Si se encuentra una coincidencia, el tráfico se traduce según la regla DNAT y si el firewall lo permite. Por tanto, el tráfico no está sujeto a ningún procesamiento adicional por parte de otras reglas de red. Por motivos de seguridad, se recomienda agregar un origen de Internet específico para permitir el acceso de DNAT a la red y evitar el uso de caracteres comodín.

No se aplican reglas de aplicación a las conexiones entrantes. Por lo tanto, si quiere filtrar el tráfico HTTP/S entrante, debe usar Web Application Firewall (WAF). Para más información, consulte ¿Qué es Azure Web Application Firewall?

Ejemplos

En los siguientes ejemplos se muestran los resultados de algunas de estas combinaciones de reglas.

Ejemplo 1

La conexión a google.com se permite debido a una regla de red coincidente.

Regla de red

  • Acción: Allow
name Protocolo Tipo de origen Source Tipo de destino Dirección de destino Puertos de destino
Allow-web TCP Dirección IP * Dirección IP * 80 443

Regla de aplicación

  • Acción: Denegar
name Tipo de origen Source Protocolo:Puerto FQDN de destino
Deny-google Dirección IP * http:80,https:443 google.com

Resultado

La conexión a google.com se permite porque el paquete coincide con la regla de red Allow-web. El procesamiento de reglas se detiene en este momento.

Ejemplo 2

Se deniega el tráfico SSH porque una colección de reglas de red Denegar de prioridad más alta lo bloquea.

Colección de reglas de red 1

  • Nombre: Allow-collection
  • Prioridad: 200
  • Acción: Permitir
name Protocolo Tipo de origen Source Tipo de destino Dirección de destino Puertos de destino
Allow-SSH TCP Dirección IP * Dirección IP * 22

Colección de reglas de red 2

  • Nombre: Deny-collection
  • Prioridad: 100
  • Acción: Denegar
name Protocolo Tipo de origen Source Tipo de destino Dirección de destino Puertos de destino
Deny-SSH TCP Dirección IP * Dirección IP * 22

Resultado

Se deniegan las conexiones SSH porque una colección de reglas de red de prioridad más alta las bloquea. El procesamiento de reglas se detiene en este momento.

Cambios de reglas

Si cambia una regla para denegar el tráfico permitido anteriormente, se quitará cualquier sesión existente pertinente.

Comportamiento del protocolo de enlace de tres direcciones

Como servicio con estado, Azure Firewall realiza un protocolo de enlace de tres direcciones de TCP para el tráfico permitido, desde un origen al destino. Por ejemplo, VNet-A a VNet-B.

La creación de una regla de tipo permitir de VNet-A a VNet-B no significa que se permita el inicio de nuevas conexiones de VNet-B a VNet-A.

Como resultado, no es necesario crear una regla de denegación explícita de VNet-B a VNet-A. Si crea esta regla de denegación, interrumpa el protocolo de enlace de tres direcciones de la regla de tipo permitir inicial de VNet-A a VNet-B.

Pasos siguientes