Reglas de seguridad

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.

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

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

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.

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

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

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:

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.