Nota:

Uso del firewall de red de OCI para proxy de reenvío SSL e inspección de entrada mediante la regla de descifrado

Introducción

El servicio de firewall de red de Oracle Cloud Infrastructure (OCI) es una solución de firewall gestionado basada en la nube que utiliza la tecnología de firewall de última generación (NGFW) de Palo Alto Networks. Con sus capacidades de firewall de tecnología puntera basadas en aprendizaje automático, el servicio OCI Network Firewall proporciona una protección de primera categoría para sus cargas de trabajo de OCI, todo ello sin esfuerzo para utilizarlo en el ecosistema de OCI.

El firewall de red de OCI inspecciona todas las solicitudes, incluido el tráfico cifrado de seguridad de capa de transporte (TLS), a medida que pasa por el firewall. En función de las reglas de política de firewall definidas por el usuario, el servicio puede realizar diversas acciones, como permitir, rechazar, borrar, detectar intrusiones o prevenir. Con estas funciones sólidas, OCI Network Firewall es una potente herramienta para proteger sus cargas de trabajo de OCI frente a una variedad de amenazas de seguridad.

Objetivos

El objetivo de este tutorial es proporcionar una guía completa para implementar el proxy de reenvío SSL y la inspección de entrada mediante reglas de descifrado en el firewall de última generación en OCI Cloud.

Si sigue este tutorial, obtendrá un conocimiento sólido del proxy de reenvío SSL y la inspección de entrada mediante reglas de descifrado, y podrá aplicar este conocimiento para proteger su infraestructura de red en OCI Cloud.

Requisitos

Nota: Se recomienda tener un entorno de prueba configurado en OCI para experimentar con configuraciones de firewall y reglas de descifrado antes de implementarlas en un entorno de producción.

Arquitectura

Arquitectura

La política de firewall de red de OCI consta de listas que incluyen:

caso de prueba

Para este tutorial, hemos creado una conexión SSH con la máquina de Linux (en la subred pública: 129.146.201.118) a través de Internet con una regla de seguridad en la política de firewall.

Ahora tiene una idea de cómo se pueden utilizar las listas para crear reglas de seguridad para el firewall. Mediante esta regla, hemos realizado un SSH en la máquina de Linux.

Comprender la tecnología de cifrado TLS/SSL

Nota:

TLS es un protocolo criptográfico que proporciona seguridad integral para cualquier dato enviado entre aplicaciones a través de Internet. Los escenarios más comunes están en navegación web segura. Sin embargo, también puede y debe utilizarse para otras aplicaciones como correo electrónico, transferencias de archivos, videoconferencia/audioconferencia, mensajería instantánea y voz sobre IP, etc.

Es importante comprender que TLS no protege los datos en los sistemas finales. Garantiza la entrega segura de datos a través de Internet, evitando posibles intrusiones y/o alteraciones del contenido que se envía (en tránsito). TLS se suele implementar sobre TCP para cifrar protocolos de capa de aplicación como HTTP, FTP, SMTP e IMAP, aunque también se puede implementar en UDP, DCCP y SCTP.

Para proteger los datos, TLS se basa en la tecnología de criptografía para cifrar/descifrar los datos en tránsito que se envían a través de Internet. Cubriremos términos y conceptos como criptografía simétrica y asimétrica, infraestructura de clave pública (PKI) y certificados digitales X.509.

Para configurar, configurar y aplicar el firewall de última generación a la red, debe comprender cómo funcionan las conexiones TLS (como https), incluida la configuración y el despliegue de certificados X.509 digitales.

Cifrado y tipos

La idea detrás del cifrado es precisamente ocultar u ocultar (cifrar) la información que queremos enviar de A a B en un "canal seguro". Un canal inseguro es un canal o un camino en el que no podemos garantizar que nadie intercepte, robe o modifique (evite) la información transmitida de A a B y al revés.

La criptografía nos permite proteger la información que recorre un canal inseguro, cifrando (concebiendo) los datos originales hacia su destino. Una vez recibido por elreceptor, el receptor será capaz de descifrar los datos cifradosrecibidos hasta su valor original.

