Reglas de la política de firewall

Cuando creas una regla de política de firewall, debes especificar un conjunto de componentes que definen lo que hace la regla. Estos componentes especifican la dirección del tráfico, el origen, el destino y las características de la capa 4, como el protocolo y el puerto de destino (si el protocolo usa puertos).

Cada regla de política del firewall se aplica a las conexiones entrantes (entrada) o salientes (salida), pero no a ambas.

Reglas de entrada

La dirección de entrada se refiere a las conexiones entrantes que se envían desde orígenes específicos a Google Cloud objetivos. Las reglas de entrada se aplican a paquetes entrantes, en los que el destino de los paquetes es el objetivo.

Una regla de entrada con una acción deny protege todas las instancias cuando bloquea las conexiones entrantes a ellas. Una regla de mayor prioridad podría permitir el acceso entrante. Una red predeterminada creada automáticamente incluye algunas reglas de firewall de VPC prepropagadas, que permiten la entrada para ciertos tipos de tráfico.

Reglas de salida

La dirección de salida se refiere al tráfico saliente enviado de un objetivo a un destino. Las reglas de salida se aplican a paquetes para conexiones nuevas en las que el origen del paquete es el objetivo.

Una regla de salida con una acción allow permite que una instancia envíe tráfico a los destinos especificados en la regla. Las reglas de firewall de mayor prioridad deny pueden denegar la salida. Google Cloud Google Cloud también bloquea o limita ciertos tipos de tráfico.

Componentes de las reglas de las políticas de firewall

Las reglas en las políticas de firewall jerárquicas, las políticas de firewall de red globales y las políticas de firewall de red regionales usan los componentes descritos en esta sección. El término política de firewall hace referencia a cualquiera de estos tres tipos de políticas. Para obtener más información sobre los tipos de políticas de firewall, consulta Políticas de firewall.

Las reglas de las políticas de firewall suelen funcionar de la misma manera que las reglas de firewall de VPC, pero existen algunas diferencias, como se describe en las siguientes secciones.

Prioridad

La prioridad de una regla en una política de firewall es un número entero de 0 a 2,147,483,647, inclusive. Los números enteros más bajos indican prioridades más altas. La prioridad de una regla en una política de firewall es similar a la prioridad de una regla de firewall de VPC, con las siguientes diferencias:

  • Cada regla en una política de firewall debe tener una prioridad única.
  • La prioridad de una regla en una política de firewall funciona como el identificador único de la regla. Las reglas en las políticas de firewall no usan nombres para la identificación.
  • La prioridad de una regla en una política de firewall define el orden de evaluación dentro de la política de firewall. Las reglas de firewall de VPC y las reglas en las políticas de firewall jerárquicas, las políticas de firewall de red globales y las políticas de firewall de red regionales se evalúan como se describe en Orden de evaluación de políticas y reglas.

Acción en caso de coincidencia

Una regla en una política de firewall puede tener una de las siguientes acciones:

Parámetro de acción Descripción
allow

Permite paquetes para una conexión nueva. Detiene la evaluación de las reglas en la política de firewall que contiene la regla coincidente. No evalúa ninguna otra regla de firewall.

Independientemente de la dirección de la regla, si el protocolo de paquetes y el tipo de política de firewall admiten el seguimiento de conexiones, una regla de permiso crea una entrada de tabla de seguimiento de conexiones de firewall que permite paquetes de entrada y salida.
deny

No permite paquetes para una conexión nueva. Detiene la evaluación de las reglas en la política de firewall que contiene la regla coincidente. No evalúa ninguna otra regla de firewall.

Cloud NGFW siempre verifica si hay una entrada en la tabla de seguimiento de conexiones del firewall antes de evaluar las reglas de firewall. Por lo tanto, si una regla de permiso creó una entrada en la tabla de seguimiento de conexiones, esa entrada tendrá prioridad.
apply_security_profile_group

Intercepta paquetes para una conexión nueva y los envía a un extremo de firewall o a un grupo de extremos de intercepción. Deja de evaluar las reglas en la política de firewall que contiene la regla coincidente. No evalúa ninguna otra regla de firewall.

Independientemente de la dirección de la regla, si el protocolo de paquetes y el tipo de política de firewall admiten el seguimiento de conexiones, una regla con la acción apply_security_profile_group crea una entrada de tabla de seguimiento de conexiones del firewall para que el extremo del firewall o el grupo de extremos de intercepción intercepten los paquetes de entrada y salida.

No puedes crear reglas con la acción apply_security_profile_group en las políticas de firewall de red regionales.
goto_next

Detiene la evaluación de otras reglas en la política de firewall y evalúa las reglas en el siguiente paso del orden de evaluación de reglas y políticas de firewall.

El siguiente paso del orden de evaluación de reglas y políticas de firewall podría ser la evaluación de reglas en otra política de firewall o las reglas de firewall implícitas.

Aplicación

Puedes cambiar si una regla de política de firewall se aplica configurando su estado como habilitada o inhabilitada. Establece el estado de aplicación cuando creas una regla o cuando actualizas una regla.

Si no configuras un estado de aplicación cuando creas una regla de firewall nueva, la regla de firewall se habilita de forma automática.

Protocolos y puertos

Al igual que con las reglas de firewall de VPC, debes especificar una o más restricciones de protocolos y puertos cuando creas una regla. Cuando especificas TCP o UDP en una regla, puedes especificar el protocolo, el protocolo y un puerto de destino, o el protocolo y un rango de puertos de destino. No puedes especificar solo un puerto o rango de puertos. Además, solo puedes especificar puertos de destino. No se admiten reglas basadas en puertos de origen.

Puedes usar los siguientes nombres de protocolo en reglas de firewall: tcp, udp, icmp (en ICMP para IPv4), esp, ah, sctp y ipip. Para todos los demás protocolos, usa los números de protocolo de IANA.

Muchos protocolos usan el mismo nombre y número en IPv4 y en IPv6, pero algunos protocolos, como ICMP, no. Para especificar ICMP de IPv4, usa icmp o el número de protocolo 1. Para especificar ICMP de IPv6, usa el número de protocolo 58.

Las reglas de firewall no admiten la especificación de códigos y tipos de ICMP, solo el protocolo.

El protocolo IPv6 de salto por salto no es compatible con las reglas de firewall.

Si no especificas los parámetros de protocolo y puerto, la regla se aplica a todos los protocolos y puertos de destino.

Logging

El registro de las reglas de la política de firewall funciona igual que el registro de reglas de firewall de VPC, excepto por las siguientes diferencias:

  • El campo de referencia incluye el ID de la política de firewall y un número que indica el nivel del recurso al que se adjunta la política. Por ejemplo, 0 significa que la política se aplica a una organización, y 1 significa que la política se aplica a una carpeta de nivel superior en la organización.

  • Los registros de las reglas de políticas de firewall incluyen un campo target_resource que identifica las redes de VPC a las que se aplica la regla.

  • El registro solo se puede habilitar para las reglas allow, deny y apply_security_profile_group. No se puede habilitar en reglas goto_next.

