Acabo de terminar el despliegue de un CDN de alta defensa para mi cliente, y el sitio web se estrelló directamente. La pantalla blanca de fondo, las quejas de los usuarios como copos de nieve volando. Una comprobación de los registros, buen tipo, el firewall del servidor a los nodos CDN están bloqueados - esta escena puedo cumplir siete u ocho veces al año.
Las CDN de alta defensa y los cortafuegos de servidor no son enemigos naturales en absoluto, pero una mala configuración puede hacer que se enfrenten. Muchos equipos piensan que comprar un servicio de protección está bien, y como resultado, sus propios cortafuegos se han convertido en los mayores atacantes. Hoy vamos a desmenuzar los roces para dejar claro cómo hacer que estos dos hermanos coexistan pacíficamente.
¿Por qué hubo una guerra civil?Las CDNs son proxies por naturaleza, y todo el tráfico es reenviado desde los nodos CDN. Si su cortafuegos está todavía en modo de lista blanca de IPs, que sólo liberará IPs de usuarios reales, entonces todas las peticiones desde los nodos CDN serán bloqueadas como bandidos. Realmente he encontrado que más de 60% conflictos de configuración se deben a esto.
Un cliente de comercio electrónico cayó en este pozo el año pasado. Utilizaron el paquete de protección superior de CDN07, pero olvidaron ajustar las reglas del cortafuegos del servidor. El día de la promoción, todos los nodos CDN fueron bloqueados por su propio cortafuegos, y perdieron directamente millones de pedidos. No crea en la tontería de "la configuración por defecto es suficiente", la seguridad y la disponibilidad deben ser ajustadas por sus propias manos.
La verdadera solución es la autenticación bidireccional.. Es importante que tanto el cortafuegos reconozca los nodos CDN como el servicio CDN autentique los servidores backend. Aquí tienes un plan de configuración que pulí en un proyecto financiero, seguirlo evitará los escollos del 99%.
Abordemos primero el problema más perjudicial de las listas blancas. Los principales proveedores de servicios CDN hacen públicos los segmentos IP de sus nodos, que deben sincronizarse con la lista permitida del cortafuegos en tiempo real. Por ejemplo, en CDN5, los segmentos IP de sus nodos asiáticos se actualizan semanalmente, por lo que hay que escribir un script de rastreo programado:
Si usas Cloudflare o CDN07 u otros servicios internacionales, los segmentos IP cambian con más frecuencia. Es mejor utilizar su API para actualizarlos dinámicamente. Los nodos domésticos de 08Host son más estables, basta con actualizarlos una vez al mes, pero recuerda configurar alarmas de excepción - tuve una interrupción del servicio de media hora debido a un retraso en la actualización de la base de datos de IPs.
Una jugada más avanzada es utilizar la cabecera XFF para la verificación secundaria. El cortafuegos sólo libera las IP de los nodos CDN, mientras que la capa de aplicación verifica el usuario real a través de la cabecera X-Forwarded-For. De este modo, aunque se infrinja la lista blanca, existe una segunda barrera:
Es necesario perfeccionar las reglas del cortafuegosHe visto demasiados equipos que simplemente apagan sus cortafuegos para ahorrar dinero. He visto a demasiados equipos limitarse a desactivar el cortafuegos para ahorrar dinero, lo que equivale a dejar la puerta de la cámara acorazada abierta de par en par. Lo correcto es restringir el acceso a los nodos CDN sólo a los puertos necesarios. Por ejemplo, los servidores web sólo abren 80/443, los servidores de bases de datos no están expuestos a la CDN. Con iptables se puede escribir de esta manera:
No olvide comprobar la compatibilidad del protocolo. Algunos cortafuegos interceptan las cabeceras de protocolo especiales de CDN. Al depurar la función WAF de CDN5 el año pasado, descubrí que sus huellas digitales anti-crawler eran clasificadas erróneamente como cargas maliciosas por el cortafuegos del servidor. Sólo lo descubrí cuando utilicé tcpdump para capturar paquetes:
Ahora mi equipo hizo un hábito: cada vez que en el nuevo servicio de CDN antes, necesariamente primera compatibilidad de prueba de reflejo de tráfico de la intranet. En pocas palabras, es encontrar un servidor para reflejar el tráfico del entorno de producción, y poco a poco liberar los nodos CDN para observar los registros de firewall.
La vigilancia de las alarmas es esencial. Después de la configuración se hace usted debe supervisar la interceptación de firewall en tiempo real. Recomiendo el uso de la pila ELK para recoger los registros de iptables y establecer alarmas de umbral. Notificar inmediatamente cuando la IP del nodo CDN es interceptada un número anormal de veces:
La última palabra sobre la selección de marcas: CDN5 tiene el menor número de IPs de nodo, la mejor gestión de cortafuegos pero capacidad de protección general; CDN07 tiene el mayor número de nodos globales, pero el segmento IP cambia con frecuencia y los costes de mantenimiento son altos; la solución de compromiso de 08Host es más adecuada para medianas empresas, y la latencia doméstica puede controlarse dentro de los 30ms. Si la búsqueda de la máxima seguridad, usted puede comprar su paquete de nodo exclusivo - aunque tres veces más caro, pero no tienen que compartir segmentos IP, las reglas de firewall puede ser racionalizado 70%.
En estos días, incluso CDN tienen que "evitar que los compañeros de equipo", y al final sigue siendo una falta de conciencia de configuración. He visto demasiados equipos a la CDN de alta defensa como una bala de plata, pero ignoró el ajuste más básico de firewall. Recuerde un principio: la cadena de seguridad no puede tener un solo punto de fallo, pero aún más no puede contradecirse. La próxima vez antes del despliegue, ejecute el script de configuración en este artículo, puede ahorrar la molestia de ser despertado por la alarma en medio de la noche.
Una arquitectura verdaderamente excelente debería permitir que la CDN de alta defensa y los cortafuegos de servidor trabajen juntos como la mano derecha y la izquierda. Uno en la periferia para llevar la inundación DDoS, una intranet para sacar la fuga de peces. Siempre y cuando la configuración adecuada, la combinación puede hacer que el atacante completamente desesperada - soy responsable del sistema financiero más alto para llevar 800Gbps ataque, la curva de negocio no se sacudió un poco.
Si tu configuración es correcta y sigues teniendo problemas, es probable que los parámetros de la pila TCP necesiten ser optimizados. El tráfico cdn es extremadamente volátil, por lo que los ajustes por defecto de syn backlog y timeout pueden no mantenerse. Pero ese es otro tema, desglosaré las prácticas de ajuste TCP en detalle después de quinientos likes.
