Reglas de seguridad

Acerca de las VNIC y los recursos principales

Una VNIC es un componente de servicio de Networking que permite que un recurso en red, como una instancia informática, se conecte a una red virtual en la nube (VCN). La VNIC determina cómo se conecta la instancia con los puntos finales dentro y fuera de la VCN. Cada VNIC reside en una subred de una VCN.

Cuando crea una instancia informática, 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 informática. Por este motivo, las VNIC de una instancia se muestran de forma destacada como parte de los recursos relacionados de una instancia informática en la consola.

Hay otros tipos de recursos principales que se pueden crear que también dan lugar a la creación automática de una VNIC. Por ejemplo, al crear un equilibrador de carga, el servicio Equilibrador de carga crea automáticamente VNIC para equilibrar el tráfico en el juego de backends. Además, al crear un sistema de base de datos, el servicio de Database 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 fácilmente visibles en la consola de la misma forma que lo son las VNIC para las instancias informáticas.

Para usar una NSG, se colocan las VNIC de su elección en el grupo. 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 informática, puede especificar opcionalmente un NSG para la instancia. Aunque conceptualmente coloca la instancia en el grupo, en realidad está aplicando el VNIC principal de la instancia en el grupo de seguridad de red. 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 todos las VNIC de un NSG determinado deben estar en la VCN al que pertenece el NSG.

Del mismo modo, cuando coloca un equilibrador de carga en un grupo de seguridad de red, conceptualmente coloca el equilibrador de carga en el grupo. Sin embargo, en realidad, coloca las VNIC gestionadas por el servicio Equilibrador de carga en el grupo de seguridad de red.

La pertenencia al VNIC de un NSG se gestiona en el recurso principal, no en el propio NSG. En otras palabras, para agregar un recurso principal a un grupo de seguridad de red, puede ejecutar la acción en el recurso principal (mediante la especificación de los grupos de seguridad de red a los que se debe agregar el recurso principal). No se ejecuta la acción en el grupo de seguridad de red (mediante la especificación de qué VNIC o recursos principales se deben agregar al grupo de seguridad de red). De manera similar, para eliminar una VNIC de un grupo de seguridad de red, puede ejecutar esa acción actualizando el recurso principal, no el grupo de seguridad de red. Por ejemplo, para agregar una VNIC de una instancia informática existente a un NSG, actualice las propiedades de la 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 pueden 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

Hay una diferencia importante en cómo se pueden escribir reglas de seguridad para 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 salida). 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 una NSG específica, puede escribir reglas que especifiquen 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

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

Reglas predeterminadas

VCN proporciona automáticamente una lista de seguridad predeterminada que contiene varias reglas de seguridad predeterminadas que sirven de ayuda para empezar a utilizar el servicio de Networking. Al crear una subred, la lista de seguridad predeterminada se asocia a la subred a menos que se especifique una lista de seguridad personalizada ya creada en la VCN.

En comparación, la VCN NO tiene ningún grupo de seguridad de 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.

Uso de grupos de seguridad de red

Oracle 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 las VNIC de un nivel determinado pertenecen a la 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 adicionales y especiales. Por lo tanto, debe crear otro NSG para esas reglas adicionales y colocar ese subconjunto de VNIC en el NSG del nivel y en el NSG adicional.

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

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

VCN proporciona automáticamente una lista de seguridad predeterminada que contiene varias reglas de seguridad predeterminadas que sirven de ayuda para empezar a utilizar el servicio de Networking. Esas reglas existen porque activan la conectividad básica. Incluso si decide no utilizar las listas de seguridad o la lista de seguridad predeterminada, es preciso familiarizarse con las reglas para comprender mejor los tipos de tráfico que necesitan los recursos en la nube conectados a la red. Es posible que desee usar esas reglas en los NSG o en cualquier lista de seguridad personalizada que se configure.

La lista de seguridad predeterminada 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

De manera predeterminada, la VCN puede tener subredes que utilizan la lista de seguridad por defecto. No elimine ninguna de las reglas de seguridad predeterminadas de la lista a menos que haya confirmado antes que los recursos de la VCN no las necesiten. De lo contrario, es posible que se interrumpa la conectividad de la VCN.

Confirmación de que las reglas del firewall del sistema operativo se alinean con las reglas de seguridad

sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
								
sudo 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 deseado.

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 salida para permitir el tráfico de respuesta, ya que automáticamente se permiten las respuestas y se realiza un seguimiento de ellas.

Reglas sin estado

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).

Si la instancia A necesita, en cambio, 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.

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.

Detalles de seguimiento de conexiones para reglas con estado

Oracle utiliza el seguimiento de conexiones para permitir respuestas para el tráfico que coincide con las reglas con estado (consulte Reglas con estado frente a sin estado). Cada instancia tiene un número máximo de conexiones simultáneas de las que se puede realizar un seguimiento, según la unidad de computación de la instancia.

Para determinar el tráfico de respuesta para TCP, UDP e ICMP, Oracle realiza el seguimiento de 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)

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 producirá un timeout y se eliminará. Una vez eliminadas, las respuestas para una regla de seguridad con estado se borrarán. En la siguiente tabla, se muestran los timeouts de inactividad por defecto:

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 recibir mensajes de fragmentación del descubrimiento de la MTU de la ruta. Esta regla resulta crítica para establecer una conexión con sus instancias. Sin ella, puede experimentar problemas de conectividad. Para obtener más información, consulte Conexiones que se cuelgan.