Objetivo, origen y destino

Los parámetros de objetivo identifican las interfaces de red de las instancias a las que se aplica una regla de firewall.

Puedes especificar parámetros de origen y parámetros de destino que se aplican a los orígenes o destinos de los paquetes para las reglas de firewall de entrada y salida. La dirección de la regla de firewall determina los valores posibles para los parámetros de origen y destino.

Los parámetros de objetivo, origen y destino funcionan juntos.

Destinos

Todas las reglas de firewall de entrada y salida tienen un destino. El destino identifica las interfaces de red de las instancias de Compute Engine (incluidos los nodos de Google Kubernetes Engine y las instancias del entorno flexible de App Engine) a las que se aplica la regla de firewall.

Cada regla de firewall tiene un destino más amplio, que puedes reducir si especificas un parámetro de destino o una combinación de parámetros de destino. Si no especificas un parámetro de destino ni una combinación de parámetros de destino, la regla de firewall se aplica al destino más amplio.

  • Objetivo más amplio para las reglas en políticas de firewall jerárquicas: Todas las interfaces de red de VM en una subred en cualquier región de cualquier red de VPC que se encuentre en un proyecto bajo el nodo de Resource Manager (organización o carpeta) asociado con la política de firewall jerárquica.

  • Objetivo más amplio para las reglas en las políticas de firewall de red globales: Todas las interfaces de red de VM en una subred en cualquier región de la red de VPC asociada con la política de firewall de red global.

  • Objetivo más amplio para las reglas en las políticas de firewall de red regionales: Todas las interfaces de red de VM en una subred dentro de la región y la red de VPC asociadas con la política de firewall de red regional.

En la siguiente tabla, se enumeran los parámetros y las combinaciones de destino válidos que puedes usar para segmentar el destino de una regla de firewall:

Parámetro de destino Compatibilidad con políticas de firewall jerárquicas Compatibilidad con políticas de firewall de red globales y regionales
Recursos de la red de VPC de destino

Es una lista de una o más redes de VPC especificadas con el parámetro target-resources. Esta lista reduce el destino más amplio de la regla de firewall a las interfaces de red de VM que se encuentran en al menos una de las redes de VPC especificadas.
Cuentas de servicio objetivo

Es una lista de una o más cuentas de servicio especificadas con el parámetro target-service-accounts. Esta lista reduce el objetivo más amplio de la regla de firewall a las interfaces de red de VM que pertenecen a instancias de VM asociadas con al menos una de las cuentas de servicio especificadas.
Combinación de cuentas de servicio de destino y recursos de red de VPC de destino

Una combinación que usa los parámetros target-service-accounts y target-resources en la misma regla. Esta combinación reduce el objetivo más amplio de la regla de firewall a las interfaces de red de la VM que cumplen ambos de los siguientes criterios:

  • Interfaces que se encuentran en al menos una de las redes de VPC especificadas
  • Interfaces que pertenecen a instancias de VM asociadas con al menos una de las cuentas de servicio especificadas
Cómo segmentar valores de etiquetas seguros a partir de una clave de etiqueta con datos de propósito de red

Es una lista de uno o más valores de etiquetas de una clave de etiqueta cuyos datos de propósito especifican una sola red de VPC. Esta lista reduce el objetivo más amplio de la regla de firewall a las interfaces de red de la VM que se encuentran en la red de VPC especificada en los datos de propósito. Para obtener más información, consulta Etiquetas seguras para firewalls.
Segmenta por valores de etiquetas seguras a partir de una clave de etiqueta con datos de propósito de la organización

Es una lista de uno o más valores de etiquetas de una clave de etiqueta cuyos datos de propósito son organization=auto. Esto reduce el objetivo más amplio de la regla de firewall a las interfaces de red de VM que se encuentran en cualquier red de VPC de la organización. Para obtener más información, consulta Etiquetas seguras para firewalls.

Objetivos y direcciones IP para reglas de entrada

Los paquetes enrutados a la interfaz de red de una VM de destino se procesan en función de las siguientes condiciones:

  • Si la regla de firewall de entrada incluye un rango de direcciones IP de destino, el destino del paquete debe ajustarse a uno de los rangos de direcciones IP de destino definidos de forma explícita.

  • Si la regla de firewall de entrada no incluye un rango de direcciones IP de destino, el destino del paquete debe coincidir con una de las siguientes direcciones IP:

    • La dirección IPv4 interna principal que se asigna a la NIC de la instancia.

    • Cualquier rango de direcciones IP que se configura en la NIC de la instancia.

    • La dirección IPv4 externa que está asociada a la NIC de la instancia.

    • Si se configura IPv6 en la subred, cualquiera de las direcciones IPv6 asignadas a la NIC.

    • Una dirección IP interna o externa asociada con una regla de reenvío que se usa para el balanceo de cargas de transferencia, en la que la instancia es un backend de un balanceador de cargas de red de transferencia interno o un balanceador de cargas de red de transferencia externo.

    • Una dirección IP interna o externa asociada con una regla de reenvío que se usa para el reenvío de protocolos, en la que una instancia de destino hace referencia a la instancia.

    • Una dirección IP dentro del rango de destino de una ruta estática personalizada que usa la instancia (next-hop-instance o next-hop-address) como una VM de próximo salto.

    • Una dirección IP dentro del rango de destino de una ruta estática personalizada que usa un balanceador de cargas de red de transferencia interno (next-hop-ilb) como próximo salto si la VM es un backend para ese balanceador de cargas.

Objetivos y direcciones IP para reglas de salida

El procesamiento de los paquetes emitidos desde la interfaz de red de un objetivo depende de la configuración de reenvío de IP en la VM de destino. El reenvío de IP está inhabilitado de forma predeterminada.

  • Cuando la VM de destino tiene inhabilitado el reenvío de IP, la VM puede emitir paquetes con los siguientes orígenes:

    • La dirección IPv4 interna principal de la NIC de una instancia.

    • Cualquier rango de direcciones IP que se configura en la NIC de una instancia.

    • Si se configura IPv6 en la subred, cualquiera de las direcciones IPv6 asignadas a la NIC.

    • Una dirección IP interna o externa asociada con una regla de reenvío para el balanceo de cargas de transferencia o el reenvío de protocolos. Esto es válido si la instancia es un backend de un balanceador de cargas de red de transferencia interno, un balanceador de cargas de red de transferencia externo o si una instancia objetivo hace referencia a ella.

    Si la regla de firewall de salida incluye rangos de direcciones IP de origen, las VMs de destino aún están limitadas a las direcciones IP de origen mencionadas antes, pero el parámetro de origen se puede usar para definir mejor ese conjunto. El uso de un parámetro de origen sin habilitar el reenvío de IP no expande el conjunto de direcciones de origen de paquetes posibles.

    Si la regla de firewall de salida no incluye un rango de direcciones IP de origen, se permiten todas las direcciones IP de origen mencionadas antes.

  • Cuando la VM de destino tiene habilitado el reenvío de IP, la VM puede emitir paquetes con direcciones de origen arbitrarias. Puedes usar el parámetro de origen para definir con mayor precisión el conjunto de orígenes de paquetes permitidos.

