Reglas de seguridad

El servicio de Networking ofrece dos funciones de firewall virtual que utilizan reglas de seguridad para controlar el tráfico en el nivel de paquete. Los dos funciones son:

  • Listas de seguridad: la función de firewall virtual original del servicio Networking.
  • Grupos a la seguridad de la red (NSG): función diseñada posteriormente para componentes que tienen diferentes posturas de seguridad. Los NSG solo se admiten para servicios específicos.

Estas dos funciones ofrecen diferentes maneras de aplicar reglas de seguridad a un conjunto de tarjetas de interfaz de red virtual (VNIC) en la red virtual en la nube (VCN).

En este tema, se resumen las diferencias básicas entre las dos funciones. También se explican los conceptos importantes de las reglas de seguridad que es necesario comprender. El modo de creación, gestión y aplicación de reglas de seguridad varía entre las listas de seguridad y los grupos de seguridad de la red. Para obtener información detallada sobre la implantación, consulte los siguientes temas relacionados:

Nota

Puede utilizar el enrutamiento de paquetes de confianza cero (ZPR) junto con grupos de seguridad de red o en lugar de ellos para controlar el acceso de red a los recursos de OCI mediante la aplicación de atributos de seguridad y la creación de políticas ZPR para controlar la comunicación entre ellos. Para obtener más información, consulte Zero Trust Packet Routing.
Atención

Si un punto final tiene un atributo de seguridad ZPR, el tráfico al punto final debe cumplir las reglas ZPR y también todas las reglas de NSG y lista de seguridad. Por ejemplo, si ya está utilizando NSG y aplica un atributo de seguridad a un punto final, tan pronto como se aplica el atributo, todo el tráfico al punto final se bloquea. A partir de ese momento, una política ZPR debe permitir el tráfico al punto final.

Comparación de listas de seguridad y grupos de seguridad de red

Las listas de seguridad permiten definir un conjunto de reglas de seguridad que se aplica a todas las VNIC de una subred completa. Para utilizar una lista del sistema de seguridad determinado con una subred concreta, debe asociar la lista del sistema de seguridad a la subred, ya sea durante la creación de una subred o más adelante. Una subred se puede asociar con un máximo de cinco listas de seguridad. Todas las VNIC que se crean en esa subred están sujetas a las listas de seguridad asociadas con la subred.

Los grupos del sistema de seguridad (NSG) permiten definir un conjunto de reglas de seguridad que se aplica a un grupo de VNIC seleccionado (o los recursos primarios de los VNIC, como equilibradores del sistema de base de datos o de carga). Por ejemplo, los VNIC que pertenecen a un conjunto de instancias de Compute que tienen la misma posición de seguridad. Para utilizar un NSG específico, agregue las VNIC de interés al grupo. Las VNIC agregadas a ese grupo están sujetas a las reglas de seguridad de ese grupo. Se puede agregar una VNIC a un máximo de cinco NSG.

En la siguiente tabla se resumen las diferencias.

Herramienta de seguridad Se aplica a Para activarla Limitaciones
Listas de seguridad Todas las VNIC de una subred que utilizan esa lista de seguridad Asocie la lista de seguridad a la subred Máximo de cinco listas de seguridad por subred
Grupos de seguridad de red VNIC seleccionadas en la misma VCN Agregue VNIC específicas al NSG Máximo de cinco NSG por VNIC

Recomendamos utilizar NSG en lugar de listas de seguridad, ya de que los NSG permiten separar la arquitectura de subred de la VCN de los requisitos del entorno de seguridad.

Sin embargo, puede usar tanto listas de seguridad como NSG juntos si así lo desea. Para obtener más información, consulte Uso combinado de listas de seguridad y grupos de seguridad de red.

Acerca de las VNIC y los recursos principales

Una VNIC es un componente del servicio Networking necesario para que un recurso en red, como una instancia de Compute, se conecte a una red virtual en la Nube (VCN). La VNIC afecta a cómo se conecta la instancia con puntos finales dentro y fuera de la VCN. Cada VNIC reside en una subred de una VCN.

