Preguntas frecuentes sobre Azure Firewall

Azure Firewall es un servicio de seguridad de red administrado y basado en la nube que protege los recursos de Azure Virtual Network. Se trata de un firewall como servicio con estado completo que incorpora alta disponibilidad y escalabilidad a la nube sin restricciones. Puede crear, aplicar y registrar directivas de aplicaciones y de conectividad de red a nivel central en suscripciones y redes virtuales.

Para obtener información sobre las características de Azure Firewall, consulte Características de Azure Firewall.

Puede implementar Azure Firewall en cualquier red virtual, pero los clientes habitualmente lo implementan en una red virtual central y lo emparejan con otras redes virtuales en un modelo de concentrador y radio. A continuación, puede establecer la ruta predeterminada desde las redes virtuales emparejadas para que apunte a esta red virtual de firewall central. Se admite el emparejamiento de VNet global, pero no se recomienda debido a posibles problemas de rendimiento y latencia entre regiones. Para obtener el mejor rendimiento, implemente un firewall por región.

La ventaja de este modelo es la posibilidad de ejercer control centralizado sobre varias redes virtuales de radio en distintas suscripciones. También hay un ahorro en los costos, ya que no es necesario implementar un firewall en cada red virtual por separado. Este ahorro se debe medir frente al costo de emparejamiento asociado basado en los patrones de tráfico del cliente.

Puede configurar Azure Firewall mediante Azure Portal, PowerShell, API REST o a través del uso de plantillas. Consulte Tutorial: Implementación y configuración de Azure Firewall mediante Azure Portal para obtener instrucciones detalladas.

Azure Firewall es compatible con las reglas y las colecciones de reglas. Una colección de reglas es una lista de reglas que comparten el mismo orden y prioridad. Las colecciones de reglas se ejecutan en su orden de prioridad. Las colecciones de reglas de DNAT son colecciones de reglas de red con una prioridad más alta que las de aplicación, y todas las reglas provocan la terminación.

Hay tres tipos de colecciones de reglas:

• Reglas de aplicación: configurar los nombres de dominio completo (FQDN) a los que se puede acceder desde una red virtual.
• Reglas de red: configurar reglas que contienen direcciones de origen, protocolos, puertos de destino y direcciones de destino.
• Reglas NAT: Configure reglas DNAT para permitir conexiones entrantes de Internet o intranet (versión preliminar).

Para más información, veaConfiguración de reglas de Azure Firewall.

Azure Firewall es compatible con el filtrado entrante y saliente. La protección de entrada se usa normalmente para protocolos que no son HTTP, como protocolos RDP, SSH y FTP. Para la protección HTTP y HTTPS de entrada, use un firewall de aplicaciones web como Azure Web Application Firewall (WAF) o las funcionalidades de descarga de TLS e inspección profunda de paquetes de Azure Firewall Premium.

Sí, Azure Firewall Básico admite la tunelización forzada.

Azure Firewall se integra con Azure Monitor para ver y analizar los registros de firewall. Los registros se pueden enviar a Log Analytics, Azure Storage o Event Hubs. Puede analizarse en Log Analytics o usando distintas herramientas, como Excel y Power BI. Para más información, consulte el Tutorial: Supervisión de los registros de Azure Firewall.

Azure Firewall es un servicio de seguridad de red administrado y basado en la nube que protege los recursos de la red virtual. Se trata de un firewall como servicio con estado completo que incorpora alta disponibilidad y escalabilidad a la nube sin restricciones. Se integra previamente con proveedores de seguridad como servicio (SECaaS) de terceros para proporcionar seguridad avanzada para las conexiones a Internet de la red virtual y las ramas. Para más información sobre la seguridad de red de Azure, consulte Seguridad de red de Azure.

Firewall de aplicaciones web (WAF) es una característica de Application Gateway que proporciona a las aplicaciones una protección de entrada centralizada contra ataques y puntos vulnerables comunes. Azure Firewall proporciona protección de entrada para protocolos no HTTP/S (como RDP, SSH y FTP), protección de salida a nivel de red para todos los puertos y protocolos, y protección a nivel de aplicación para las salidas HTTP/S.