Fuentes

Los valores del parámetro de origen dependen de lo siguiente:

  • El tipo de política de firewall que contiene la regla de firewall
  • La dirección de la regla de firewall

Orígenes para reglas de entrada

En la siguiente tabla, se enumeran los parámetros de origen que se pueden usar de forma individual o en combinación entre sí en una sola regla de política de firewall de entrada. El NGFW de Cloud requiere que especifiques al menos un parámetro de origen.

Parámetro de origen de la regla de entrada Compatibilidad con políticas de firewall jerárquicas Compatibilidad con políticas de firewall de red globales y regionales
Rangos de direcciones IP de origen

Una lista simple que consta de direcciones IPv4 en formato CIDR o direcciones IPv6 en formato CIDR. La lista se almacena dentro de la regla de política de firewall.
Grupos de direcciones de origen

Colecciones reutilizables de direcciones IPv4 en formato CIDR o direcciones IPv6 en formato CIDR. La regla de firewall hace referencia a la colección. Para obtener más información, consulta Grupos de direcciones para políticas de firewall.
Nombres de dominio de origen

Es una lista de uno o más nombres de dominio de origen. Para obtener más información, incluida la forma en que los nombres de dominio se convierten en direcciones IP, consulta Objetos FQDN.
Obtén valores de etiquetas seguros de una clave de etiqueta con datos de propósito de red

Es una lista de uno o más valores de etiquetas de una clave de etiqueta cuyos datos de propósito especifican una sola red de VPC. Para obtener más información, consulta Etiquetas seguras para firewalls y Cómo las etiquetas seguras de origen implican los orígenes de los paquetes.
Obtén valores de etiquetas seguras de una clave de etiqueta con datos de propósito de la organización

Es una lista de uno o más valores de etiquetas de una clave de etiqueta cuyos datos de propósito son organization=auto. Para obtener más información, consulta Etiquetas seguras para firewalls y Cómo las etiquetas seguras de origen implican los orígenes de los paquetes.
Ubicaciones geográficas de origen

Es una lista de una o más ubicaciones geográficas de origen especificadas como códigos de país o región de dos letras. Para obtener más información, consulta Objetos de ubicación geográfica.
Listas de origen de Google Threat Intelligence

Es una lista de uno o más nombres predefinidos de listas de Google Threat Intelligence. Para obtener más información, consulta Inteligencia ante amenazas de Google para las reglas de políticas de firewall.
Tipo de red de origen

Es una restricción que define un límite de seguridad. Para obtener más información, consulta Tipos de redes.

En una sola regla de entrada, puedes usar dos o más parámetros de origen para producir una combinación de orígenes. Cloud NGFW aplica las siguientes restricciones a las combinaciones de origen de cada regla de entrada:

  • Los rangos de direcciones IP de origen deben contener CIDR de IPv4 o IPv6, no una combinación de ambos.
  • No se puede usar un grupo de direcciones de origen que contenga CIDRs IPv4 con un grupo de direcciones de origen que contenga CIDRs IPv6.
  • No se puede usar un rango de direcciones IP de origen que contenga CIDRs IPv4 con un grupo de direcciones de origen que contenga CIDRs IPv6.
  • No se puede usar un rango de direcciones IP de origen que contenga CIDRs IPv6 con un grupo de direcciones de origen que contenga CIDRs IPv4.
  • El tipo de red de Internet no se puede usar con las etiquetas de red de origen.
  • Los tipos que no son de Internet, los tipos de redes de VPC y los tipos entre VPC no se pueden usar con las listas de inteligencia sobre amenazas de Google de origen ni con las ubicaciones geográficas de origen.

Cloud NGFW aplica la siguiente lógica para hacer coincidir los paquetes con una regla de entrada que usa una combinación de fuentes:

  • Si la combinación de origen no incluye un tipo de red de origen, los paquetes coinciden con la regla de entrada si coinciden con al menos un parámetro de origen en la combinación de origen.

  • Si la combinación de origen incluye un tipo de red de origen, los paquetes coinciden con la regla de entrada si coinciden con el tipo de red de origen y con al menos uno de los otros parámetros de origen de la combinación de origen.

Cómo las etiquetas seguras de origen implican los orígenes de los paquetes

Las reglas de entrada en las políticas de firewall pueden especificar orígenes a través de etiquetas seguras de origen (valores de etiquetas). Los valores de las etiquetas seguras identifican interfaces de red, no características de paquetes, como direcciones IP.

Los paquetes enviados desde una interfaz de red de una instancia de VM coinciden con una regla de entrada que usa un valor de etiqueta segura de origen según las siguientes reglas:

  • Si la regla de entrada está en una política de red regional, la instancia de VM debe estar ubicada en una zona de la misma región que la política de firewall de red regional. De lo contrario, la instancia de VM puede ubicarse en cualquier zona.

  • La instancia de VM debe estar asociada con el mismo valor de etiqueta segura que se usa como etiqueta segura de origen en una regla de firewall de entrada.

  • El valor de la etiqueta segura asociado a la instancia de VM y que usa la regla de firewall de entrada debe provenir de una clave de etiqueta cuyo atributo purpose-data identifique al menos una red de VPC que contenga una interfaz de red de la instancia de VM:

    • Si los datos de propósito de la clave de la etiqueta especifican una sola red de VPC, las reglas de firewall de entrada que usan el valor de la etiqueta de seguridad de origen se aplican a las interfaces de red de la instancia de VM que se encuentran en esa red de VPC.

    • Si los datos de propósito de la clave de etiqueta especifican la organización, las reglas de firewall de entrada que usan el valor de la etiqueta segura de origen se aplican a las interfaces de red de la instancia de VM que se encuentran en cualquier red de VPC de la organización.

  • La interfaz de red de la VM identificada debe cumplir con uno de los siguientes criterios:

    • La interfaz de red de la VM se encuentra en la misma red de VPC a la que se aplica la política de firewall.
    • La interfaz de red de la VM está en una red de VPC que está conectada, a través del intercambio de tráfico entre redes de VPC, a la red de VPC a la que se aplica la política de firewall.

Para obtener más información sobre las etiquetas seguras para firewalls, consulta Especificaciones.

Orígenes para las reglas de salida

Puedes usar los siguientes orígenes para reglas de salida en las políticas de firewall jerárquicas y en las políticas de firewall de red:

  • Predeterminado: Implicado por el objetivo: Si omites el parámetro de origen de una regla de salida, las fuentes de paquetes se definen de forma implícita como se describe en Objetivos y direcciones IP para reglas de salida.

  • Rangos de IPv4 de origen: Una lista de direcciones IPv4 en formato CIDR.

  • Rangos de direcciones IPv6 de origen: Una lista de direcciones IPv6 en formato CIDR.