Al crear una instancia de Compute, se crea automáticamente una VNIC para la instancia en la subred de la instancia. Se considera que la instancia es el recurso principal para la VNIC. Puede agregar más VNIC (secundarias) a una instancia de Compute. Por este motivo, las VNIC de una instancia se muestran de forma destacada como parte de los recursos relacionados de una instancia de Compute en la consola.

Otros tipos de recursos principales también hacen que se cree automáticamente una VNIC. Por ejemplo, al crear un equilibrador de carga, los servicios del equilibrador de carga crean automáticamente VNIC para equilibrar la circulación en el conjunto de backends. Además, al crear un sistema de base de datos, el servicio de base de datos crea automáticamente VNIC como nodos del sistema de base de datos. Esos servicios crean y gestionan esos VNIC. Por este motivo, esas VNIC no son tan visibles en la consola de la misma forma que los VNIC para las instancias de Compute.

Para utilizar un NSG, coloca activamente las VNIC en el grupo, una VNIC nunca forma parte de un NSG porque está en una subred determinada. Sin embargo, lo habitual es trabajar con el recurso principal cuando se agrega una VNIC al grupo, no la VNIC propiamente dicho. Por ejemplo, al crear una instancia de Compute, puede especificar opcionalmente un NSG para la instancia. Aunque conceptualmente coloca la instancia en el grupo, en la realidad está poniendo la VNIC principal de las instancias en el grupo. Las reglas de seguridad del grupo se aplican a esa VNIC, no a la instancia. Además, si agrega una VNIC secundaria a la instancia, también puede especificar un NSG para esa VNIC, en cuyo caso las reglas se aplican a esa VNIC, no a la instancia. Tenga en cuenta que todas las VNIC de Un NSG deben estar en la misma VCN a la que pertenece el NSG.

Del mismo modo, cuando coloca un equilibrador de cargas en un Grupo de Seguridad de Red, conceptualmente coloca el equilibrador de cargas en el grupo. Técnicamente, está colocando las VNIC gestionadas por el servicio Load Balancer en el grupo del seguro de red.

La pertenencia al VNIC de un NSG se gestiona en el recurso principal, no en el propio NSG. Por ejemplo, para agregar un recurso principal a un grupo de seguridad de redes, puede realizar la acción en el recurso primario (mediante el cálculo de los grupos de seguridad de redes a aquellos a quienes se ha agregado el recurso principal). No lleva a cabo la acción en el NSG (especificando qué VNIC o recursos principales agregar al NSG). De manera similar, para eliminar una VNIC de un grupo de seguridad de redes, puede realizar esa acción actualizando el recurso principal, no el grupo de seguridad de redes. Por ejemplo, para agregar una VNIC de un instancia de Compute existente a un NSG, actualice las propiedades de esa VNIC y especifique el NSG. Por ejemplo, con la API de REST, puede llamar a UpdateVnic. En la consola, verá la instancia y, a continuación, la VNIC de interés, donde se podrán editar las propiedades de la VNIC.

Para obtener una lista de los recursos principales que admiten el uso de NSG, consulte Soporte para grupos de seguridad de red.

Grupo de Seguridad de Red como Origen o Destino de una Regla

Una diferencia importante en la forma de escribir reglas de seguridad para los NSG en comparación con las listas de seguridad: al escribir reglas para un NSG, puede especificar un NSG como origen del tráfico ( para reglas de entrada) o destino del tráfico ( para reglas de entrada). Compárese con las reglas de la lista de seguridad, donde puede especificar un CIDR como origen o destino.

La capacidad de especificar un NSG significa que puede escribir fácilmente reglas para controlar el tráfico entre dos NSG diferentes. Los NSG deben estar en la misma VCN.

Además, si desea controlar el tráfico entre los VNIC en un NSG específico, puede escribir reglas que especifique la propia NSG de la regla como origen (para las reglas de entrada) o destino (para las reglas de salida).

Para obtener más información, consulte Visión general de los grupos de seguridad de red.

Diferencias de API de REST

El modelo de API de REST para NSG tiene algunas diferencias básicas en t en comparación con las listas de seguridad. Para obtener más información, consulte Uso de la API.

Reglas predeterminadas

