Diseñar la protección DDoS para Oracle Cloud Infrastructure
Aunque hay muchas opciones de diseño de las que seleccionar, los factores comunes para la mayoría de los diseños son que deben ser:
- Se ajusta a los estándares de seguridad del negocio
- Garantizado de extremo a extremo
- Seguir un modelo de defensa en profundidad
- Gestión sencilla
- Escalable
El objetivo principal del servicio de protección DDoS de OCI es proporcionar una solución segura y escalable que cumpla los requisitos DDoS de una organización, al tiempo que admite varios niveles de entorno, incluidos la producción, la ubicación temporal, el desarrollo, el control de calidad y la recuperación ante desastres. Los servicios de protección DDoS de OCI también ayudan a una compañía a poner en marcha una arquitectura escalable y de alta disponibilidad con un modelo de seguridad de defensa en profundidad que aprovecha los componentes en la nube de OCI, como los firewalls de aplicaciones web (WAF), Equilibradores de carga de red (NLB), equilibradores de carga flexibles (FLB), firewalls de última generación (NGFW) de terceros con DDoS activado y certificados TLS/SSL, junto con las ventajas y consideraciones asociadas para cada diseño.
Evaluación y selección de una opción de diseño de arquitectura para la prevención de DDoS en OCI
Hay varias opciones de diseño de arquitectura que puede elegir, dependiendo de cómo le gustaría que escalara su prevención DDoS.
Opción de diseño 1: firewalls de aplicaciones web y equilibrador de carga de red única
En este diseño, los certificados TLS se utilizan en WAF, NGFW, los FLB privados y los servidores backend para flujos HTTP/S. El flujo HTTP/S siempre entrará desde el perímetro de OCI WAF y gradualmente avanzará a través de un NLB, seguido de NGFW y, por último, el FLB privado. Este enfoque requiere varias políticas de WAF para cada nivel de entorno (por ejemplo, producción, control de calidad y DR) y reenvío del tráfico HTTP/S a un único NLB, un único FLB y sus correspondientes juegos de back-end.
Nota:
Para todos los flujos no HTTP/S, el flujo siempre entrará a través del NLB, omitiendo el WAF de OCI, los NGFW y, por último, el NLB privado. Esto proporciona la capacidad de implementar el firewall DDoS en un nivel basado en zona o en un nivel global para centrarse en los ataques de capa 3 y capa 4.En el siguiente diagrama se ilustra esta arquitectura.
red única-lb-ngfw-architecture.zip
A medida que el tráfico entra en el perímetro de OCI, las políticas de perímetro de OCI WAF realizan la terminación TLS/SSL. A continuación, el paquete se descifra para que se pueda inspeccionar en busca de cualquier carga útil maliciosa de la capa 7 de WAF antes de enviar el tráfico hacia el origen en un puerto específico. Por defecto, es 443/TCP, que se puede configurar para reenviar en puertos específicos.
El origen de OCI WAF está configurado para reenviar tráfico a un único NLB, que luego reenvía el tráfico hacia instancias informáticas de NGFW de terceros para un puerto TCP determinado. Por ejemplo, en el diagrama anterior, los flujos de tráfico verde y azul desde el borde de OCI WAF se envían al origen (la dirección IP del listener de NLB) en puertos específicos, 4443/TCP y 4444/TCP, respectivamente. A su vez, el NLB está configurado para reenviar el tráfico a los juegos de backends (los NGFW) en los mismos puertos TCP.
El NLB funciona en las capas 3 y 4, y se coloca en una subred pública. El NLB generalmente se configurará para conservar la dirección IP de origen del cliente. La entrada de tráfico a través de OCI WAF se realizará mediante proxy mediante CIDR de OCI WAF documentados dedicados al servicio OCI WAF. Dado que el tráfico se envía por proxy desde una lista de CIDR de OCI WAF documentados, podemos agregar una capa adicional de seguridad aprovechando listas de seguridad o NSG para limitar la conectividad a una lista de CIDR de OCI WAF válidos y de confianza. Esto también implica que los logs de flujo de subred de NLB y los logs de tráfico de NGFW de terceros solo verán las direcciones IP de los rangos de CIDR de OCI WAF como IP de origen.
Dado que este diseño aprovecha los firewalls activos/activos mediante un NLB, el firewall de terceros debe realizar la NAT de origen antes de reenviar el tráfico al FLB privado para mantener una ruta simétrica para el tráfico de retorno. El NGFW también tendrá que realizar el destino-NAT, ya que el destino es un FLB privado.
Suponiendo que el NGFW admite el descifrado y la inspección, podemos descifrar el tráfico para realizar IDS/IPS en las cargas útiles no cifradas en el NGFW, antes de reenviar el tráfico a un FLB determinado.
Teniendo en cuenta los requisitos proporcionados y la opción de diseño descrita anteriormente, podemos concluir las siguientes mejores prácticas para este despliegue:
- Políticas de WAF independientes para cada nivel de entorno (producción, desarrollo y control de calidad).
- Utilice un único equilibrador de carga de red (NLB).
- Vuelva a utilizar los mismos NGFW de backend para varios niveles de entorno.
- Diseñar una arquitectura de defensa en profundidad.
- Proteja el entorno de extremo a extremo.
- Mitigue y controle los ataques desde entornos locales hasta Oracle Cloud.
- Obtenga protección DDoS de las capas 3 y 4 con control organizativo.
- Configure DDoS en la capa de firewall con el control de usuario para complementar las ofertas de Oracle.
Opción de diseño 2: firewalls de aplicaciones web y varios equilibradores de carga de red
En este diseño, la tecnología, los componentes y el flujo de datos siguen siendo los mismos que en nuestro diseño anterior. Después de que el tráfico entre en el perímetro de OCI, se procesa e inspecciona mediante las políticas de perímetro de OCI WAF para cualquier carga útil de capa 7 de WAF maliciosa antes de enviarla al NLB, al NGFW y, en última instancia, a un ALB privado. Del mismo modo, todos los flujos no HTTP/S siempre entrarán a través del NLB, omitiendo OCI WAF y los NGFW y, por último, el NLB privado. Esto proporciona la capacidad de implementar el firewall DDoS en un nivel basado en zona o en un nivel global para centrarse en los ataques de capa 3 y capa 4.
La diferencia clave en el diseño de la opción 2 es aprovechar varios NLB por nivel de entorno (producción, desarrollo y control de calidad) para separar el tráfico de entorno. En la opción 2, cada NLB utiliza una dirección IP secundaria única en el NGFW como conjunto de backends para reenviar tráfico. En última instancia, el tráfico se dirige al FLB designado para la aplicación o el servicio determinados. Este diseño también introduce la capacidad de escalar más allá de la limitación de 50 listeners utilizando un único NLB. Este diseño también permitirá la reutilización de puertos de listener NLB para estandarizar los flujos de tráfico para cada nivel de entorno (producción, desarrollo y control de calidad).
En el siguiente diagrama se ilustra esta arquitectura.
