¿Qué es Azure Firewall?

Azure Firewall es un servicio de seguridad de firewall de red inteligente y nativo de la nube que le proporciona la mejor protección contra amenazas para las cargas de trabajo en la nube que se ejecutan en Azure. Se trata de un firewall como servicio con estado completo que incorpora alta disponibilidad y escalabilidad en la nube sin restricciones. Asimismo, proporciona la opción de realizar la inspección del tráfico de este a oeste y de norte a sur.

Azure Firewall se ofrece en tres SKU: Estándar, Prémium y Básico.

Azure Firewall Estándar

Azure Firewall Estándar proporciona fuentes de inteligencia sobre amenazas y filtrado L3-L7 directamente desde Microsoft Cyber Security. El filtrado basado en la inteligencia sobre amenazas puede enviar alertas y denegar el tráfico desde o hacia dominios y direcciones IP malintencionados, que sean conocidos y que se actualicen en tiempo real para protegerle frente a ataques nuevos y emergentes.

Introducción al estándar de firewall

Para obtener información sobre las características estándar del firewall, consulte las características estándar de Azure Firewall.

Azure Firewall Prémium

Azure Firewall Premium proporciona funcionalidades avanzadas que incluyen IDPS basados en firmas para permitir la detección rápida de ataques mediante la búsqueda de patrones específicos. Estos patrones pueden incluir secuencias de bytes en el tráfico de red o secuencias de instrucciones malintencionadas conocidas y que use el malware. Existen más de 58 000 firmas en más de 50 categorías que se actualizan en tiempo real para protegerle contra vulnerabilidades nuevas y emergentes. Las categorías de vulnerabilidades de seguridad incluyen malware, suplantación de identidad, minería de monedas y ataques de troyanos.

Información general del firewall Premium

Para obtener más información sobre las características del firewall Premium, consulte Características de Azure Firewall Premium.

Azure Firewall Básico (versión preliminar)

Importante

Azure Firewall básico se encuentra actualmente en VERSIÓN PRELIMINAR. Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure para conocer los términos legales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general.

Azure Firewall Básico está pensado para que los clientes pymes protejan sus entornos en la nube de Azure. Proporciona la protección esencial que los clientes pymes necesitan a un precio asequible.

Diagrama que muestra Azure Firewall Básico.

Azure Firewall Básico es similar a Firewall Estándar, pero tiene las siguientes limitaciones:

  • Solo admite el modo de alerta de Intel para amenazas.
  • Se ha corregido la unidad de escalado para que el servicio se ejecute en dos instancias de back-end de máquina virtual.
  • Se recomienda para entornos con un rendimiento máximo de 250 Mbps. El rendimiento puede aumentar para la disponibilidad general de características (GA).

Regiones admitidas

Azure Firewall Básico está disponible en las siguientes regiones durante la versión preliminar:

  • Este de EE. UU.
  • Este de EE. UU. 2
  • Oeste de EE. UU.
  • Oeste de EE. UU. 2
  • Oeste de EE. UU. 3
  • Centro de EE. UU.
  • Centro-Norte de EE. UU
  • Centro-sur de EE. UU.
  • Centro-Oeste de EE. UU.
  • EUAP de Este de EE. UU. 2
  • EUAP del centro de EE. UU.
  • Norte de Europa
  • Oeste de Europa
  • Este de Asia
  • Sudeste de Asia
  • Japón Oriental
  • Japón Occidental
  • Este de Australia
  • Sudeste de Australia
  • Centro de Australia
  • Sur de Brasil
  • Sur de la India
  • Centro de la India
  • Oeste de la India
  • Centro de Canadá
  • Este de Canadá
  • Sur de Reino Unido
  • Oeste de Reino Unido
  • Centro de Corea del Sur
  • Corea del Sur
  • Centro de Francia
  • Norte de Sudáfrica
  • Norte de Emiratos Árabes Unidos
  • Norte de Suiza
  • Centro-oeste de Alemania
  • Este de Noruega
  • JIO del Oeste de la India
  • Centro de Suecia
  • Centro de Catar

Para implementar Azure Firewall Básico, consulte Implementación y configuración de Azure Firewall Básico (versión preliminar) y una directiva mediante Azure Portal.