Una VCN incluye automáticamente una lista de seguridad por defecto que contiene varias reglas de seguridad por defecto que sirven de ayuda para empezar a utilizar el servicio de redes. Al crear una subred, la lista del sistema de seguridad por defecto se asocia con la subred a menos que especifique una lista personalizada de seguridad ya creada en la VCN.

En comparación, la VCN no tiene un grupo de seguridad para la red predeterminado.

Límites

Las dos funciones tienen límites diferentes. Consulte la sección Límites de servicio para obtener una lista de límites aplicables e instrucciones para solicitar un aumento del límite.

Límites de lista de seguridad

Recurso

Ámbito

Universal Credits de Oracle

Pay As You Go o prueba

Listas de seguridad VCN 300 300
Listas de seguridad Subred 5* 5*
Reglas de seguridad Lista de seguridad

200 reglas de entrada*

y

200 reglas de salida*

200 reglas de entrada*

y

200 reglas de salida*

* No se puede aumentar el límite para este recurso
Límites de grupos de seguridad de red
Recurso Ámbito Universal Credits de Oracle Pay As You Go o prueba
Grupos de seguridad de red VCN 1000 1000
VNIC Grupo de seguridad de red

Un grupo de seguridad de red determinado puede tener tantos VNIC como en la VCN.

Una VNIC determinada puede pertenecer como máximo a 5 grupos de seguridad de red.*

Un grupo de seguridad de red determinado puede tener tantos VNIC como en la VCN.

Una VNIC determinada puede pertenecer como máximo a 5 grupos de seguridad de red.*

Reglas de seguridad Grupo de seguridad de red

120 (total de entrada más salida)

120 (total de entrada más salida)

* No se puede aumentar el límite para este recurso

Mejores prácticas para reglas de seguridad

Uso de grupos de seguridad de red

Se recomienda utilizar NSG para los componentes que tienen la misma posición de seguridad. Por ejemplo, en una arquitectura de varios Niveles, tendría un NSG independiente por cada nivel. Todos los VNIC de nivel pertenecerían al NSG de ese nivel. En un nivel determinado, es posible que tenga un subconjunto determinado de las VNIC del nivel que tienen requisitos de seguridad especiales y adicionales. Por lo tanto, debe crear otro NSG para esas reglas suplementarias y colocar ese subconjunto de VNIC en el NSG del nivel y el NSG extra.

Oracle también recomienda usar NSG porque Oracle prioriza los NSG antes que las listas de seguridad cuando se implantan mejoras futuras.

Familiarización con las reglas de la lista de seguridad predeterminada

Una VCN incluye automáticamente una lista de seguridad por defecto que contiene varias reglas de seguridad por defecto que sirven de ayuda para empezar a utilizar el servicio de redes. Esas reglas existen porque activan la conectividad básica. Incluso si no utiliza las listas del seguro o la lista del seguro por defecto, es conveniente familiarizarse con las reglas para comprender mejor los tipos de tráfico que requieren los recursos en la nube en red. Es posible que desee usar esas reglas en el NSG o cualquiera de las listas de seguridad personalizadas que se configure.

La lista de seguridad por defecto no incluye reglas para activar el ping. Si necesita utilizar el ping, consulte Reglas para activar el ping.

No eliminar reglas de seguridad predeterminadas de forma indiscriminada

Es posible que una VCN tenga subredes que utilicen la lista por defecto de seguridad. No suprima ninguna de las reglas de seguridad por defecto de la lista a menos que haya confirmado primero que los recursos de la VCN no los necesitan. De lo contrario, puede interrumpir la conectividad de la VCN.

Confirmar que las reglas de firewall del sistema operativo se alinean con las reglas de seguridad

Las instancias informáticas que ejecutan imágenes de plataforma también tienen reglas del firewall del sistema operativo que controlan la instancia. Al solucionar problemas de acceso a una instancia, asegúrese que todos los elementos siguientes están definidos correctamente:

  • Las reglas de los grupos de seguridad de red en los que está la instancia
  • Las reglas de las listas de seguridad asociadas a la subred de la instancia
  • Las reglas de firewall del sistema operativo de la instancia