El servicio Azure Firewall complementa la funcionalidad de grupo de seguridad de red. Juntos proporcionan una mejor seguridad de red de "defensa en profundidad". Los grupos de seguridad de red proporcionan filtrado del trafico de capas de red distribuida para limitar el tráfico a los recursos dentro de las redes virtuales en cada suscripción. Azure Firewall es un firewall de red centralizada como servicio con estado completo que proporciona protección a nivel de red y de aplicación en todas las distintas suscripciones y redes virtuales.

Azure Firewall es un servicio administrado con varias capas de protección, como la protección de la plataforma con NSG de nivel de NIC (no visible). Los NSG no son obligatorios en AzureFirewallSubnet y están deshabilitados para garantizar que no se produzcan interrupciones en el servicio.

Para un acceso seguro a los servicios de PaaS, se recomiendan los puntos de conexión de servicio. Puede elegir habilitar puntos de conexión de servicio en la subred de Azure Firewall y deshabilitarlos en las redes virtuales de radios conectadas. De este modo se beneficia de ambas características: la seguridad de los puntos de conexión y el registro central de todo el tráfico.

Consulte Precios de Azure Firewall.

Puede usar los métodos deallocate y allocate de Azure PowerShell. En el caso de un firewall configurado para la tunelización forzada, el procedimiento es ligeramente diferente.

Por ejemplo, para un firewall configurado con la NIC de administración NO habilitada:

# Stop an existing firewall

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$publicip1 = Get-AzPublicIpAddress -Name "Public IP1 Name" -ResourceGroupName "RG Name"
$publicip2 = Get-AzPublicIpAddress -Name "Public IP2 Name" -ResourceGroupName "RG Name"
$azfw.Allocate($vnet,@($publicip1,$publicip2))

Set-AzFirewall -AzureFirewall $azfw

Para un firewall configurado con la NIC de administración habilitada, la detención es la misma. Pero para el inicio, es necesario volver a asociar la dirección IP pública de administración al firewall:

# Stop an existing firewall

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip= Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip2 = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip2)
$azfw | Set-AzFirewall

En el caso de un firewall que esté en una arquitectura de centro virtual protegido, la detención es la misma, pero el inicio debe usar el Id. del centro virtual:

# Stop and existing firewall

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall

$virtualhub = get-azvirtualhub -ResourceGroupName "RG name of vHUB" -name "vHUB name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Azfw RG Name"
$azfw.Allocate($virtualhub.Id)
$azfw | Set-AzFirewall

Cuando se asigna y desasigna un firewall, la facturación se detiene y se inicia en consecuencia.

La recomendación es configurar zonas de disponibilidad durante la implementación inicial del firewall. Sin embargo, en algunos casos es posible cambiar las zonas de disponibilidad después de la implementación. Los requisitos previos son:

• El firewall se implementa en una red virtual. No se admite con firewalls implementados en un centro virtual protegido.
• La región del firewall admite zonas de disponibilidad.
• Todas las direcciones IP públicas asociadas se implementan con zonas de disponibilidad. En la página de propiedades de cada dirección IP pública, asegúrese de que el campo zonas de disponibilidad existe y esté configurado con las mismas zonas que configuró para el firewall.

La reconfiguración de zonas de disponibilidad solo se puede realizar al reiniciar el firewall. Después de asignar el firewall y justo antes de iniciar el firewall con Set-AzFirewall, use el siguiente Azure PowerShell para modificar la propiedad Zonas del firewall:

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip= Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip2 = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip2)
$azFw.Zones=1,2,3
$azfw | Set-AzFirewall

Para ver los límites del servicio Azure Firewall, consulte Suscripción de Azure y límites de servicio, cuotas y restricciones.