Sigue estos lineamientos a fin de agregar rangos de direcciones IP de origen para reglas de salida:

  • Si una interfaz de VM tiene direcciones IPv4 internas y externas asignadas, solo se usa la dirección IPv4 interna durante la evaluación de la regla.

  • Si tienes un rango de direcciones IP de origen y parámetros de destino en la regla de salida, los parámetros de destino se resuelven en la misma versión de IP que la versión de IP de origen.

    Por ejemplo, en una regla de salida, tienes un rango de direcciones IPv4 en el parámetro de origen y un objeto FQDN en el parámetro de destino. Si el FQDN se resuelve tanto en direcciones IPv4 como en direcciones IPv6, solo se usa la dirección IPv4 resuelta durante la aplicación de la regla.

Destinos

Los destinos se pueden especificar a través de rangos de direcciones IP, que son compatibles con las reglas de entrada y salida en las políticas de firewall jerárquicas y de red. El comportamiento de destino predeterminado depende de la dirección de la regla.

Destinos para las reglas de entrada

Puedes usar los siguientes destinos para las reglas de firewall de entrada en las políticas jerárquicas y de firewall de red:

  • Predeterminado: Implicado por el objetivo: Si omites el parámetro de destino de una regla de entrada, los destinos del paquete se definen de forma implícita como se describe en Objetivos y direcciones IP para reglas de entrada.

  • Rangos de direcciones IPv4 de destino: Una lista de direcciones IPv4 en formato CIDR.

  • Rangos de direcciones IPv6 de destino: Una lista de direcciones IPv6 en formato CIDR.

Sigue estos lineamientos a fin de agregar rangos de direcciones IP de destino para las reglas de entrada:

Destinos para las reglas de salida

En la siguiente tabla, se enumeran los parámetros de destino que se pueden usar de forma individual o en combinación entre sí en una sola regla de política de firewall de salida. Cloud NGFW requiere que especifiques al menos un parámetro de destino.

Parámetro de destino de la regla de salida Compatibilidad con políticas de firewall jerárquicas Compatibilidad con políticas de firewall de red globales y regionales
Rangos de direcciones IP de destino

Una lista simple que consta de direcciones IPv4 en formato CIDR o direcciones IPv6 en formato CIDR. La lista se almacena dentro de la regla de política de firewall.
Grupos de direcciones de destino

Colecciones reutilizables de direcciones IPv4 en formato CIDR o direcciones IPv6 en formato CIDR. La regla de política de firewall hace referencia a la colección. Para obtener más información, consulta Grupos de direcciones para políticas de firewall.
Nombres de dominio de destino

Es una lista de uno o más nombres de dominio de origen. Para obtener más información, incluida la forma en que los nombres de dominio se convierten en direcciones IP, consulta Objetos FQDN.
Ubicaciones geográficas de destino

Es una lista de una o más ubicaciones geográficas de origen especificadas como códigos de país o región de dos letras. Para obtener más información, consulta Objetos de ubicación geográfica.
Listas de Google Threat Intelligence de destino

Es una lista de uno o más nombres predefinidos de listas de Google Threat Intelligence. Para obtener más información, consulta Inteligencia ante amenazas de Google para las reglas de políticas de firewall.
Tipo de red de destino

Es una restricción que define un límite de seguridad. Para obtener más información, consulta Tipos de redes.

En una sola regla de salida, puedes usar dos o más parámetros de destino para producir una combinación de destinos. Cloud NGFW aplica las siguientes restricciones a las combinaciones de destinos de cada regla de salida:

  • Los rangos de direcciones IP de destino deben contener CIDR IPv4 o IPv6, no una combinación de ambos.
  • No se puede usar un grupo de direcciones de destino que contenga CIDR de IPv4 con un grupo de direcciones de destino que contenga CIDR de IPv6.
  • No se puede usar un rango de direcciones IP de destino que contenga CIDRs IPv4 con un grupo de direcciones de destino que contenga CIDRs IPv6.
  • No se puede usar un rango de direcciones IP de destino que contenga CIDRs IPv6 con un grupo de direcciones de destino que contenga CIDRs IPv4.
  • Las listas de Inteligencia de amenazas de Google de destino o las ubicaciones geográficas de destino no se pueden usar con el tipo de red de destino que no es de Internet.

La NGFW de Cloud aplica la siguiente lógica para hacer coincidir los paquetes con una regla de salida que usa una combinación de destino:

  • Si la combinación de destinos no incluye un tipo de red de destino, los paquetes coinciden con la regla de salida si coinciden con al menos un parámetro de destino en la combinación de destinos.

  • Si la combinación de destino incluye un tipo de red de destino, los paquetes coinciden con la regla de salida si coinciden con el tipo de red de destino y al menos uno de los otros parámetros de destino en la combinación de destino.

Tipos de redes

Los tipos de red te ayudan a alcanzar tus objetivos de seguridad con menos reglas de política de firewall de manera más eficiente. Cloud NGFW admite cuatro tipos de redes que se pueden usar para crear una combinación de origen o destino en una regla de una política de firewall jerárquica, una política de firewall de red global o una política de firewall de red regional.

En la siguiente tabla, se enumeran los cuatro tipos de redes y se indica si un tipo de red se puede usar en una combinación de origen de una regla de entrada, en una combinación de destino de una regla de salida o en ambas.

Tipo de red Orígenes para reglas de entrada Destinos para las reglas de salida
Internet (INTERNET)
Sin Internet (NON_INTERNET)
Redes de VPC (VPC_NETWORKS)
Dentro de la VPC (INTRA_VPC)

Los tipos de redes con y sin Internet son mutuamente excluyentes. Los tipos de redes de VPC y redes dentro de la VPC son subconjuntos del tipo de red que no es de Internet.

Tipo de red de Internet

El tipo de red internet (INTERNET) se puede usar como parte de una combinación de origen de una regla de entrada o como parte de una combinación de destino de una regla de salida:

  • Para una regla de entrada, especifica el tipo de origen de Internet y al menos otro parámetro de origen, excepto un origen de etiqueta segura. Los paquetes coinciden con la regla de entrada si coinciden con al menos uno de los otros parámetros de origen y coinciden con el parámetro de origen del tipo de Internet.

  • Para una regla de salida, especifica el destino de tipo Internet y, al menos, otro parámetro de destino. Los paquetes coinciden con la regla de salida si coinciden con al menos uno de los otros parámetros de destino y coinciden con el parámetro de destino del tipo de Internet.

En el resto de esta sección, se describen los criterios que usa Cloud NGFW para determinar si un paquete pertenece al tipo de red de Internet.

Tipo de red de Internet para paquetes de entrada