Si una instancia está ejecutando Oracle Autonomous Linux 8.x, Oracle Autonomous Linux 7, Oracle Linux 8, Oracle Linux 7 u Oracle Linux Cloud Developer 8, debe usar firewalld para interactuar con las reglas de iptables. A continuación se muestran los comandos para abrir un puerto (1521 en este ejemplo):

sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
								
sudo firewall-cmd --reload

Para instancias con un volumen de inicio iSCSI, el comando --reload anterior puede causar problemas. Para obtener información detallada y una solución alternativa, consulte Bloqueo del sistema de experiencias en instancias al ejecutar el firewall-cmd --reload.

Uso de métricas de VNIC para solucionar problemas de paquetes anulados debido a reglas de seguridad

El servicio de Networking ofrece métricas para VNIC, que muestran los niveles de tráfico de VNIC (paquetes y bytes). Dos de las métricas son para paquetes de entrada y salida que violan las reglas de seguridad y, por lo tanto, se anulan. Puede utilizar estas métricas para ayudarle a resolver problemas relacionados con reglas de seguridad y si las VNIC reciben el tráfico adecuado.

Uso combinado de listas de seguridad y grupos de seguridad de red

Solo se pueden utilizar listas de seguridad o grupos de seguridad de red, o también ambos elementos juntos. Depende de las necesidades específicas de seguridad.

Si tiene reglas de seguridad que desea aplicar para todos las VNIC de una VCN, la solución más sencilla consiste en colocar las reglas en una sola lista de seguridad y, a continuación, asociar esa lista de seguridad a todas las subredes de la VCN. De esta manera, puede asegurarse de que se aplican las reglas, independientemente de quién cree una VNIC en la VCN. Una opción es utilizar la lista de seguridad predeterminada de la la VCN, que se incluye automáticamente en la VCN y contiene un conjunto de reglas esenciales por defecto.

Si utiliza de forma agregada listas y grupos del sistema de seguridad, el conjunto de reglas que se aplica a una VNIC concreta es la unión de estos elementos:

  • Las reglas de las listas de seguridad asociadas a la subred de la VNIC
  • Las reglas de seguridad de todos los NSG en los que se encuentra la VNIC

El siguiente diagrama de Venn es una ilustración de la idea.

Una VNIC está sujeta a las reglas de todos los grupos de seguridad de red en los que está y todas las listas de seguridad asociadas a su subred.

La VNIC 1 está cubierta por la lista de seguridad 1, la lista de seguridad 2, el NSG A y el NSG B. Se permite un paquete en cuestión si cualquier regla de las listas y grupos relevantes permite el tráfico (o si el tráfico es parte de una conexión que se está realizando). Una advertencia es si las listas vienen a contener reglas con estado y sin Estado que cubren el mismo tráfico. Para obtener más información, consulte Stateful Compared to Stateless Rules.

Partes de una regla de seguridad

Una regla de seguridad permite un tipo concreto de tráfico dentro o fuera de una VNIC. Por ejemplo, una regla que se suele utilizar permite que el tráfico del puerto 22 de TCP de entrada para establecer conexiones SSH con la instancia (más concretamente las VNIC de la instancia). Sin reglas de seguridad, no se permite tráfico en las VNIC ni fuera de ellos en la VCN.

Nota

Las reglas de seguridad no se aplican al tráfico que implica el bloque CIDR 169.254.0.0/16, que incluye servicios como iSCSI y metadatos de instancia.