Sí, puede usar Azure Firewall en una red virtual de concentrador para enrutar y filtrar el tráfico entre varias redes virtuales de radio. Las subredes de cada una de las redes virtuales de radio deben tener una ruta definida por el usuario (UDR) que apunte a la instancia de Azure Firewall como puerta de enlace predeterminada para que este escenario funcione correctamente.

Sí. Sin embargo, es necesario prestar más atención al configurar las UDR para redirigir el tráfico entre subredes de la misma red virtual. Aunque basta con usar el intervalo de direcciones de red virtual como prefijo de destino para la UDR, también se enruta todo el tráfico de una máquina a otra de la misma subred mediante la instancia de Azure Firewall. Para evitar este problema, incluya una ruta para la subred en la UDR con un tipo de próximo salto VNET. La administración de estas rutas podría ser problemática y estar sujeta a errores. El método recomendado para la segmentación de redes internas es usar grupos de seguridad de red, que no necesitan UDR.

Azure Firewall no aplica SNAT cuando la dirección IP de destino es un intervalo IP privado por IANA RFC 1918 o IANA RFC 6598 para redes privadas. Si su organización usa un intervalo de direcciones IP públicas para las redes privadas, Azure Firewall aplicará SNAT al tráfico para una de las direcciones IP privadas de firewall en AzureFirewallSubnet. Puede configurar Azure Firewall de modo que no aplique SNAT al intervalo de direcciones IP públicas. Para más información, consulte Aplicación de SNAT por parte de Azure Firewall a intervalos de direcciones IP privadas.

Además, al tráfico que procesan las reglas de aplicación siempre se le aplica SNAT. Si desea ver la dirección IP inicial del origen en los registros de tráfico de FQDN, puede usar reglas de red con el FQDN de destino.

La tunelización forzada se admite cuando se crea un nuevo Firewall. No se puede configurar un firewall existente para la tunelización forzada. Para más información, consulte Tunelización forzada de Azure Firewall.

Azure Firewall debe tener conectividad directa a Internet. Si AzureFirewallSubnet aprende una ruta predeterminada a la red local mediante BGP, debe reemplazarla por una UDR 0.0.0.0/0 con el valor NextHopType establecido como Internet para mantener la conectividad directa a Internet.

Si la configuración requiere tunelización forzada a una red local y puede determinar los prefijos de las direcciones IP de destino de los destinos de Internet, puede configurar estos intervalos con la red local como el próximo salto mediante una ruta definida por el usuario en AzureFirewallSubnet. O bien, puede usar BGP para definir estas rutas.

Sí.

• El firewall y la red virtual deben estar en el mismo grupo de recursos.
• La dirección IP pública puede estar en cualquier grupo de recursos.
• El firewall, la red virtual y la dirección IP pública deben estar en la misma suscripción.

• Dirección URL: los asteriscos funcionan cuando se sitúan en el extremo derecho o en el extremo izquierdo. Si un asterisco está a la izquierda, no puede formar parte del FQDN.
• FQDN: los asteriscos funcionan cuando se ponen en el extremo izquierdo.
• GENERAL: los asteriscos del lado izquierdo significan literalmente que cualquier cosa a la izquierda coincide, lo que significa que coinciden varios subdominios o variaciones de nombres de dominio potencialmente no deseados; vea los ejemplos siguientes.

Ejemplos:

Cada vez que se aplique un cambio de configuración, Azure Firewall intenta actualizar todas sus instancias de back-end subyacentes. En raras ocasiones, una de estas instancias de back-end puede producir un error al actualizar con la nueva configuración y el proceso de actualización se detiene con un estado de aprovisionamiento con error. Azure Firewall todavía está operativo, pero es posible que la configuración aplicada se encuentre en un estado incoherente, donde algunas instancias tienen la configuración anterior y otras tienen el conjunto de reglas actualizado. Si esto sucede, intente actualizar la configuración una vez más, hasta que la operación se realice correctamente y el firewall se encuentre en un estado de aprovisionamiento Correcto.