Hay dos tipos de cifrado: Simétrico y asimétrico.

Cifrado simétrico

Para cifrar/descifrar un fragmento de datos, los motores de cifrado simétrico utilizan exactamente la misma clave para cifrar y descifrar los datos. Normalmente se denomina clave maestra o secreto compartido.

Cifrado de clave maestra

Aunque suena como una forma fácil de lograr el cifrado, el principal problema aquí es distribuir la clave maestra entre las dos partes a través de un canal no seguro. Este proceso de intercambio de claves maestras se abordará en este tutorial utilizando diferentes técnicas, incluida una técnica que se explica en la siguiente sección: cifrado asimétrico.

Algunos de los algoritmos de cifrado simétrico más comunes son: AES128, AES256, Serpent, Camelia, etc.

Cifrado asimétrico

La criptografía/cifrado asimétrico utiliza un par de claves relacionadas con una relación especial: cualquier dato que cifre con una de las claves de pares puede descifrarse SOLO mediante la otra clave de par y al revés.

Cifrado asimétrico

Normalmente, hacemos referencia a este par de claves como clave pública y clave privada. La clave pública se puede compartir con todos, mientras que la clave privada se debe mantener en secreto.

El cifrado asimétrico resuelve el problema de la distribución de claves mediante el uso de claves públicas para el cifrado y claves privadas para el descifrado (o al revés). Sin embargo, la desventaja es que los sistemas de cifrado asimétricos son muy lentos en comparación con los sistemas simétricos y requieren mucha más potencia informática debido a sus longitudes de clave mucho más largas.

Los algoritmos de cifrado simétricos son mucho más rápidos y requieren menos potencia computacional, pero su principal debilidad es la distribución de claves, ya que la misma clave se utiliza para cifrar y descifrar información, esa clave se debe distribuir a cualquier persona que necesite acceder a los datos.

TLS utiliza cifrado asimétrico y simétrico, no solo para cifrar datos, sino para autenticar las partes implicadas en la conexión. Aquí es donde los certificados X.509 realizan acciones.

Certificados X.509

Un certificado X.509 es un certificado digital basado en el estándar X.509 de la Unión Internacional de Telecomunicaciones (UIT) ampliamente aceptado, que define el formato de los certificados de infraestructura de clave pública ( PKI). Un certificado X.509 se diseña mediante un par de claves que consta de una clave pública relacionada y una clave privada. Como hemos mencionado anteriormente, este par de claves es precisamente el par de claves que se utilizan en el cifrado asimétrico, donde elegimos una para ser pública y la otra para ser privada. Recuerde que cualquier elemento que cifre con una de las claves solo se puede descifrar con la otra clave y viceversa.

Como puede imaginar, la parte pública del par de claves, como su nombre lo indica, es pública y se puede distribuir libremente. La clave privada debe estar conectada de forma segura y, a menudo, cifrada con una clave maestra en modo de cifrado simétrico, por lo que nadie puede utilizarla incluso si es robada.

Además de la clave pública, el certificado X.509 contiene otra información que representa una identidad (un nombre de host, una organización o una persona), por lo tanto, el certificado x.509 enlaza esta identidad con la clave pública incluida.

La estructura de un certificado digital X.509 v3 es la siguiente:

Certificado

Número de Versión

Número de Serie

ID de algoritmo de firma

Nombre del Emisor

Período de validez

No Antes de

No Después de

Nombre de tema

Información de clave pública de asunto

Algoritmo de clave pública

Clave pública de asunto Esta es la clave pública

Identificador único de emisor (opcional)

Identificador único de sujeto (opcional)

Extensiones (opcional)

…

algoritmo de firma de certificado

Firma de certificado

La clave pública está enlazada a una identidad representada en el nombre del asunto, que es una cadena con el siguiente formato:

donde, Asunto: C = EE. UU., ST = California, L = Mountain View, O = Google LLC, CN = *.google.com

