Compartir por

Configuración de las reglas de Azure Firewall

Puede configurar Azure Firewall con reglas NAT, reglas de red y reglas de aplicación mediante reglas clásicas o una directiva de firewall. De forma predeterminada, Azure Firewall deniega todo el tráfico hasta que configure manualmente reglas para permitir el tráfico. Las reglas finalizan, por lo que el procesamiento de reglas se detiene en una coincidencia.

Procesamiento de reglas mediante reglas clásicas

El firewall procesa colecciones de reglas en orden de prioridad por tipo de regla, de números inferiores a números más altos (de 100 a 65 000). Un nombre de colección de reglas solo puede contener letras, números, caracteres de subrayado, 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.

Inicialmente, distribuya los números de prioridad de colección de reglas en incrementos de 100 (100, 200, 300, etc.), de modo que tenga espacio para agregar más colecciones de reglas si es necesario.

Procesamiento de reglas mediante la política de firewall

Mediante la política de firewall, organiza las reglas dentro de colecciones de reglas y grupos de colecciones de reglas. Los grupos de recopilación de reglas contienen cero o más colecciones de reglas. Las colecciones de reglas son NAT, Network o Applications. Puede definir varios tipos de colección de reglas dentro de un único grupo de reglas. Puede definir cero o más reglas en una colección de reglas. Las reglas de una colección de reglas deben ser del mismo tipo (NAT, Red o Aplicación).

El sistema procesa las reglas según la prioridad del grupo de reglas y 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). El sistema procesa primero los grupos de recopilación de reglas de mayor prioridad. Dentro de un grupo de recopilación de reglas, el sistema procesa primero las colecciones de reglas con prioridad más alta (número más bajo).

Si hereda una directiva de firewall de una directiva principal, los grupos de recopilación de reglas de la directiva principal siempre tienen prioridad, independientemente de la prioridad de una directiva secundaria.

Nota:

El sistema siempre procesa las reglas de aplicación después de las reglas de red y procesa las reglas de red después de las reglas DNAT independientemente del grupo de recopilación de reglas o de la prioridad de recopilación de reglas y la herencia de directivas.

Para resumir:

  1. La directiva principal siempre tiene prioridad sobre la directiva secundaria.
  2. El sistema procesa los grupos de recopilación de reglas en orden de prioridad.
  3. El sistema procesa las colecciones de reglas en orden de prioridad.
  4. El sistema procesa las reglas DNAT, después las reglas de red y las reglas de aplicación.

Esta es una directiva de ejemplo con cuatro grupos de recopilación de reglas. BaseRCG1 y BaseRCG2 se heredan de una directiva principal; ChildRCG1 y ChildRCG2 pertenecen a una directiva secundaria.

Sugerencia

Abreviaturas usadas en estas tablas: RCG = grupo de recopilación de reglas, RC = colección de reglas. Los números de prioridad van de 100 (prioridad más alta) a 65 000 (prioridad más baja).

Estructura de directivas:

Level Nombre Tipo Prioridad Reglas Policy
Grupo BaseRCG1 Grupo de colección de reglas 200 8 Parent
Colección DNATRC1 DNAT 600 7 Parent
Colección DNATRC3 DNAT 610 3 Parent
Colección NetworkRC1 Network 800 1 Parent
Grupo BaseRCG2 Grupo de colección de reglas 300 3 Parent
Colección AppRC2 Aplicación 1.200 2 Parent
Colección NetworkRC2 Network 1 300 1 Parent
Grupo ChildRCG1 Grupo de colección de reglas 300 5 Niño
Colección ChNetRC1 Network 700 3 Niño
Colección ChAppRC1 Aplicación 900 2 Niño
Grupo ChildRCG2 Grupo de colección de reglas 650 9 Niño
Colección ChNetRC2 Network 1 100 2 Niño
Colección ChAppRC2 Aplicación 2000 7 Niño
Colección ChDNATRC3 DNAT 3000 2 Niño