Los paquetes de entrada que un Maglev de Google enruta a una interfaz de red de VM se consideran pertenecientes al tipo de red de Internet. Maglev enruta los paquetes a una interfaz de red de VM cuando el destino del paquete coincide con uno de los siguientes:

  • Es una dirección IPv4 externa regional de una interfaz de red de VM, una regla de reenvío de un balanceador de cargas de red de transferencia externo o una regla de reenvío para el reenvío de protocolos externos.
  • Una dirección IPv6 externa regional de una interfaz de red de VM, una regla de reenvío de un balanceador de cargas de red de transferencia externo o una regla de reenvío para el reenvío de protocolos externos y el paquete no se enrutó con una ruta de subred importada por el intercambio de tráfico entre redes de VPC o desde un radio de VPC en un centro de Network Connectivity Center.

Para obtener más información sobre los paquetes que Maglev enruta a las VMs de backend para un balanceador de cargas de red de transferencia externo o un reenvío de protocolos externos, consulta Rutas para balanceadores de cargas de red de transferencia externos y reenvío de protocolos externos.

Tipo de red de Internet para paquetes de salida

Los paquetes de salida enviados por las interfaces de red de la VM y enrutados con rutas estáticas que usan el siguiente salto de la puerta de enlace de Internet predeterminada se consideran que pertenecen al tipo de red de Internet. Sin embargo, si la dirección IP de destino de estos paquetes de salida es para los servicios y las APIs de Google, se considera que estos paquetes pertenecen al tipo de red que no es de Internet. Para obtener más información sobre la conectividad a los servicios y las APIs de Google, consulta Tipo de red sin Internet.

Cuando los paquetes se enrutan a través de una ruta estática que usa el siguiente salto de la puerta de enlace de Internet predeterminada, se considera que los paquetes que envían las interfaces de red de la VM a los siguientes destinos pertenecen al tipo de Internet:

  • Es un destino de dirección IP externa fuera de la red de Google.
  • Es la dirección IPv4 externa regional de destino de una interfaz de red de VM, la regla de reenvío de un balanceador de cargas externo regional o la regla de reenvío para el reenvío de protocolos externos.
  • Es la dirección IPv6 externa regional de destino de una interfaz de red de VM, la regla de reenvío de un balanceador de cargas externo regional o la regla de reenvío para el reenvío de protocolos externos.
  • Es el destino de una dirección IPv4 e IPv6 externa global de una regla de reenvío de un balanceador de cargas externo global.

Los paquetes que envían las interfaces de red de la VM a las puertas de enlace de Cloud VPN y Cloud NAT se consideran de tipo Internet:

  • Los paquetes de salida que se envían desde una interfaz de red de una VM que ejecuta software de VPN a la dirección IPv4 externa regional de una puerta de enlace de Cloud VPN se consideran de tipo Internet.
  • Los paquetes de salida que se envían desde una puerta de enlace de Cloud VPN a otra no se consideran pertenecientes a ningún tipo de red, ya que las reglas de firewall solo se aplican a las VMs.
  • En el caso de la NAT pública, se considera que los paquetes de respuesta enviados desde una interfaz de red de VM a una dirección IPv4 externa regional de una puerta de enlace de Cloud NAT pertenecen al tipo de Internet.

Si las redes de VPC están conectadas a través del intercambio de tráfico entre redes de VPC o si participan como radios de VPC en el mismo centro de Network Connectivity Center, las rutas de subred IPv6 pueden proporcionar conectividad a los destinos de direcciones IPv6 externas regionales de las interfaces de red de VM, las reglas de reenvío del balanceador de cargas externo regional y las reglas de reenvío de protocolos externos. Cuando la conectividad a esos destinos de direcciones IPv6 externas regionales se proporciona a través de una ruta de subred, los destinos se encuentran en el tipo de red que no es de Internet.

Tipo de red que no es de Internet

El tipo de red sin Internet (NON-INTERNET) se puede usar como parte de una combinación de origen de una regla de entrada o como parte de una combinación de destino de una regla de salida:

  • Para una regla de entrada, especifica el origen de tipo no Internet y, al menos, otro parámetro de origen, excepto un origen de lista de amenazas o un origen de ubicación geográfica. Los paquetes coinciden con la regla de entrada si coinciden con al menos uno de los otros parámetros de origen y coinciden con el parámetro de origen de tipo no Internet.

  • Para una regla de salida, especifica el destino de tipo no Internet y, al menos, otro parámetro de destino. Los paquetes coinciden con la regla de salida si coinciden con al menos uno de los otros parámetros de destino y coinciden con el parámetro de destino de tipo no Internet.

En el resto de esta sección, se describen los criterios que usa el NGFW de Cloud para determinar si un paquete pertenece al tipo de red que no es de Internet.

Tipo de red que no es de Internet para paquetes de entrada

Los paquetes de entrada enrutados a una interfaz de red de VM a través de próximos saltos dentro de una red de VPC o desde las APIs y los servicios de Google se consideran pertenecientes al tipo de red que no es de Internet.

Los paquetes se enrutan a través de próximos saltos dentro de una red de VPC o desde las APIs y los servicios de Google en las siguientes situaciones:

  • El destino del paquete coincide con uno de los siguientes:

    • Es una dirección IPv4 o IPv6 interna regional de una interfaz de red de VM, una regla de reenvío de un balanceador de cargas de red de transferencia interno o una regla de reenvío para el reenvío de protocolos interno.
    • Una dirección IPv6 externa regional de una interfaz de red de VM, una regla de reenvío de un balanceador de cargas de red de transferencia externo o una regla de reenvío para el reenvío de protocolos externos y el paquete se enrutó con una ruta de subred local, una ruta de subred de peering o una ruta de subred de Network Connectivity Center.
    • Cualquier dirección dentro del rango de destino de una ruta estática en la que la VM receptora sea una VM de próximo salto o una VM de backend de un balanceador de cargas de red de transferencia interno de próximo salto

  • El origen del paquete coincide con uno de los siguientes:

Tipo de red que no es de Internet para paquetes de salida

Los paquetes de salida que envían las interfaces de red de la VM y que se enrutan dentro de una red de VPC, o bien que se envían a las APIs y los servicios de Google, se consideran que pertenecen al tipo de red que no es de Internet.

Los paquetes se enrutan a través de los próximos saltos dentro de una red de VPC o hacia las APIs y los servicios de Google en las siguientes situaciones:

Tipo de redes de VPC

El tipo de redes de VPC (VPC_NETWORKS) solo se puede usar como parte de una combinación de origen de una regla de entrada. No puedes usar el tipo de redes de VPC como parte de una combinación de destino de una regla de salida.