Por lo tanto, esta identidad pertenece a Google, en el país de EE. UU., el estado de California y un nombre común es *.google.com.

Podemos utilizar este certificado para dos propósitos: distribuir nuestra clave pública y autenticar nuestra identidad a otros. Teniendo esto en cuenta, cualquier computadora/móvil/dispositivo fuera allí, al recibir nuestro certificado, será propietario de nuestra clave pública e identidad, por lo tanto, será capaz de enviar información cifrada utilizando la clave pública, y solo podremos descifrarla (con la clave privada). Además, el certificado tiene nuestra identidad dentro, por lo que el dispositivo que lo recibe podrá confiar en esta identidad y asegurarse de que está intercambiando información con la identidad correcta.

Como hemos mencionado anteriormente, el cifrado asimétrico a través de claves públicas/privadas es mucho más lento que el cifrado simétrico (x4 o más), por lo que no es viable. Además, no hemos explicado cómo el dispositivo que recibe el certificado puede realmente confiar en la identidad dentro del certificado. Al final, el certificado X.509 es solo un fragmento de texto recibido a través de un canal seguro. Para confiar/autenticar un certificado recibido, se requiere una autoridad de certificación, una organización que es de confianza para firmar certificados digitales. Una autoridad de certificación verifica la identidad y legitimidad de la compañía o persona que solicitó un certificado y, si la verificación se realiza correctamente, la CA emite un certificado firmado. Algunos ejemplos de organizaciones de CA son Oracle, VeriSign, D-Trust, DigiCert entre otros.

Entonces, desde una perspectiva criptográfica, ¿cómo funciona este proceso de firma? De nuevo, utilizaremos la potencia del cifrado asimétrico para esto, de la siguiente manera:

Por lo tanto, ahora que tenemos nuestro certificado X.509 listo para tomar medidas. ¿Cómo un equipo/móvil/dispositivo que recibe este certificado durante una conexión TLS puede verificar si es un certificado X.509 válido? De nuevo, utilizaremos la potencia del cifrado asimétrico, de la siguiente manera:

Ahora que sabemos que tenemos un certificado válido que incluye el nombre de dominio al que estamos intentando conectarse, por ejemplo, www.mycompanycomain.com (incluido en los campos de nombre común o de nombre alternativo del asunto del certificado), el equipo/móvil/explorador se asegurará de que estamos conectando realmente a ese nombre de dominio DNS (www.mycompanycomain.com) y no a otro. Esta es una validación obligatoria, ya que cualquiera puede robar el certificado X.509 e intentar utilizarlo desde otro servidor de dominio DNS (www.myfakecompany.com, etc.) y pasaría el proceso de validación de firma de CA.

Por lo tanto, ahora todos los ordenadores / móviles / dispositivos por ahí pueden descargar la clave pública de nuestro Certificado y enviar datos cifrados para que solo podamos descifrarlo. Dado que el cifrado asimétrico es mucho más lento que el cifrado simétrico (x4 o más), no es viable. La solución es utilizar ambos y aquí es donde se requiere SSL/TLS.

Conceptos Básicos de TLS

TLS es un protocolo criptográfico que proporciona seguridad de extremo a extremo de los datos que se envían entre aplicaciones a través de Internet. La mayoría de los usuarios conocen su uso en la navegación web segura y, en particular, el icono de candado que aparece en los exploradores web cuando se establece una sesión segura.

TLS utiliza una combinación de criptografía simétrica y asimétrica, ya que esto proporciona un buen compromiso entre el rendimiento y la seguridad al transmitir datos de forma segura. Recuerde que la criptografía asimétrica requiere 4 veces o más potencia computacional que la criptografía simétrica. Sin embargo, la criptografía simétrica requiere la misma clave maestra en ambos lados de la comunicación para poder cifrar/descifrar el mensaje, por lo que el objetivo de usar cifrado simétrico es, para poder intercambiar la primero la clave maestra (o el secreto compartido) entre las dos partes en un canal no seguro y, a continuación, empiece a utilizar esta clave maestra para proteger la comunicación, cifrando/descifrando cada mensaje que se envía/recibe utilizando el motor simétrico elegido.