El firewall recorre en iteración todos los grupos de recopilación de reglas tres veces: una vez por tipo de regla en orden: DNAT, luego Red y, a continuación, Aplicación. En cada paso, se procesan los grupos en orden de prioridad y luego, las recopilaciones de reglas dentro de cada grupo en orden de prioridad. En la tabla siguiente se muestra la secuencia de procesamiento completa para este ejemplo:

Orden de procesamiento:

Paso Colección de reglas Tipo RCG primario
1 DNATRC1 DNAT BaseRCG1 (200)
2 DNATRC3 DNAT BaseRCG1 (200)
3 ChDNATRC3 DNAT ChildRCG2 (650)
4 NetworkRC1 Network BaseRCG1 (200)
5 NetworkRC2 Network BaseRCG2 (300)
6 ChNetRC1 Network ChildRCG1 (300)
7 ChNetRC2 Network ChildRCG2 (650)
8 AppRC2 Aplicación BaseRCG2 (300)
9 ChAppRC1 Aplicación ChildRCG1 (300)
10 ChAppRC2 Aplicación ChildRCG2 (650)

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

Inteligencia sobre amenazas

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

Sistema de Detección y Prevención de Intrusiones (IDPS)

Al configurar IDPS en modo de alerta , el motor de IDPS funciona en paralelo con la lógica de procesamiento de reglas. Genera alertas sobre las firmas coincidentes para los flujos entrantes y salientes. Para una coincidencia de firma de IDPS, Azure Firewall registra una alerta en los registros de firewall. Sin embargo, dado que el motor IDPS funciona en paralelo con el motor de procesamiento de reglas, el tráfico que la aplicación o las reglas de red deniegan o permitan podrían generar aún otra entrada de registro.

Al configurar IDPS en modo de alerta y denegación , el motor de IDPS funciona en línea y se activa después del motor de procesamiento de reglas. Por lo tanto, ambos motores generan alertas y pueden bloquear los flujos coincidentes.

Las interrupciones de sesión que realiza el IDPS bloquean el flujo de forma silenciosa. Por lo tanto, no se envía ningún RST en el nivel TCP. Puesto que IDPS siempre inspecciona el tráfico después de que la regla de red o aplicación coincida (Permitir o denegar) y se marque en los registros, es posible que se registre otro mensaje drop cuando IDPS decide denegar la sesión debido a una coincidencia de firma.

Al habilitar la inspección de TLS, Azure Firewall inspecciona el tráfico cifrado y sin cifrar.

Compatibilidad con tráfico de retorno implícito (TCP/UDP con estado)

Puede configurar reglas de firewall para permitir el tráfico solo en una dirección. Por ejemplo, Azure Firewall puede permitir que las conexiones que inicie desde una red local a una red virtual de Azure, al tiempo que requieren que se bloqueen nuevas conexiones desde la red virtual de Azure a un entorno local . Para aplicar esta directiva, agregue una regla de denegación explícita para el tráfico desde la red virtual de Azure a la red local .

Azure Firewall admite esta configuración. En Azure Firewall se aplica un seguimiento de estado, por lo que permite el tráfico de retorno en una conexión TCP o UDP establecida (por ejemplo, los paquetes SYN‑ACK/ACK de una conexión que ha iniciado en el entorno local), aunque exista una regla de denegación explícita en la dirección inversa. La regla de denegación explícita sigue bloqueando las nuevas conexiones que se inician desde la red virtual de Azure a un entorno local.

Conectividad de salida

Reglas de red y reglas de aplicación

Si configura reglas de red y reglas de aplicación, Azure Firewall aplica reglas de red en orden de prioridad antes de las reglas de aplicación. Las reglas están terminando. Por lo tanto, si Azure Firewall encuentra una coincidencia en una regla de red, no procesa ninguna otra regla. Si configura IDPS, Azure Firewall lo ejecuta en todo el tráfico recorrido. Cuando IDPS encuentra una coincidencia de firma, puede generar alertas o bloquear tráfico sospechoso, en función del modo IDPS.