Para usar el tipo de redes de VPC como parte de una combinación de fuentes de una regla de entrada, haz lo siguiente:

  1. Debes especificar una lista de redes de VPC de origen:

    • La lista de redes de origen debe contener al menos una red de VPC. Puedes agregar un máximo de 250 redes de VPC a la lista de redes de origen.
    • Debe existir una red de VPC antes de que puedas agregarla a la lista de redes de origen.
    • Puedes agregar la red con su identificador de URL parcial o completo.
    • Las redes de VPC que agregues a la lista de redes de origen no necesitan estar conectadas entre sí. Cada red de VPC puede ubicarse en cualquier proyecto.
    • Si se borra una red de VPC después de agregarla a la lista de redes de origen, la referencia a la red borrada permanece en la lista. Cloud NGFW ignora las redes de VPC borradas cuando aplica una regla de entrada. Si se borran todas las redes de VPC de la lista de redes de origen, las reglas de entrada que dependen de la lista no serán efectivas porque no coincidirán con ningún paquete.

  2. Debes especificar al menos otro parámetro de fuente, excepto una fuente de lista de inteligencia sobre amenazas o una fuente de geolocalización.

Un paquete coincide con una regla de entrada que usa el tipo de redes de VPC en su combinación de origen si se cumplen todas las siguientes condiciones:

  • El paquete coincide con al menos uno de los otros parámetros de origen.

  • El paquete lo envía un recurso ubicado en una de las redes de VPC de origen.

  • La red de VPC de origen y la red de VPC a la que se aplica la política de firewall que contiene la regla de entrada son la misma red de VPC o están conectadas a través del intercambio de tráfico entre redes de VPC o como radios de VPC en un concentrador de Network Connectivity Center.

Los siguientes recursos se encuentran en una red de VPC:

  • Interfaces de red de VM
  • Túneles de Cloud VPN
  • Adjuntos de VLAN de Cloud Interconnect
  • Dispositivos del router
  • Proxies de Envoy en una subred de solo proxy
  • Extremos de Private Service Connect
  • Conectores de Acceso a VPC sin servidores

Tipo de red dentro de la VPC

El tipo de red intra-VPC (INTRA_VPC) solo se puede usar como parte de una combinación de origen de una regla de entrada. No puedes usar el tipo de red dentro de la VPC como parte de una combinación de destino de una regla de salida.

Para usar el tipo intra-VPC como parte de una combinación de orígenes de una regla de entrada, debes especificar al menos otro parámetro de origen, excepto un origen de lista de inteligencia sobre amenazas o un origen de ubicación geográfica .

Un paquete coincide con una regla de entrada que usa el tipo intra-VPC en su combinación de origen si se cumplen todas las siguientes condiciones:

  • El paquete coincide con al menos uno de los otros parámetros de origen.

  • El paquete se envía desde un recurso ubicado en la red de VPC a la que se aplica la política de firewall que contiene la regla de entrada.

Los siguientes recursos se encuentran en una red de VPC:

  • Interfaces de red de VM
  • Túneles de Cloud VPN
  • Adjuntos de VLAN de Cloud Interconnect
  • Dispositivos del router
  • Proxies de Envoy en una subred de solo proxy
  • Extremos de Private Service Connect
  • Conectores de Acceso a VPC sin servidores

Objetos de ubicación geográfica

Usa objetos de ubicación geográfica en reglas de la política de firewall para filtrar el tráfico IPv4 y el IPv6 externo en función de ubicaciones geográficas o regiones específicas.

Puedes aplicar reglas con objetos de ubicación geográfica al tráfico de entrada y salida. Según la dirección del tráfico, las direcciones IP asociadas con los códigos de país coinciden con el origen o el destino del tráfico.

  • Puedes configurar objetos de ubicación geográfica para políticas de firewall jerárquicas, políticas de firewall de red globales y políticas de firewall de red regionales.

  • Para agregar ubicaciones geográficas a las reglas de la política de firewall, usa los códigos de país o región de dos letras, como se definen en los códigos de país ISO 3166 alfa-2.

    Por ejemplo, si deseas permitir el tráfico entrante solo desde EE.UU. hacia la red, crea una regla de política de firewall de entrada con el código de país de origen establecido como US y la acción establecida como allow. Del mismo modo, si deseas permitir el tráfico saliente solo a EE.UU., configura una regla de política de firewall de salida con el código de país de destino establecido en US y la acción establecida en allow.

  • Cloud NGFW te permite configurar reglas de firewall para los siguientes territorios, sujetos a sanciones completas de EE.UU.:

    Territorios Código asignado
    Crimea XC
    Las denominadas Donetsk People's Republic y Luhansk People's Republic XD

  • Si hay códigos de país duplicados en una sola regla de firewall, solo se conserva una entrada para ese código de país. Se quita la entrada duplicada. Por ejemplo, en la lista de código de país ca,us,us, solo se conserva ca,us.

  • Google mantiene una base de datos con direcciones IP y asignaciones de códigos de país. Google Cloud Los firewalls usan esta base de datos para asignar las direcciones IP del tráfico de origen y destino al código de país y, luego, aplican la regla de política de firewall coincidente con los objetos de ubicación geográfica.

  • A veces, las asignaciones de direcciones IP y los códigos de país cambian debido a las siguientes condiciones:

    Debido a que estos cambios tardan un tiempo en reflejarse en la base de datos de Google, es posible que veas algunas interrupciones del tráfico y cambios en el comportamiento del tráfico que se bloquea o se permite.

Usa objetos de ubicación geográfica con otros filtros de reglas de políticas de firewall

Puedes usar objetos de ubicación geográfica junto con otros filtros de origen o de destino. Según su dirección, la regla de política de firewall se aplica al tráfico entrante o saliente que coincide con la unión de todos los filtros especificados.

Para obtener información sobre cómo funcionan los objetos de ubicación geográfica con otros filtros de origen en las reglas de entrada, consulta Orígenes para reglas de entrada en las políticas de firewall jerárquicas y Orígenes para reglas de entrada en las políticas de firewall de red.

Si deseas obtener información para saber cómo funcionan los objetos de ubicación geográfica con otros filtros de destino en las reglas de salida, consulta Destinos para reglas de salida.

Inteligencia ante amenazas de Google para reglas de políticas de firewall

Las reglas de políticas de firewall te permiten proteger tu red, ya que permiten o bloquean el tráfico según los datos de Google Threat Intelligence. Los datos de Google Threat Intelligence incluyen listas de direcciones IP basadas en las siguientes categorías:

  • Nodos de salida de Tor: Tor es un software de código abierto que habilita la comunicación anónima. Para excluir a los usuarios que ocultan su identidad, bloquea las direcciones IP de los nodos de salida de Tor (extremos en los que el tráfico sale de la red de Tor).
  • Direcciones IP maliciosas conocidas: Direcciones IP que se sabe que son el origen de ataques de aplicaciones web. Para mejorar la posición de seguridad de tu aplicación, bloquea estas direcciones IP.
  • Motores de búsqueda: Direcciones IP que pueden habilitar la indexación de sitios.
  • Rangos de direcciones IP de la nube pública: Esta categoría puede bloquearse para evitar que las herramientas maliciosas automatizadas exploren aplicaciones web, o bien se permite si el servicio usa otras nubes públicas. Esta categoría se divide aún más en las siguientes subcategorías:
    • Rangos de direcciones IP que usa Amazon Web Services
    • Rangos de direcciones IP que usa Microsoft Azure
    • Rangos de direcciones IP que usa Google Cloud
    • Rangos de direcciones IP que usan los servicios de Google