TLS, imagen de hacker

Para intercambiar una clave maestra a través de un canal no seguro, TLS utilizará dos técnicas diferentes que siguen el mismo objetivo, que es intercambiar la clave maestra/secreto compartido de forma segura en un canal no seguro:

La metodología RSA se basará en el uso de la potencia del cifrado asimétrico (clave pública y privada) para intercambiar la clave maestra a través de un canal no seguro.

DHE/ECDHE se basará en el uso de cálculos matemáticos para generar la misma clave maestra entre dos partes en un canal no seguro. Ambas partes intercambiarán cierta información benigna que se mezclará con su información privilegiada mientras viaja por un canal inseguro y se puede capturar sin ningún riesgo. Al final de la negociación, ambos cálculos matemáticos de las dos partes terminarán en el mismo secreto común o clave maestra. Más información https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

Estas dos metodologías de intercambio de claves tienen lugar durante un proceso denominado shake de TLS.

Establecimiento de comunicación de TLS desenmascarado

Un protocolo SSL/TLS es una negociación entre dos partes de una red, como un explorador y un servidor web, para establecer los detalles de su conexión. Durante esa negociación, las dos partes autenticarán (mediante certificados X509), acordarán un conjunto de cifrado (cómo se intercambiará la clave maestra y qué motores de criptografía se utilizarán, como AES256, 128, hashing). como SHA1, 2, etc.) y, por último, cuando se produzca la autenticación (certificado válido recibido) y se acepte cómo establecer un canal seguro realizado, tendremos un canal seguro de ambas partes. Estos son los pasos reales:

Establecimiento de comunicación de TLS

Observe que en el gráfico anterior, estamos utilizando RSA (clave privada/pública) para intercambiar la clave maestra (o secreta compartida) que se utilizará en el motor de cifrado simétrico acordado (es decir, AES256) durante la negociación del conjunto de cifrado. Si se utilizara DHE/ECDHE, en lugar de utilizar una clave pública y privada para intercambiar la clave maestra, ambas partes usarían cálculos de DHE, intercambiando material benigno, para terminar calculando el mismo resultado en ambas partes. Ese resultado se convertirá en la clave maestra (secreto compartido) que se utilizará para el cifrado simétrico.

Tarea 1: Uso del firewall de red de OCI para proxy de reenvío SSL e inspección de entrada mediante la regla de descifrado

  1. Cree dos certificados autofirmados con openssl para el tráfico saliente y la inspección entrante mediante SSL abierto en la máquina Linux. Actualice la máquina de Linux para confiar en el certificado.

    Creación de certificados autofirmados

  2. Cree un almacén en OCI.

    Vault

  3. Después de crear el almacén, cree una clave. El contenido del secreto debe tener el siguiente formato.

    {

"caCertOrderedList":

[

"-----BEGIN CERTIFICATE

-----END CERTIFICATE-----\n"

],

"certKeyPair":

{

"cert" : "-----BEGIN CERTIFICATE

-----END CERTIFICATE----\n",

"key": "-----BEGIN RSA PRIVATE KEY

-----END RSA PRIVATE KEY----\n"

}

}

  4. En la política de firewall de red, agregue el secreto asignado.

    1. Seleccione Tipo de secreto asignado como proxy de reenvío SSL o inspección de entrada SSL.

    2. Seleccione el almacén creado.

    3. Seleccione el secreto.

    4. Agregue el secreto asignado.

      Secreto asignado

  5. Cree un perfil de descifrado.

    1. Seleccione el proxy de reenvío SSL y compruebe las opciones de verificación del certificado de servidor o elija la inspección de entrada SSL y compruebe las comprobaciones de modo no soportadas que son necesarias para el tráfico.

      perfil de descifrado hacia adelante

      perfil de descifrado entrante

    2. Agregue un perfil de descifrado.

      Agregando perfil de descifrado

  6. Cree una regla de descifrado.

    1. Seleccione las direcciones IP de origen de la lista de direcciones IP que ha creado en la política o elija alguna.

    2. Seleccione las direcciones IP de destino de la lista de direcciones IP que ha creado en la política o elija alguna.

      Dirección IP de destino

    3. Seleccione Acción para descifrar el tráfico con proxy de reenvío SSL, SSL entrante o sin descifrado.

    4. Seleccione el perfil de descifrado y el secreto asignado.

      Comprobación del perfil de descifrado