Las reglas de aplicación evalúan el paquete en orden de prioridad si no hay ninguna coincidencia de regla de red y si 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. Si hay un desajuste de puerto entre el puerto TCP real y el puerto en el encabezado del host, el firewall bloquea el tráfico. Azure DNS o un DNS personalizado que configure en el firewall permite la resolución de DNS.

Nota:

Azure Firewall siempre rellena los protocolos HTTP y HTTPS (con inspección de TLS) con un encabezado XFF (X-Forwarded-For) configurado con 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, encabezado host y también la dirección URL para que coincida con la regla.

Si Azure Firewall no encuentra una coincidencia dentro de las reglas de aplicación, evalúa el paquete con la colección de reglas de infraestructura. Si Azure Firewall todavía no encuentra ninguna coincidencia, deniega el paquete de forma predeterminada.

Recopilación de reglas de infraestructura

Azure Firewall incluye una colección de reglas integradas para FQDN de infraestructura que están permitidos de forma predeterminada. Estos FQDN son específicos para la plataforma y no se pueden usar para otros fines. La colección de reglas de infraestructura se procesa después de las reglas de aplicación y antes de la regla de denegación total.

La colección de reglas de infraestructura integrada incluye los siguientes servicios:

  • Acceso a recursos de cómputo en el repositorio de imágenes de la plataforma de almacenamiento (PIR)
  • Acceso al almacenamiento del estado de los discos administrados
  • Diagnósticos y registro de eventos de Azure (MDS)

Invalidación de la colección de reglas de infraestructura

Puede anular la colección integrada de reglas de infraestructura creando una colección de reglas de aplicación Denegar todo que se procese en último lugar. Siempre se procesa antes que la colección de reglas de infraestructura. De forma predeterminada, se deniega todo lo que no esté en la colección de reglas de infraestructura.

Nota:

Puede configurar reglas de red para TCP, UDP, ICMP o cualquier protocolo IP. Cualquiera El protocolo IP incluye todos los protocolos IP tal como se definen en el documento Números de protocolo de la Autoridad de números asignados a Internet (IANA). Si configura explícitamente un puerto de destino, la regla se traduce en una regla TCP+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 tiene intención de permitir ningún protocolo IP tal como está definido actualmente, modifique la regla para configurar explícitamente los protocolos que desee (TCP, UDP o ICMP).

Conectividad de entrada

Reglas de DNAT y reglas de red

Puede habilitar la conectividad entrante a Internet o intranet mediante la configuración de traducción de direcciones de red de destino (DNAT), como se describe en Filtrado del tráfico entrante de Internet o intranet con DNAT de Azure Firewall mediante Azure Portal. Las reglas NAT se aplican en prioridad antes de las reglas de red. Si Azure Firewall encuentra una coincidencia, traduce el tráfico según la regla DNAT y 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, añada un origen específico de Internet para permitir el acceso DNAT a la red y evitar el uso de caracteres comodín.

Azure Firewall no aplica reglas de aplicación para las conexiones entrantes. Por lo tanto, si desea filtrar el tráfico HTTP/S entrante, use Firewall de aplicaciones web (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

Se permite la conexión a google.com porque una regla de red coincide.

Regla de red : acción: permitir

Nombre Protocolo Tipo de origen Fuente 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

Nombre Tipo de origen Fuente 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 aquí.

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: Allow

Nombre Protocolo Tipo de origen Fuente 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: Deny

Nombre Protocolo Tipo de origen Fuente 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 mayor prioridad 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, Azure Firewall quita las sesiones existentes pertinentes.

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 permiso de VNet-A a VNet-B no significa que se permitan las conexiones recién iniciadas 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.

Pasos siguientes

  • Last updated on