Las listas de datos de Google Threat Intelligence pueden incluir direcciones IPv4, direcciones IPv6 o ambas. Para configurar Google Threat Intelligence en tus reglas de políticas de firewall, usa los nombres de lista predefinidos de Google Threat Intelligence según la categoría que desees permitir o bloquear. Estas listas se actualizan de forma continua, lo que protege los servicios de amenazas nuevas sin pasos de configuración adicionales. Los nombres de las listas válidos son los siguientes.

Nombre de la lista Descripción
iplist-tor-exit-nodes Coincide con las direcciones IP de los nodos de salida TOR
iplist-known-malicious-ips Coincide con las direcciones IP que se sabe que atacan aplicaciones web
iplist-search-engines-crawlers Coincide con las direcciones IP de los rastreadores de los motores de búsqueda
iplist-vpn-providers Hace coincidir las direcciones IP que pertenecen a proveedores de VPN de baja reputación
iplist-anon-proxies Coincide con las direcciones IP que pertenecen a proxies anónimos abiertos
iplist-crypto-miners Coincide con las direcciones IP que pertenecen a los sitios de minería de criptomonedas
iplist-public-clouds
  • iplist-public-clouds-aws
  • iplist-public-clouds-azure
  • iplist-public-clouds-gcp
  • iplist-public-clouds-google-services
 Coincide con las direcciones IP que pertenecen a nubes públicas
  • Coincide con los rangos de direcciones IP que usa Amazon Web Services
  • Coincide con los rangos de direcciones IP que usa Microsoft Azure
  • Coincide con los rangos de direcciones IP que usa Google Cloud
  • Coincide con los rangos de direcciones IP que usan los servicios de Google

Usa Google Threat Intelligence con otros filtros de reglas de políticas de firewall

Para definir una regla de política de firewall con Google Threat Intelligence, sigue estos lineamientos:

  • Para las reglas de salida, especifica el destino con una o más listas de Google Threat Intelligence de destino.

  • Para las reglas de entrada, especifica el origen con una o más listas de Google Threat Intelligence.

  • Puedes configurar listas de Google Threat Intelligence para políticas de firewall jerárquicas, políticas de firewall de red globales y políticas de firewall de red regionales.

  • Puedes usar estas listas junto con otros componentes del filtro de reglas de origen o destino.

    Para obtener información sobre cómo funcionan las listas de Google Threat Intelligence con otros filtros de origen en las reglas de entrada, consulta Orígenes para reglas de entrada en políticas de firewall jerárquicas y Orígenes para reglas de entrada en políticas de firewall de red.

    Para obtener información sobre cómo funcionan las listas de Google Threat Intelligence con otros filtros de destino en las reglas de salida, consulta Destinos para reglas de salida.

  • El registro de firewall se realiza a nivel de la regla. Para que sea más fácil depurar y analizar el efecto de tus reglas de firewall, no incluyas varias listas de Google Threat Intelligence en una sola regla de firewall.

  • Puedes agregar varias listas de Inteligencia de amenazas de Google a una regla de política de firewall. Cada nombre de lista incluido en la regla se cuenta como un atributo, sin importar la cantidad de direcciones IP o rangos de direcciones IP incluidos en esa lista. Por ejemplo, si incluiste los nombres de las listas iplist-tor-exit-nodes, iplist-known-malicious-ips y iplist-search-engines-crawlers en tu regla de política de firewall, el recuento de atributos de la regla por política de firewall aumenta en tres. Para obtener más información sobre el recuento de atributos de la regla, consulta Cuotas y límites.

Crea excepciones a las listas de Google Threat Intelligence

Si tienes reglas que se aplican a las listas de Google Threat Intelligence, puedes usar las siguientes técnicas para crear reglas de excepción aplicables a ciertas direcciones IP dentro de una lista de Google Threat Intelligence:

  • Regla de firewall de permiso selectivo: Supongamos que tienes una regla de firewall de entrada o salida que rechaza los paquetes desde o hacia una lista de Google Threat Intelligence. Para permitir paquetes desde o hacia una dirección IP seleccionada dentro de esa lista de Google Threat Intelligence, crea una regla de firewall de permiso de entrada o salida de prioridad más alta que especifique la dirección IP de excepción como fuente o destino.

  • Regla de firewall de denegación selectiva: Supongamos que tienes una regla de firewall de entrada o salida que permite paquetes desde o hacia una lista de Google Threat Intelligence. Para rechazar paquetes desde o hacia una dirección IP seleccionada dentro de esa lista de Google Threat Intelligence, crea una regla de firewall de denegación de entrada o salida de mayor prioridad que especifique la dirección IP de excepción como un origen o un destino.

Grupos de direcciones para políticas de firewall

Los grupos de direcciones son una colección lógica de rangos de direcciones IPv4 o rangos de direcciones IPv6 en formato CIDR. Puedes usar grupos de direcciones para definir orígenes o destinos coherentes a los que hacen referencia muchas reglas de firewall. Los grupos de direcciones se pueden actualizar sin modificar las reglas de firewall que los usan. Para obtener más información sobre los grupos de direcciones, consulta Grupos de direcciones para políticas de firewall.

Puedes definir grupos de direcciones de origen y de destino para las reglas de firewall de entrada y salida, respectivamente.

Para obtener información sobre cómo funcionan los grupos de direcciones de origen con otros filtros de origen en las reglas de entrada, consulta Orígenes para reglas de entrada en políticas de firewall jerárquicas y Orígenes para reglas de entrada en políticas de firewall de red.

Si deseas obtener información sobre cómo funcionan los grupos de direcciones de destino con otros filtros de destino en las reglas de salida, consulta Destinos de las reglas de salida.

Objetos FQDN

Los objetos de nombre de dominio completamente calificado (FQDN) contienen nombres de dominio que especificas en el formato de nombre de dominio. Puedes usar objetos FQDN como fuentes para reglas de entrada o como destinos para reglas de salida en una política de firewall jerárquica, una política de firewall de red global o una política de firewall de red regional.

Puedes combinar FQDN con otros parámetros. Para obtener detalles sobre las combinaciones de parámetros de origen en las reglas de entrada, consulta Orígenes para las reglas de entrada. Si deseas obtener detalles sobre las combinaciones de parámetros de destino en las reglas de salida, consulta Destinos para las reglas de salida.

Los objetos de FQDN admiten políticas de respuesta de Cloud DNS, zonas privadas administradas con alcance de red de VPC, nombres de DNS internos de Compute Engine y zonas de DNS públicas. Esta compatibilidad se aplica siempre y cuando la red de VPC no tenga una política del servidor saliente que especifique un servidor de nombres alternativo. Para obtener más información, consulta Orden de resolución de la red de VPC.