Cada regla de seguridad especifica los siguientes elementos:

  • Dirección (entrada o salida): el tráfico de entrada es el que se recibe y el de salida, el que se envía desde la VNIC. El modelo de API de REST para las listas de seguridad es diferente de los grupos de seguridad de red. Con las listas de seguridad hay un objeto de IngressSecurityRule y un objeto de EgressSecurityRule independiente. Con el grupo de seguridad de red sólo hay un objeto SecurityRule y el atributo direction del objeto muestra si la regla es para los tráficos de entrada o salida.
  • Con estado o sin estado: si se tiene estado, se utiliza el seguimiento de conexión para el tráfico que coincide con la regla. Si no tiene estado, no se utiliza ningún seguimiento de conexión. Consulte Stateful Compared to Stateless Rules.
  • Origen y tipo de origen (solo reglas de entrada): el origen que proporcione para una regla de entrada depende del tipo de origen seleccionado.

    Tipos de orígenes permitidos
    Tipo de origen Origen permitido
    CIDR Bloque CIDR desde el que se origina el tráfico. Utilice 0.0.0.0/0 para indicar todas las direcciones IP. El prefijo es necesario (por ejemplo, incluya el /32 si especifica una dirección IP individual). Para obtener más información sobre la notación CIDR, consulte RFC1817 y RFC1519.
    Grupo de seguridad de red

    Grupo de seguridad de red en la misma VCN que el grupo de seguridad de red de esta regla.

    Este tipo de origen está disponible solo si la regla pertenece a un NSG, y no a una lista de seguridad.

    Servicio

    Solo para los paquetes que provienen de un servicio de Oracle mediante un gateway de servicio. Si un gateway de servicios no está presente en una VCN, el tráfico que proviene de la IP pública de un punto final de OSN se puede enrutar a una VCN mediante un gateway de NAT o un gateway de Internet. El tráfico sigue recorriendo el eje principal de OCI a la VCN.

    El servicio de origen es la etiqueta CIDR del servicio en la que está interesado.

  • Tipo de destino y destino (solo reglas para salida): el destino que se proporciona para una regla de entrada depende del tipo de destino que seleccione.

    Tipos de destino permitidos
    Tipo de destino Destino permitido
    CIDR Bloque CIDR al que se dirige el tráfico. Utilice 0.0.0.0/0 para indicar todas las direcciones IP. El prefijo es necesario (por ejemplo, incluya el /32 si especifica una dirección IP individual). Para obtener más información sobre la notación CIDR, consulte RFC1817 y RFC1519.
    Grupo de seguridad de red

    Un NSG en la misma VCN que el NSG de esta regla.

    Este tipo de destino solo está disponible si la regla pertenece a un NSG, y no a una lista de seguridad.

    Servicio

    Solo para paquetes que van a un servicio de Oracle (como Object Storage) a través del gateway de servicio. Si un gateway de servicio no esta presente en una VCN, el tráfico destinado a la IP pública de un punto final de OSN puede enrutarse a OSN a través del gateway de NAT o un gateway de Internet. El enrutamiento mediante una puerta de enlace de servicio le permite seleccionar a qué puntos finales de la red de servicios de Oracle (OSN) desea encaminar el tráfico (seleccione Solo almacenamiento de objeto o Todos los servicios).

    El servicio de destino es la etiqueta CIDR del servicio de OSN en la que está interesado.

  • Protocolo IP: un único protocolo IPv4 o "todos" para cubrir todos los protocolos.
  • Puerto de origen: puerto desde el que se origina el tráfico. Para TCP o UDP, puede especificar todos los puertos de origen u, opcionalmente, especificar un único número de puerto de origen o un rango.
  • Puerto de destino: puerto al que se dirige el tráfico. Para TCP o UDP, puede especificar todos los puertos de destino u, opcionalmente, especificar un único número de puerto de destino o un rango.
  • Tipo y código ICMS: para ICMP, puede especificar todos los tipos y códigos o especificar de manera optativa un solo tipo ICMP con un código opcional. Si el tipo tiene diferentes códigos, cree una regla independiente para cada código que desee permitir.
  • Descripción (solo reglas del NSG): las reglas de seguridad del NSG incluyen un atributo opcional, mediante el que se puede proporcionar una descripción fácil de recordar de la regla. No se admite para las reglas de lista de seguridad.

Para ver ejemplos de reglas de seguridad, consulte Escenarios de Networking.

Para conocer el límite del número de reglas que puede tener, consulte Comparación de listas de seguridad y grupos de seguridad de red.

Nota

Si usa los NSG y dos VNIC que están en la misma VCN necesitan comunicarse mediante sus direcciones IP públicas, debe usar la dirección IP pública de la VNIC, no el NSG de la VNIC como el origen (para entrada) o el destino (para salida) en las reglas de seguridad relevantes. El paquete se enruta al gateway del internet de la VCN y, en ese momento, la información del NSG del VNIC no está disponible Por lo tanto, una regla que especifica el NSG como origen o destino no es efectiva a la hora de permitir ese tipo específico de tráfico.