Azure Firewall consta de varios nodos de back-end en una configuración activo-activo. Para cualquier mantenimiento planeado, se dispone de lógica de purga de la conexión para actualizar los nodos correctamente. Las actualizaciones se planean durante el horario no comercial de cada una de las regiones de Azure para limitar aún más el riesgo de interrupción. Si surgen problemas imprevistos, se crea una instancia de un nuevo nodo para reemplazar el nodo con errores. Normalmente, la conectividad con el nuevo nodo se restablece en 10 segundos desde el momento en que se produjo el error.

Para cualquier mantenimiento planeado, la lógica de purga de conexiones actualiza los nodos de back-end correctamente. Azure Firewall espera 90 segundos para que se cierren las conexiones existentes. En los primeros 45 segundos, el nodo de back-end no acepta nuevas conexiones y, en el tiempo restante, responde con RST a todos los paquetes entrantes. Si es necesario, los clientes pueden volver a establecer la conectividad automáticamente con otro nodo de back-end.

Sí. Hay un límite de 50 caracteres para un nombre de firewall.

Azure Firewall debe aprovisionar más instancias de máquinas virtuales a medida que se escalan. Un espacio de direcciones /26 garantiza que el firewall tiene suficientes direcciones IP disponibles para acomodar el escalado.

No. Azure Firewall no necesita una subred mayor que /26.

La capacidad de rendimiento inicial de Azure Firewall es de 2,5 a 3 Gbps y se escala horizontalmente a 30 Gbps para la SKU Estándar y 100 Gbps para la SKU Premium. Se escala horizontalmente de manera automática en función del uso de CPU, el rendimiento y el número de conexiones.

Azure Firewall se escala gradualmente cuando el rendimiento medio o el consumo de CPU es del 60 %, o bien el número de uso de conexiones es del 80 %. Por ejemplo, comienza a escalar horizontalmente cuando alcanza el 60 % de su rendimiento máximo. Los números de rendimiento máximo varían en función de la SKU del firewall y de las características habilitadas. Para más información, consulte Rendimiento de Azure Firewall.

El escalado horizontal tarda entre cinco y siete minutos.

Cuando realice pruebas de rendimiento, asegúrese de que lleva a cabo una prueba de 10 a 15 minutos como mínimo e inicie nuevas conexiones para aprovechar los nodos de Firewall recién creados.

Cuando una conexión agota el tiempo de espera de inactividad (cuatro minutos sin actividad), Azure Firewall envía un paquete RST de TCP para finalizar correctamente la conexión.

El apagado de una instancia de máquina virtual de Azure Firewall puede producirse cuando se reduce horizontal o verticalmente un conjunto de escalado de máquinas virtuales o durante una actualización de software. En estos casos, se equilibra la carga de las nuevas conexiones entrantes en las instancias de firewall restantes y no se reenvían a la instancia de firewall apagada. Después de 45 segundos, el firewall comienza a rechazar las conexiones establecidas mediante el envío de paquetes RST de TCP. Después de otros 45 segundos, la máquina virtual del firewall se apaga. Para obtener más información, vea Tiempo de espera de inactividad y restablecimiento de TCP de Load Balancer.

No. Azure Firewall bloquea el acceso a Active Directory de forma predeterminada. Para permitir el acceso, configure la etiqueta de servicio AzureActiveDirectory. Para más información, consulte Etiquetas de servicio de Azure Firewall.

Sí, puede usar Azure PowerShell para ello:

# Add a Threat Intelligence allowlist to an Existing Azure Firewall.