Asigna objetos FQDN a direcciones IP

Cloud NGFW resuelve periódicamente los objetos FQDN en direcciones IP. El NGFW de Cloud sigue el orden de resolución de nombres de VPC de Cloud DNS en la red de VPC que contiene los objetivos de la regla de firewall.

Cloud NGFW usa el siguiente comportamiento para la resolución de direcciones IP:

  • Admite el rastreo de CNAME. Cloud NGFW usa el rastreo de CNAME de Cloud DNS si la respuesta a una consulta de objeto FQDN es un registro CNAME.

  • Direcciones IP del programa Cloud NGFW usa las direcciones IP resueltas cuando programa las reglas de firewall que usan objetos FQDN. Cada objeto FQDN se puede asignar a un máximo de 32 direcciones IPv4 y 32 direcciones IPv6.

    Si la respuesta de DNS para una consulta de objeto FQDN se resuelve en más de 32 direcciones IPv4 o más de 32 direcciones IPv6, Cloud NGFW limita las direcciones IP programadas en las reglas de firewall a las primeras 32 direcciones IPv4 y las primeras 32 direcciones IPv6.

  • Ignorar objetos FQDN Si Cloud NGFW no puede resolver un objeto FQDN en una dirección IP, ignora el objeto FQDN. En las siguientes situaciones, Cloud NGFW ignora un objeto de FQDN:

    • Cuando se reciben respuestas de NXDOMAIN Las respuestas NXDOMAIN son respuestas explícitas de un servidor de nombres que indican que no existe ningún registro de DNS para la consulta del objeto FQDN.

    • Cuando no hay una dirección IP en una respuesta. En esta situación, una consulta de objeto de FQDN no genera una respuesta con una dirección IP que el NGFW de Cloud pueda usar para programar una regla de firewall.

    • Cuando no se puede acceder al servidor de Cloud DNS. Cloud NGFW ignora los objetos FQDN si no se puede acceder a un servidor DNS que proporcione la respuesta.

    Cuando se ignora un objeto FQDN, Cloud NGFW programa las partes restantes de una regla de firewall, si es posible.

Consideraciones para los objetos FQDN

Ten en cuenta lo siguiente para los objetos FQDN:

  1. Dado que los objetos de FQDN se asignan y se programan como direcciones IP, Cloud NGFW se comporta de la siguiente manera cuando dos o más objetos de FQDN se asignan a la misma dirección IP. Supongamos que tienes las siguientes dos reglas de firewall que se aplican al mismo destino:

    • Regla 1: prioridad 100, entrada permitida desde el FQDN de origen example1.com
    • Regla 2: prioridad 200, entrada permitida desde el FQDN de origen example2.com

    Si tanto example1.com como example2.com se resuelven en la misma dirección IP, los paquetes de entrada de example1.com y example2.com coinciden con la primera regla de firewall porque esta regla tiene una prioridad más alta.

  2. Entre las consideraciones para usar objetos FQDN, se incluyen las siguientes:

    • Una consulta de DNS puede tener respuestas únicas según la ubicación del cliente solicitante.

    • Las respuestas de DNS pueden ser muy variables cuando se involucra un sistema de balanceo de cargas basado en DNS.

    • Una respuesta de DNS puede contener más de 32 direcciones IPv4.

    • Una respuesta de DNS puede contener más de 32 direcciones IPv6.

    En las situaciones anteriores, debido a que el NGFW de Cloud realiza consultas de DNS en cada región que contiene la interfaz de red de la VM a la que se aplica la regla de firewall, las direcciones IP programadas en las reglas de firewall no contienen todas las direcciones IP posibles asociadas con el FQDN.

    La mayoría de los nombres de dominio de Google, como googleapis.com, están sujetos a una o más de estas situaciones. En su lugar, usa direcciones IP o grupos de direcciones.

  3. No uses objetos FQDN con Cloud DNS DNS64. Cloud NGFW no programa las direcciones IPv6 de prefijo conocido (WKP) que usa DNS64.

    DNS64 y NAT64 están diseñados para usarse en conjunto y proporcionar conectividad a servidores solo IPv4 desde clientes de VM solo IPv6. Para proporcionar esta conectividad, un proveedor de DNS64 sintetiza una respuesta AAAA a una consulta de DNS para la que no existe un registro AAAA. La respuesta AAAA sintetizada codifica la dirección IPv4 del servidor en los últimos cuatro bytes de una dirección IPv6 de WKP (64:ff9b::/96). Cuando el cliente solo IPv6 envía paquetes a la dirección IPv6 de WKP, un proveedor de NAT64 extrae la dirección IPv4 del servidor de la dirección IPv6 de WKP y abre una conexión IPv4 al servidor solo IPv4.

    Cuando se usa DNS64, te recomendamos que uses direcciones IP o grupos de direcciones en las reglas de firewall. Asegúrate de incluir la dirección IPv4 del servidor y su representación WKP IPv6.

  4. Evita usar objetos FQDN con registros A de DNS que tengan un tiempo de actividad (TTL) de menos de 90 segundos.

Formatea los nombres de dominio

Los objetos FQDN deben seguir el formato de FQDN estándar, que se define en RFC 1035, RFC 1123 y RFC 4343. Cloud NGFW rechaza los objetos FQDN que incluyen un nombre de dominio que no cumple con todas las siguientes reglas de formato:

  • Cada objeto FQDN debe ser un nombre de dominio con al menos dos etiquetas:

    • Cada etiqueta debe coincidir con una expresión regular que incluya solo estos caracteres: [a-z]([-a-z0-9][a-z0-9])?..
    • Cada etiqueta debe tener una longitud de entre 1 y 63 caracteres.
    • Las etiquetas se deben concatenar con un punto (.).

    Por lo tanto, los objetos FQDN no admiten caracteres comodín (*) ni nombres de dominio de nivel superior (o raíz), como *.example.com. y .org, ya que estos incluyen solo una etiqueta.

  • Los objetos FQDN admiten nombres de dominio internacionalizados (IDN). Puedes proporcionar un IDN en formato Unicode o Punycode. Ten en cuenta lo siguiente:

    • Si especificas un IDN en formato Unicode, Cloud NGFW lo convierte al formato Punycode antes de procesarlo.

    • Puedes usar el convertidor de IDN para crear la representación en Punycode de un IDN.

    • El límite de caracteres de 1 a 63 por etiqueta se aplica a los IDN después de la conversión al formato Punycode.

  • La longitud codificada de un nombre de dominio completamente calificado (FQDN) no puede superar los 255 bytes (octetos).

El NGFW de Cloud no admite nombres de dominio equivalentes en la misma regla de firewall. Por ejemplo, si los dos nombres de dominio (o las representaciones de Punycode de los IDN) difieren como máximo en un punto final (.), Cloud NGFW los considera equivalentes.

¿Qué sigue?