Con estado en comparación con las reglas sin estado

Al crear una regla de seguridad, se selecciona si es con estado o sin estado. La diferencia se describe en las secciones siguientes. El valor predeterminado es con estado. Se recomiendan reglas sin estado si se tiene un sitio web orientado a internet de gran volumen (para el tráfico HTTP/HTTPS).

En esta sección se hace referencia a las instancias de Compute y su tráfico. Sin embargo, la discusión se aplica a todos los tipos de recursos con las VNIC. Consulte Comparación de listas de seguridad y grupos de seguridad de red.

Reglas con estado

Al marcar una regla de seguridad con estado se indica que se va a utilizar el seguimiento de conexiones para cualquier tráfico que coincida con esa regla. Esto significa que, cuando una instancia recibe tráfico que coincide con la regla de entrada con estado, se realiza un seguimiento de la respuesta y se permite de forma automática para el host de origen, independientemente de las reglas de salida aplicables a la instancia. Asimismo, cuando una instancia envía tráfico que coincida con una regla de salida con estado, la respuesta entrante se permite automáticamente, con independencia de las reglas de entrada.

Por ejemplo, puede tener una regla de seguridad de entrada con estado para una instancia (instancia A) que deba recibir y responder al tráfico HTTP desde el host B. El host B puede ser cualquier host, ya sea una instancia o no. La instancia A y el host B se comunican porque la regla de entrada con estado permite el tráfico de cualquier dirección IP de origen (0.0.0.0/0) solo al puerto de destino 80 (protocolo TCP). No se necesita ninguna regla de entrada para permitir el tráfico de respuesta porque se permite y se realiza un seguimiento de ellas automáticamente.

Regla de entrada con estado que permite el tráfico HTTP entrante y la respuesta
Nota

Las reglas con estado almacenan información en una tabla de seguimiento de conexiones de cada instancia informática. El tamaño de esa tabla es específico de la unidad de computación que se está utilizando (consulte la página de límites de servicio para Seguimiento de conexiones). Cuando la tabla de seguimiento de conexiones está llena, no se puede agregar nueva información de estado y las nuevas conexiones experimentan pérdida de paquetes. El uso de una unidad de computación más grande permite tener una tabla más grande, pero puede que no sea suficiente para evitar la pérdida de paquetes al utilizar reglas con estado.

Si una subred tiene un volumen de tráfico alto, se recomienda utilizar reglas sin estado en lugar de reglas con estado.

Reglas sin estado

Si se define una regla a la seguridad sin estado, no podrá utilizar el seguimiento a ninguna conexión para ningún tráfico que coincida con esa regla. Esto significa que el tráfico de respuesta no se permite automáticamente. Para permitir el tráfico de respuesta para una regla de entrada sin estado, debe crear la regla de salida sin estado correspondiente.

La siguiente figura muestra la instancia A y el host B como antes, pero ahora con las reglas de seguridad sin estado. Al igual que con la regla con estado en la sección anterior, la regla de entrada sin estado permite el tráfico de todas las direcciones IP y de cualquier puerto, solo en el puerto de destino 80 (con el protocolo TCP). Para permitir el tráfico de respuesta, debe haber una regla de salida sin estado correspondiente que permita el tráfico a cualquier dirección IP de destino (0.0.0.0/0) y todos los puertos, desde el puerto de origen 80 únicamente (mediante el protocolo TCP).

Reglas de entrada y salida sin estado que permiten la respuesta y el tráfico HTTP entrante

Si la instancia A necesita, en cambio, para iniciar el tráfico HTTP y obtener la respuesta, se requiere un conjunto diferente de reglas sin estado. Como se muestra en la siguiente figura, la regla de salida tendría el puerto de origen = todos y el puerto de destino = 80 (HTTP). La regla de entrada tendría entonces el puerto de origen 80 y el puerto de destino = todos.

Reglas de entrada y salida sin estados que permiten que la instancia inicie el tráfico HTTP y obtenga la respuesta

Si va a utilizar el enlace de puerto en la instancia A para especificar exactamente de qué puerto procede el tráfico HTTP, puede especificar aquel como puerto de origen en la regla de salida y el puerto de destino en la regla de entrada.