Azure Firewall Manager

Puede usar Azure Firewall Manager para administrar de forma centralizada las instancias de Azure Firewall en varias suscripciones. Firewall Manager aprovecha la directiva de firewall para aplicar un conjunto común de reglas de red o aplicaciones y la configuración a los firewalls del inquilino.

Firewall Manager admite firewalls en entornos de redes virtuales y redes de Virtual WAN (Centro virtual seguro). Los centros virtuales usan la solución de automatización de rutas de Virtual WAN para simplificar el enrutamiento del tráfico al firewall con unos pocos pasos.

Para obtener más información sobre Azure Firewall Manager, consulte Azure Firewall Manager.

Precios y contrato de nivel de servicio

Para obtener información de los precios de Azure Firewall, consulte Precios de Azure Firewall.

Para obtener información del Acuerdo de Nivel de Servicio de Azure Firewall, consulte SLA para Azure Firewall.

Regiones admitidas

Para ver las regiones admitidas para Azure Firewall, consulte Productos de Azure disponibles por región.

Novedades

Para obtener información sobre las novedades de Azure Firewall, consulte Actualizaciones de Azure.

Problemas conocidos

Azure Firewall Estándar

Azure Firewall Estándar presenta los siguientes problemas conocidos:

Nota:

Cualquier problema que se aplique a Estándar también se aplica a Premium.

Problema Descripción Mitigación
Las reglas de filtrado de red para protocolos que no son TCP/UDP (por ejemplo, ICMP) no funcionan con el tráfico enlazado a Internet Las reglas de filtrado de red de protocolos que no son TCP/UDP no funcionan con la traducción SNAT a la dirección IP pública. Los protocolos que no son TCP/UDP no se admiten entre subredes de radio y redes virtuales. Azure Firewall usa Standard Load Balancer, que actualmente no admite SNAT para los protocolos IP. Se están examinando opciones para admitir este escenario en una versión futura.
Falta de compatibilidad entre PowerShell y CLI con ICMP Azure PowerShell y la CLI no admiten ICMP como protocolo válido en las reglas de red. Aun así se puede usar ICMP como protocolo a través del portal y la API REST. Estamos trabajando para agregar pronto ICMP a PowerShell y la CLI.
Las etiquetas FQDN requieren que se establezca una combinación protocolo: puerto Las reglas de aplicaciones con las etiquetas FQDN requieren la definición de puerto: protocolo. Puede usar https como valor de puerto: protocolo. Estamos trabajando para que este campo sea opcional cuando se usen etiquetas FQDN.
No se admite la posibilidad de mover un firewall a otro grupo de recursos o suscripción. No se admite la posibilidad de mover un firewall a otro grupo de recursos o suscripción. La compatibilidad con esta funcionalidad está en nuestro mapa de ruta. Para mover un firewall a otro un grupo de recursos o suscripción, debe eliminar la instancia actual y volver a crearla en el nuevo grupo de recursos o suscripción.
Las alertas de inteligencia sobre amenazas pueden estar enmascaradas Reglas de red con destino 80/443 para las alertas de inteligencia sobre amenazas de las máscaras de filtrado de salida cuando la configuración está establecida en el modo de solo alerta. Cree filtrado de salida para 80/443 mediante reglas de aplicaciones. También puede cambiar el modo de inteligencia sobre amenazas a Alertar y denegar.
DNAT de Azure Firewall no funciona para destinos de IP privadas La compatibilidad con DNAT de Azure Firewall se limita a la entrada/salida de Internet. DNAT no funciona actualmente con destinos de IP privada. Por ejemplo, radio a radio. Se trata de una limitación actual.
Availability Zones solo se puede configurar durante la implementación. Availability Zones solo se puede configurar durante la implementación. No se puede configurar una vez implementado un firewall. es así por diseño.
SNAT en conexiones entrantes Además de DNAT, en las conexiones mediante la dirección IP pública del firewall (entrante) se aplica SNAT en una de las direcciones IP privadas del firewall. Este requisito hoy en día (también para aplicaciones virtuales de red activa/activa) es para garantizar el enrutamiento simétrico. Para conservar el código fuente original para HTTP/S, considere el uso de encabezados XFF. Por ejemplo, use un servicio como Azure Front Door o Azure Application Gateway delante del firewall. También puede agregar WAF como parte de Azure Front Door Service y la cadena al firewall.
El filtrado por nombre de dominio completo de SQL se admite solo en modo de proxy (puerto 1433) Para Azure SQL Database, Azure Synapse Analytics y Azure SQL Managed Instance:

El filtrado por nombre de dominio completo de SQL se admite solo en modo de proxy (puerto 1433).

Para IaaS de Azure SQL:

Si va a usar puertos que no son los estándar, puede especificar esos puertos en las reglas de la aplicación.
Para SQL en modo de redirección (el valor predeterminado si se conecta desde dentro de Azure), puede filtrar en su lugar el acceso mediante la etiqueta de servicio de SQL como parte de las reglas de red de Azure Firewall.
El tráfico SMTP de salida del puerto TCP 25 está bloqueado La plataforma de Azure puede bloquear los mensajes de correo electrónico salientes que se envían directamente a dominios externos (como outlook.com y gmail.com) en el puerto TCP 25. Este es el comportamiento predeterminado de la plataforma en Azure, Azure Firewall no introduce ninguna restricción específica adicional. Use servicios de retransmisión SMTP autenticados, que normalmente se conectan a través del puerto TCP 587, pero también admiten otros puertos. Para más información, consulte Solución de problemas de conectividad SMTP saliente en Azure. Actualmente, Azure Firewall puede comunicarse con IP públicas mediante el puerto TCP 25 de salida, pero no se garantiza que funcione y no se admite en todos los tipos de suscripción. En el caso de las IP privadas, como redes virtuales, VPN y Azure ExpressRoute, Azure Firewall admite una conexión saliente del puerto TCP 25.
Agotamiento de puertos SNAT Azure Firewall admite actualmente 2496 puertos por cada dirección IP pública por cada instancia de conjunto de escalado de máquinas virtuales de back-end. De manera predeterminada, hay dos instancias de conjunto de escalado de máquinas virtuales. Por lo tanto, hay 4992 puertos por flujo (IP de destino, puerto de destino y protocolo (TCP o UDP). El firewall se escala verticalmente hasta un máximo de 20 instancias. Se trata de una limitación de la plataforma. Como solución alternativa para los límites, puede configurar las implementaciones de Azure Firewall con un mínimo de cinco direcciones IP públicas para implementaciones susceptibles de agotamiento de SNAT. Esto aumenta cinco veces los puertos SNAT disponibles. Realice la asignación desde un prefijo de dirección IP para simplificar los permisos del flujo descendente. Para una solución más permanente, puede implementar una puerta de enlace NAT para superar los límites de puertos SNAT. Este enfoque es compatible con las implementaciones de red virtual.

Para más información, consulte Escalado de puertos SNAT con Azure Virtual Network NAT.
DNAT no es compatible con la tunelización forzada habilitada Los firewalls implementados con la tunelización forzada habilitada no admiten el acceso entrante desde Internet debido al enrutamiento asimétrico. Esto es así por diseño. La ruta de acceso de retorno de las conexiones entrantes pasa por el firewall local, que no ha visto la conexión establecida.
Es posible que el FTP pasivo saliente no funcione en firewalls con varias direcciones IP públicas, en función de la configuración del servidor FTP. FTP pasivo establece distintas conexiones para los canales de control y datos. Cuando un firewall con varias direcciones IP públicas envía datos de salida, selecciona de manera aleatoria una de sus direcciones IP públicas como dirección IP de origen. FTP puede generar un error cuando los canales de control y de datos usan direcciones IP de origen diferentes, en función de la configuración del servidor FTP. Está previsto una configuración de SNAT explícita. Entretanto, puede configurar el servidor FTP para que acepte los canales de control y de datos de distintas direcciones IP de origen (vea un ejemplo de IIS). Otra opción es usar una única dirección IP en esta situación.
Es posible que el FTP pasivo entrante no funcione en función de la configuración del servidor FTP FTP pasivo establece distintas conexiones para los canales de control y datos. En las conexiones entrantes de Azure Firewall se aplica SNAT a una de las direcciones IP privadas del firewall para garantizar el enrutamiento simétrico. FTP puede generar un error cuando los canales de control y de datos usan direcciones IP de origen diferentes, en función de la configuración del servidor FTP. Se está investigando la conservación de la dirección IP de origen original. Entretanto, puede configurar el servidor FTP para que acepte los canales de control y de datos de distintas direcciones IP de origen.
FTP activo no funcionará cuando el cliente FTP deba acceder a un servidor FTP mediante Internet. FTP activo usa un comando PORT del cliente FTP que indica al servidor FTP qué dirección IP y puerto usar para el canal de datos. Este comando PORT usa la dirección IP privada del cliente, que no se puede cambiar. El tráfico del lado cliente que recorre Azure Firewall será tráfico con NAT para las comunicaciones basadas en Internet, por lo que el servidor FTP considera el comando PORT como no válido. Se trata de una limitación general del FTP activo cuando se usa con una NAT del lado del cliente.
Falta una dimensión de protocolo en la métrica NetworkRuleHit La métrica ApplicationRuleHit permite el filtrado basado en el protocolo, pero esta funcionalidad falta en la métrica NetworkRuleHit correspondiente. Se está investigando una solución.
No se admiten las reglas NAT con puertos entre el 64000 y el 65535 Azure Firewall permite cualquier puerto en el rango 1-65535 en reglas de red y de aplicación; sin embargo, las reglas NAT solo admiten los puertos del rango 1-63999. Se trata de una limitación actual.
Las actualizaciones de configuración pueden tardar cinco minutos por término medio. Una actualización de la configuración de Azure Firewall puede tardar entre tres y cinco minutos por término medio, y no se admiten actualizaciones en paralelo. Se está investigando una solución.
Azure Firewall usa encabezados TLS SNI para filtrar el tráfico HTTPS y MSSQL Si el software del explorador o servidor no admite la extensión Server Name Indicator (SNI), no será posible conectarse mediante Azure Firewall. Si el software de explorador o servidor no admite SNI, es posible que pueda controlar la conexión mediante una regla de red, en lugar de una regla de aplicación. Consulte Indicación de nombre de servidor para conocer el software que admite SNI.
No se pueden agregar etiquetas de directiva de firewall mediante el portal ni mediante plantillas de Azure Resource Manager (ARM) La directiva de Azure Firewall tiene una limitación de compatibilidad de revisión que impide agregar una etiqueta mediante Azure Portal ni mediante plantillas de ARM. Se genera el siguiente error: No se pudieron guardar las etiquetas del recurso. Se está investigando una solución. O bien, puede usar el cmdlet de Azure PowerShell Set-AzFirewallPolicy para actualizar las etiquetas.
Actualmente, no se admite IPv6. Si agrega una dirección IPv6 a una regla, se produce un error en el firewall. Use solo direcciones IPv4. La compatibilidad con IPv6 está en proceso de investigación.
La actualización de varios grupos de IP produce un error de conflicto. Cuando se actualizan dos o más grupos de IP conectados al mismo firewall, uno de los recursos entra en estado de error. Es un problema conocido, una limitación.

Al actualizar un grupo de IP, se desencadena una actualización en todos los firewalls a los que está conectado el grupo de IP. Si se inicia una actualización en un segundo grupo de IP con el firewall aún en estado Actualizando, se produce un error en la actualización del grupo de IP.

Para evitar el error, los grupos de IP conectados al mismo firewall se deben actualizar de uno en uno. Deje tiempo suficiente entre las actualizaciones para que el firewall pueda salir del estado Actualizando.
No se admite la eliminación de elementos RuleCollectionGroup mediante plantillas de ARM. No se admite la eliminación de elementos RuleCollectionGroup mediante plantillas de ARM y se produce un error. Esta no es una operación admitida.
La regla DNAT para permitir cualquiera (*) permitirá el tráfico SNAT. Si una regla DNAT permite cualquiera (*) como dirección IP de origen, una regla de red implícita coincidirá con el tráfico de red virtual a red virtual, y siempre transmitirá el tráfico mediante SNAT. Se trata de una limitación actual.
No se admite la adición de una regla DNAT a un centro virtual protegido con un proveedor de seguridad. Esto da como resultado una ruta asincrónica para el tráfico DNAT de vuelta, que va al proveedor de seguridad. No compatible.
Error al crear más de 2000 colecciones de reglas. El número máximo de colecciones de reglas de NAT/aplicación o red es 2000 (límite de Resource Manager). Se trata de una limitación actual.
No se puede ver el nombre de la regla de red en los registros de Azure Firewall Los datos de registro de reglas de red de Azure Firewall no muestran el nombre de la regla para el tráfico de red. El registro de nombres de reglas de red se encuentra en versión preliminar. Para más información, consulte Características de la versión preliminar de Azure Firewall.
Encabezado XFF en HTTP/S Los encabezados XFF se sobrescriben con la dirección IP de origen original, tal como se administra en el firewall. Esto es aplicable a los siguientes casos de uso:
- Solicitudes HTTP
- Solicitudes HTTPS con terminación TLS
Se está investigando una solución.
No se puede actualizar a Premium con Availability Zones en la región Sudeste Asiático. Actualmente no se puede actualizar a Azure Firewall Premium con Availability Zones en la región del Sudeste Asiático. Implemente un nuevo firewall Premium en el Sudeste Asiático sin Availability Zones o impleméntelo en una región que admita Availability Zones.
No se puede implementar el firewall con Availability Zones con una dirección IP pública recién creada. Al implementar un firewall con Availability Zones, no se puede usar una dirección IP pública recién creada. En primer lugar, cree una nueva dirección IP pública con redundancia de zona y, a continuación, asigne esta dirección IP creada previamente durante la implementación del firewall.
La zona DNS privada de Azure no es compatible con Azure Firewall La zona DNS privada de Azure no funcionará con Azure Firewall independientemente de la configuración de DNS de Azure Firewall. Para lograr el estado necesario de uso de un servidor DNS privado, use el proxy de DNS de Azure Firewall en lugar de una zona DNS privada de Azure.

Azure Firewall Prémium

Azure Firewall Premium presenta los siguientes problemas conocidos:

Problema Descripción Mitigación
Compatibilidad de ESNI con la resolución de nombres de dominio completo en HTTPS Indicación de nombre de servidor cifrada no se admite en el protocolo de enlace HTTPS. Actualmente, solo Firefox admite ESNI a través de la configuración personalizada. La solución que se recomienda es deshabilitar esta característica.
No se admite la autenticación de certificación de cliente Los certificados de cliente se usan para crear una confianza de identidad mutua entre el cliente y el servidor. Los certificados de cliente se usan durante una negociación de TLS. Azure Firewall vuelve a negociar una conexión con el servidor y no tiene acceso a la clave privada de los certificados de cliente. None
QUIC/HTTP3 QUIC es la nueva versión principal de HTTP. Es un protocolo basado en UDP a través de los puertos 80 (PLAN) y 443 (SSL). No se admitirá la inspección de FQDN/URL/TLS. Configure el uso de UDP 80/443 como reglas de red.
Certificados firmados por clientes que no son de confianza El firewall no confía en los certificados firmados por el cliente una vez que se han recibido de un servidor web basado en intranet. Se está investigando una solución.
Dirección IP de origen incorrecta en las alertas con IDPS para HTTP (sin inspección de TLS). Cuando el tráfico HTTP de texto sin formato está en uso e IDPS emite una nueva alerta y el destino es una dirección IP pública, la dirección IP de origen que se muestra es incorrecta (se muestra la dirección IP interna, en lugar de la dirección IP original). Se está investigando una solución.
Propagación de certificados Cuando se aplica un certificado de entidad de certificación en el firewall, puede tardar entre 5 y 10 minutos en surtir efecto. Se está investigando una solución.
Compatibilidad con TLS 1.3 TLS 1.3 se admite de forma parcial. El túnel TLS del cliente al firewall se basa en TLS 1.2 y desde el firewall al servidor web externo en TLS 1.3. Se están investigando actualizaciones.
Availability Zones para el firewall Premium en la región de Sudeste Asiático Actualmente no se puede implementar Azure Firewall Premium con Availability Zones en la región de Sudeste Asiático. Implemente el firewall en el Sudeste Asiático sin Availability Zones o impleméntelo en una región que admita Availability Zones.

Pasos siguientes