Recuerdo que el año pasado un cliente para encontrarme fuego de emergencia, dijo que el sitio fue golpeado de repente a tiempo de inactividad, una comprobación de los registros encontró que la IP de la estación de origen fue precisamente voladura - el atacante simplemente no fue CDN, directamente a la IP de la estación de origen de salida loco. Le pregunté cómo hacer coincidir la CDN, justificó: “no en el nombre de dominio CNAME al proveedor de CDN a la dirección?” Los resultados de un vistazo a la configuración, buen tipo, el servidor de origen en realidad atado al nombre de dominio de resolución directa del registro A, las reglas de firewall no restringen la CDN de nuevo al segmento IP de origen. Este tipo de operación, equivalente al hacker emitió una recta a través de la estación de origen del billete VIP.
De hecho, la estación de origen IP exposición esta mierda, nueve veces de cada diez son omisiones de configuración o sesgo de comprensión. Algunas personas piensan que el uso de CDN descansará fácil, pero no saben que CDN es sólo una capa de escudo, el escudo en sí no está cubierto herméticamente, pero se convertirá en una debilidad. ¡Actos comunes de la muerte incluyen: el servidor de origen abrió un puerto de depuración remota y el acceso público, los registros DNS permanecen en la fuente de un registro, certificado SSL IP fuente de fugas de aplicación, e incluso directamente en el código para escribir la fuente muerta API de llamada IP. aún más indignante es que algunos pequeños y medianos proveedores de la configuración por defecto de la CDN permite a los usuarios eludir la memoria caché a través de un encabezado específico o parámetros de URL para conectarse directamente a la estación de origen! --Esto es simplemente una puerta trasera para los atacantes.
He probado tres de los principales proveedores de CDN y he descubierto que incluso para el mismo proveedor, las políticas de seguridad por defecto para los diferentes paquetes pueden ser muy diferentes. Por ejemplo, la edición Starter de CDN5 no oculta automáticamente el encabezado del servidor de origen, mientras que su edición Enterprise se verá obligada a reescribir el encabezado de respuesta. También hay un detalle lamentable: algunos CDN en la fuente de nuevo a la falla de la información de error de IP de origen será lanzado al cliente, que se llama “la exposición de retroalimentación de fallo”, especialmente lanzada usuarios blancos.
¿Por qué tienes que morir para ocultar la IP de origen, en estos días los ataques DDoS han sido durante mucho tiempo industrializado, el costo de penetrar en el CDN es cada vez mayor, pero si se toca la IP de origen, el costo del ataque directamente hacia abajo dos órdenes de magnitud. He visto el caso más trágico es la exposición de IP de origen de una estación de comercio electrónico, se paralizó con 50Gbps UDP Flood, proveedores de nube directamente al servidor de origen para tirar del agujero negro durante 24 horas - para saber que ahora sólo un clúster de broiler puede crear fácilmente el tráfico de nivel T. Lo que es aún más repugnante es que una vez que la IP de origen está etiquetada, le sigue el posterior escaneo de puertos, detección de vulnerabilidades y abuso de APIs, que es tan difícil de limpiar como un nido de cucarachas apuñalado.
Hablando de reenvío multicapa, la esencia de esto es poner una muñeca rusa de anidación en la IP de origen. La primera capa se basa en el nodo de borde CDN para llevar el tráfico, la segunda capa utiliza un proxy inverso o fuente intermedia para hacer el aislamiento, y la tercera capa es la estación de origen real. La clave es dejar que el atacante sólo pueda ver la IP proxy más externa, y de vuelta a la IP de enlace de origen toda la comunicación de la intranet o de la lista blanca. Aquí recomiendo encarecidamente utilizar el programa de “fuente intermedia”: no deje que el CDN directamente de vuelta al servidor real, pero en medio de la inserción de una capa de proxy (como Nginx clúster proxy inverso), la capa de proxy y el CDN con una línea dedicada o interconexiones de intranet, el exterior completamente invisible.
Concretamente, tomemos como castaña la configuración de Nginx. Supongamos que su fuente real intranet IP es 192.168.1.100, la fuente intermedia servidor proxy IP pública es 203.0.113.10 (pero sólo permiten CDN de vuelta a la fuente IP segmento de acceso), CDN nodo de borde de vuelta a la fuente de punto a esta IP de origen intermedio. a continuación, en el servidor de origen intermedio, la configuración de la clave nginx.conf es largo como este:
¡No subestime estas líneas de configuración! Yo ayudo a una estación financiera a hacer refuerzo, sólo confío en esta arquitectura de fuente intermedia para bloquear el 70% del comportamiento de escaneo. Porque aunque el atacante elija la IP 203.0.113.10, sólo verá una capa proxy disfrazada de CDN, y no podrá tocar el servidor real 192.168.1.100. Es más, en la fuente intermedia también se pueden desplegar WAF, limitación de velocidad, verificación humana y otros módulos de seguridad adicionales, equivalentes a la estación de origen en el doble seguro.
Ahora hablemos de la elección de los proveedores de CDN. Escoja al azar tres comparaciones: CDN5, CDN07, 08Host. El punto fuerte de CDN5 es que hay muchos nodos en el extranjero, pero la política de seguridad por defecto es débil, hay que abrir manualmente el “modo estricto de vuelta a la fuente” para bloquear la lista blanca; la aceleración doméstica de CDN07 es implacable, soporta la integración nativa de reenvío multicapa (lo llaman “arquitectura de fuente escudo”), pero el precio puede ser más caro que 40%; 08Host ruta rentable. “Arquitectura de fuente de escudo”), pero el precio puede ser más caro que 40%; 08Host ruta rentable, comprar paquetes de alta defensa para enviar servicios de origen intermedio, pero la estabilidad del nodo de vez en cuando sacudida. Medí la prueba de presión, CDN07 en 300Gbps DDoS todavía puede mantener el enlace de fuente intermedia no se escapa la IP real, mientras que algunos vendedores baratos encontraron una gran cantidad de tráfico directamente de vuelta a la fuente de la exposición - por lo que no creen que el "absoluto oculto" sin sentido, la clave es mirar el diseño de la red subyacente. La clave es mirar el diseño de red subyacente del proveedor.
También existe una operación de anidamiento con múltiples CDN. Por ejemplo, utilizando CDN5 para hacer la primera capa de aceleración de borde, de vuelta al clúster de origen intermedio CDN07, y finalmente de vuelta al servidor real. Este modo de anidamiento, aunque el coste se duplica, ayudó una vez a una empresa de juegos a resistir un ataque híbrido de 1,2Tbps - el atacante ni siquiera penetró la IP Anycast de la primera capa de CDNs, por no hablar de la trazabilidad. Por supuesto, esta solución requiere una programación DNS detallada y configuraciones de retención de sesión, o los usuarios pueden experimentar fluctuaciones de latencia a través de los saltos CDN.
Por último, me gustaría echar un jarro de agua fría: no existe ninguna solución que pueda 100% garantizar que la IP de origen nunca será expuesta. Ha habido hackers que han deducido indirectamente la IP de origen a través del análisis del tiempo del handshake del certificado SSL, el fingerprinting de la pila HTTP/2, e incluso el mapeo inverso del segmento IP del nodo CDN, etc. Así que, además del reenvío multicapa, hay que trabajar con las operaciones básicas de cambiar de nuevo a la IP de origen regularmente, deshabilitar las respuestas ICMP y cerrar los puertos no esenciales, etc. Yo solía utilizar Shodan cada mes para escanear las IPs relacionadas con mi dominio y comprobar si había alguna exposición accidental de los servicios: es mejor que esperar a que se expongan. Acostumbro a usar Shodan para escanear las IPs asociadas a mis propios dominios una vez al mes para comprobar si hay algún servicio expuesto accidentalmente - es mucho mejor que esperar a ser golpeado y luego llorar.
En resumen, ocultar la IP de origen es un proyecto sistemático, no se acaba con un simple conjunto de CDN. Tienes que apilar las defensas de tres dimensiones: arquitectura de red, especificaciones de configuración y respuesta de monitoreo. Ahora mira mi año que fue golpeado por el cliente, más tarde pasó el doble del presupuesto para reconstruir la arquitectura, pero salvó diez veces la pérdida potencial de tiempo de inactividad - esta ola no está mal. Recuerde: la seguridad de este asunto, en lugar de sobre-diseñado no lo deje al azar, después de todo, los compañeros de chantaje puede ser mucho más de lo que rodamos.
