Configuración de las reglas de Azure Firewall

Artículo
07/02/2024

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. Las reglas finalizan, por lo que el procesamiento de reglas se detiene en una coincidencia.

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.

En resumen:

La directiva primaria siempre tiene prioridad.

Los grupos de recopilación de reglas se procesan en orden de prioridad.
Las colecciones de reglas se procesan en orden de prioridad.
Se procesan las reglas DNAT, las reglas de red y, a continuación, las reglas de aplicación.

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 (300) que contiene las colecciones de reglas: ChNetRC1, ChAppRC1.
ChildRCG2 es una prioridad de grupo de recopilación de reglas (650) 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	-

Iteración inicial para reglas DNAT:

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 300), 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 para reglas de RED:

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 entrante a Internet o intranet (versión preliminar), configure Traducción de direcciones de red de destino (DNAT) como se describe en el Filtro del tráfico entrante de Internet o intranet 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.

Compartir a través de