# Create the allowlist with both FQDN and IPAddresses
$fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"
$fw.ThreatIntelWhitelist = New-AzFirewallThreatIntelWhitelist `
   -FQDN @("fqdn1", "fqdn2", …) -IpAddress @("ip1", "ip2", …)

# Or Update FQDNs and IpAddresses separately
$fw = Get-AzFirewall -Name $firewallname -ResourceGroupName $RG
$fw.ThreatIntelWhitelist.IpAddresses = @($fw.ThreatIntelWhitelist.IpAddresses + $ipaddresses)
$fw.ThreatIntelWhitelist.fqdns = @($fw.ThreatIntelWhitelist.fqdns + $fqdns)


Set-AzFirewall -AzureFirewall $fw

Un ping de TCP no se conecta realmente al FQDN de destino. Azure Firewall no permite una conexión a ninguna dirección IP o FQDN de destino a menos que haya una regla explícita que lo permita.

El ping TCP es un caso de uso único en el que, si no hay ninguna regla permitida, el propio firewall responde a la solicitud de ping TCP del cliente aunque el ping TCP no llegue a la dirección IP o FQDN de destino. En este caso, el evento no se registra. Si hay una regla de red que permite el acceso a la dirección IP o FQDN de destino, la solicitud de ping llega al servidor de destino y su respuesta se retransmite de nuevo al cliente. Este evento se registra en el registro de reglas de red.

Sí. Para más información, consulte Límites, cuotas y restricciones de suscripción y servicios de Microsoft Azure.

No, actualmente no se permite mover un grupo de direcciones IP a otro grupo de recursos.

Un comportamiento estándar de un firewall de red es asegurarse de que las conexiones TCP se mantengan activas y cerrarlas de inmediato si no hay ninguna actividad. El tiempo de espera de inactividad de TCP de Azure Firewall es de cuatro minutos. Esta configuración no es configurable por el usuario, pero puede ponerse en contacto con el Soporte técnico de Azure para aumentar el tiempo de espera de inactividad para las conexiones entrantes y salientes hasta 15 minutos. No se puede cambiar el tiempo de espera de inactividad para el tráfico horizontal de derecha a izquierda.

Si un período de inactividad es mayor que el valor de tiempo de espera, no hay ninguna garantía de que todavía exista la sesión TCP o HTTP. Una práctica común es usar TCP Keep-alive. Esta práctica mantiene la conexión activa durante un periodo más largo. Para más información, consulte estos ejemplos de .NET.

Sí, pero debe configurar el firewall en modo de tunelización forzada. Esta configuración crea una interfaz de administración con una dirección IP pública que usa Azure Firewall para sus operaciones. Esta IP pública es para el tráfico de administración. Se usa exclusivamente en la plataforma Azure y no puede usarse para ningún otro propósito. La red de la ruta de acceso a los datos de inquilino se puede configurar sin una dirección IP pública y el tráfico de Internet se puede tunelizar de manera forzada a otro firewall o bloquearse completamente.

Azure Firewall no mueve ni almacena los datos de los clientes fuera de la región en los que se implementan.

Sí. Para obtener más información, consulte Copia de seguridad de Azure Firewall y de la directiva de Azure Firewall con Logic Apps.

No, actualmente, no se admite Azure Firewall en centros virtuales protegidos (vWAN) en Qatar.

Azure Firewall usa Azure Virtual Machines debajo de que tienen un número de conexiones de límite máximo. El número total de conexiones activas por máquina virtual es de 250 000.

El límite total por firewall es el límite de conexión de la máquina virtual (250 000) x el número de máquinas virtuales del grupo de back-end del firewall. Azure Firewall comienza con dos máquinas virtuales y se escala horizontalmente en función del uso y el rendimiento de la CPU.

Azure Firewall utiliza actualmente puertos de origen TCP/UDP para el tráfico SNAT saliente, sin tiempo de espera inactivo. Cuando se cierra una conexión TCP/UDP, el puerto TCP utilizado se ve inmediatamente como disponible para próximas conexiones.

Como solución alternativa para determinadas arquitecturas, puede implementar y escalar con NAT Gateway con Azure Firewall para proporcionar un conjunto más amplio de puertos SNAT para mayor variabilidad y disponibilidad.

Los comportamientos de NAT específicos dependen de la configuración del firewall y del tipo de NAT configurado. Por ejemplo, el firewall tiene reglas DNAT para el tráfico entrante y reglas de red y reglas de aplicación para el tráfico saliente a través del firewall.

Para más información, consulte Comportamientos NAT de Azure Firewall.