Nota

Si, por algún motivo, utiliza reglas tanto con estado como sin este, y existe un tráfico con estado y sin este en una dirección determinada (por ejemplo, entrada), la regla sin este estado tiene prioridad y la conexión no se realiza el seguimiento. Necesitaría una regla correspondiente en la otra dirección (por ejemplo, salida, sin estado o con estado) para que se permita el tráfico de respuesta.

Detalles de seguimiento de conexiones para reglas con estado

Oracle utiliza el seguimiento de conexión para permitir respuestas para el tráfico que coincide con las reglas con estado (consulte Reglas con Estado Comparado con Sin Estado). Cada instancia tiene un número máx. de conexiones simultáneas del que se puede hacer un seguimiento, según la unidad de la instancia.

Para decidir el tráfico de respuesta para TCP, UDP e ICMP, Oracle realiza la conexión en estos elementos para el paquete:

  • Protocolo
  • Direcciones IP de origen y destino
  • Puertos de origen y destino (solo para TCP y UDP)
Nota

Para otros protocolos, Oracle solo realiza el seguimiento de las direcciones IP y protocolo, y no de los puertos. Esto significa que cuando una instancia inicia un tráfico a otro host y el tráfico se permite mediante las reglas que la instancia recibe más tarde de ese host durante un período se considera tráfico en respuesta y se permite.

Las conexiones con seguimiento se mantienen siempre que se reciba tráfico para la conexión. Si una conexión permanece inactiva el tiempo suficiente, se agota el tiempo de espera y se elimina. Después de eliminar la conexión, se borran las respuestas de una regla de seguridad con estado. En la siguiente tabla, se muestran los timeouts de inactividad por defecto:

Timeouts de inactividad
Protocolo Estado Timeout de inactividad
TCP Establecida 1 día
TCP Configurada 1 minuto
TCP Cierre 2 minutos
UDP Establecida (esto significa que un paquete se recibe en ambas direcciones) 3 minutos
UDP No establecida (el paquete se recibe solo en una dirección) 30 segundos
ICMP NO APLICABLE 15 segundos
Otros NO APLICABLE 5 minutos

Activación de mensajes de descubrimiento de la MTU de la ruta para reglas sin estado

Si decide utilizar reglas de seguridad sin estado para permitir que el tráfico bidireccional con los puntos finales fuera de la VCN, es importante agregar una regla de seguridad que permita el tipo de tráfico ICMP de tipo 3, código 4 desde el origen 0.0.0.0/0 y cualquier puerto de origen. Esta regla permite a las instancias informáticas recibir mensajes que detectan la MTU de ruta. Esta regla resulta crítica para establecer una conexión con las instancias. Sin ella, puede experimentar problemas de conectividad. Para obtener más información, consulte Conexiones que se cuelgan.

Reglas para activar el ping

La lista de seguridad predeterminada de la VCN contiene varias reglas predeterminadas, pero ninguna que permita solicitudes de ping. Para hacer ping a una instancia, asegúrese que las listas de seguridad aplicables o el NSG de esta instancia incluyan una regla adicional con estado para permitir específicamente el tipo del tráfico 8 de ICMP desde el origen en la que se desea hacer ping. Para permitir el acceso de ping desde internet, utilice 0.0.0.0/0 para el origen. Tenga en cuenta que esta regla de ping es independiente de las reglas relacionadas con ICMP predeterminadas en la lista de seguridad predeterminada. No elimine esas reglas.

Reglas para gestionar paquetes UDP fragmentados

Las instancias pueden enviar o recibir tráfico UDP. Si un paquete UDP es demasiado grande para la conexión, se fragmentará. Sin embargo, solo el primer fragmento del paquete contiene la información de protocolo y puerto. Si las reglas de seguridad que permiten este tráfico de entrada y salida especifican un número de puerto determinado (de origen o de destino), los fragmentos posteriores al primero se anulan. Si espera que las instancias informáticas envíen o reciban paquetes UDP grandes, establezca los puertos de origen y destino para las reglas del sistema de seguridad aplicables como ALL (en lugar de un número del puerto concreto).