Una vez que la política se actualiza con la regla de descifrado, se puede conectar al firewall.

Tarea 2: Asociación de una política al firewall

Al crear el firewall de red, tendrá la opción de elegir la política que se debe conectar al firewall.

Anexo NetworkFirewall

Hemos creado una regla de descifrado para descifrar el tráfico a través del proxy de reenvío SSL y otra para la inspección de entrada SSL. Como se ha mencionado para la conexión saliente de SSL, todo el tráfico de nuestra subred pública va a OCI Network Firewall y a través de OCI Network Firewall, está tomando una ruta de acceso desde Internet Gateway a Internet.

Para la inspección de entrada, pasa por el gateway de Internet que toma el próximo HOP como firewall y, a continuación, accede a nuestra máquina Linux en la subred pública.

De acuerdo con la regla de descifrado, para la dirección IP de origen utilizamos Hub-Linux-Machine y para cualquier dirección IP de destino, el tráfico debe ser descifrado por el proxy de reenvío SSL y para las conexiones entrantes para el origen como cualquiera y destino como Hub-Linux-Machine, debe descifrar el tráfico con la inspección de entrada SSL.

Reglas de descifrado

Nota: Para cualquier tráfico que golpee el firewall, primero comprueba las reglas de descifrado y, a continuación, las reglas de seguridad.

Pregunta: ¿cómo puedo identificar que la regla de descifrado está en vigor para el tráfico que golpea el firewall?

Respuesta: esto se puede ver en las métricas con un nombre de recuento de aciertos de regla de descifrado asociado al firewall.

Cada vez que la máquina Linux intenta acceder a sitios web de https en Internet o para cualquier conexión entrante a la máquina Linux en https, el recuento de aciertos de la regla de descifrado aumenta.

Métrica de firewall de red

Tarea 3: Uso de la regla de descifrado con una regla de seguridad para permitir o denegar el tráfico

Además del caso de uso anterior, veamos cómo se puede utilizar la regla de descifrado con una regla de seguridad para permitir o denegar el tráfico. Como se menciona en el inicio del caso de prueba, podríamos usar listas para permitir o negar el tráfico.

Aquí ya hemos creado una regla de descifrado para el proxy de reenvío SSL y la inspección SSL entrante. Para realizar pruebas, hemos creado una regla de seguridad para las conexiones salientes desde la máquina de Hub Linux a Internet para permitir el acceso a *.oracle.com.

Nota: Por defecto, se deniega el acceso a todo el tráfico en el firewall de red de OCI. Se debe crear una regla para el tráfico que se debe permitir.

Lista de URL:

Lista de URL

Regla de seguridad:

Regla de seguridad

Ahora lo que sucederá cuando la máquina de Linux intente acceder a *.oracle.com en Internet a través del firewall de red de OCI.

Pregunta: ¿cómo puedo ver qué regla se está produciendo para el tráfico?

Respuesta: se puede ver en los logs del firewall de red de OCI.

Para oracle.com

Logs de firewall de red 1

Para cualquier otra URL:

Logs de firewall de red 2

Agradecimientos

Autores: Luis Catalán Hernández (especialista en redes en la nube de OCI y multi nube), Sachin Sharma (especialista sénior en la nube de OCI)

Más recursos de aprendizaje

Explore otros laboratorios en docs.oracle.com/learn o acceda a más contenido de aprendizaje gratuito en el canal YouTube de Oracle Learning. Además, visite education.oracle.com/learning-explorer para convertirse en un explorador de Oracle Learning.

Para obtener documentación sobre los productos, visite Oracle Help Center.