Cómo defender tu servidor de los ataques CC, ¡te cuento lo que hice!

Recuerdo el verano pasado, yo estaba paralizado en el sofá cepillado drama, teléfono móvil de repente como loco zumbido vibrar sin parar - todo el correo de alarma del servidor, la tasa de uso de la CPU se disparó a 100%, el sitio se abre tan lento como un caracol arrastrándose. Maldije a una madre, el corazón entiende: este ochenta por ciento es otro ataque CC. Para ser honesto, después de tantos años de operación y mantenimiento, he visto un montón de este tipo de escenas, pero cada vez que puedo estar enojado con los dientes, porque los atacantes siempre les encanta elegir a altas horas de la noche, lo que obligó a permanecer despierto toda la noche para apagar el fuego.

CC ataque, para decirlo sin rodeos, es un grupo de “robots” disfrazados de usuarios normales, loco refrescar su página web o enviar una solicitud, el propósito no es hackear el sistema, pero para vivir a los recursos del servidor a secar, por lo que los usuarios reales no pueden acceder. He probado y encontrado que esta cosa es particularmente repugnante, porque no es como el DDoS tradicional como un flujo enorme, pero en lugar de simular la operación con una persona real como, muchos cortafuegos básicos directamente a un alto, pensando erróneamente que se trata de una visita normal.

Una vez, uno de mis puestos de comercio electrónico se jodió, la página de pedidos se atascó, el teléfono de quejas de los clientes casi se descuelga y el jefe corrió directamente a la sala de servidores para preguntarme si estaba minando.

Hoy en día, incluso las CDN tienen que ser ‘a prueba de mate", por no hablar de estos trucos turbios.

En ese momento tenía un servidor bare-bones en mis manos, y confiaba en Nginx para que me llevara con fuerza, y me sentí abrumado al instante. Me di cuenta de que no podía hacerlo solo, tenía que hacer una combinación de cosas. A continuación desmenuzo las migajas a decir, cómo paso a paso para construir el sistema de defensa, puede referirse a, pero no copiar, porque cada escenario de negocio es diferente.

En primer lugar, no te pongas a trastear, tienes que averiguar cómo es el ataque. Inmediatamente me conecté al sistema de monitorización, mirando los registros en tiempo real, y descubrí que una IP en pocos segundos envió miles de peticiones a la página de inicio de sesión, lo que obviamente no es normal. Hice una rápida búsqueda en la línea de comandos, y aquí está el comando:

tail -f /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -20

Esta línea de código enumera las 20 IP más solicitadas, identificando a los sospechosos de un vistazo. Pero es demasiado lento hacerlo manualmente, así que ya he configurado una regla de alerta en Zabbix que me envía automáticamente un mensaje de texto si una IP es solicitada más de 50 veces por segundo. No creas en esas tonterías de “la monitorización es opcional”, sin ella eres como un ciego luchando, sólo que pasivo.

Después de localizar el origen del ataque, mi primera reacción es bloquear temporalmente la IP. utilizar iptables para simplemente desconectar, por ejemplo:

iptables -A INPUT -s Dirección IP maliciosa -j DROP

Pero este truco trata los síntomas pero no la causa raíz, y el atacante puede seguir jugando con un segmento IP diferente. Así que opté por configurar la limitación de velocidad en Nginx, que es el camino a seguir. Añadí este párrafo a nginx.conf:

Esta configuración significa que cada solicitud de IP hasta 10 veces por segundo, más de una parte de la primera caché de 20, y luego sobre el retorno directo 429 error.

He probado, esto puede bloquear la mayoría de los ataques de bajo rango CC, pero cumplir con el punto avanzado, IP pool grande, o lucha. Una vez que he ajustado demasiado duro, por error bloqueado algunos rastreadores de motores de búsqueda, el tráfico SEO se redujo mucho, el jefe y me encuentro té, por lo que las reglas tienen que ajustar lentamente, no corte a través del tablero.

A continuación, decidí recurrir a un servicio CDN para filtrar primero el tráfico hacia los nodos periféricos. En ese momento, comparé varios, y finalmente elegí CDN07, ¿por qué?

Debido a que su protección inteligente es realmente no sopla, puede identificar automáticamente las solicitudes maliciosas basadas en el análisis de comportamiento, sino también con la aceleración global, el precio también es asequible. La configuración también es simple, corté el análisis de nombres de dominio a su CNAME, y luego abrir las reglas de protección de CC en la consola, el umbral se establece en 100 solicitudes por segundo, más que el desafío del código de verificación. Después de usar, la presión del servidor de inmediato cayó ochenta por ciento, la respuesta de servicio al cliente también es rápido, una vez en el medio del ataque de la noche, que 5 minutos para ayudarme a ajustar las reglas. Hoy en día, un buen CDN es como un guardaespaldas personal, ahorrando muchos dolores de cabeza.

El CDN por sí solo no era suficiente, añadí un cortafuegos de aplicaciones web (WAF) a nivel de servidor, utilizando el código abierto ModSecurity.

Tras la instalación, personalicé algunas reglas, como la protección contra la fuerza bruta para la página de inicio de sesión:

Esta regla comprueba si hay parámetros anómalos en las peticiones de inicio de sesión y las intercepta si la puntuación acumulada es alta. Te recuerdo, las reglas WAF no deben ser copiadas de Internet, tienes que moler poco a poco de acuerdo a tu propio negocio. Una vez que añadí una regla estricta, el resultado es que todas las peticiones API de mi propia APP fueron bloqueadas, y los usuarios volaron por los aires, así que tuve que hacer roll back de la noche a la mañana. Tuve que dar marcha atrás durante la noche. ¡Es una lección de sangre y lágrimas pasar por el entorno de pruebas antes de entrar en línea!

Además, he optimizado los recursos del servidor.

Por ejemplo, almacené en caché las consultas a la base de datos y utilicé Redis para almacenar los datos de la zona activa para reducir la presión de presionar directamente a MySQL. Añadí algunas respuestas retardadas al código para devolver datos falsos para peticiones sospechosas, drenando los recursos del atacante. Este truco es un poco dañino, pero efectivo, escribí un simple script PHP de ejemplo:

Esto ralentiza la máquina del atacante, mientras que los usuarios normales son acelerados por la CDN y apenas sienten el retraso. Sin embargo, esto tiene que usarse junto con la monitorización, o sería un desastre perjudicar accidentalmente a un amigo.

Hablando de eso, tengo que quejarme, algunos tutoriales siempre les gusta recomendar “herramienta de protección de un solo clic”, soplando el cielo alto, he intentado algunos, el efecto es desigual, y algunos incluso vienen con una puerta trasera.

No hay una bala de plata para defenderse de los ataques CC, la clave es la profundidad multicapa: la capa de red utiliza CDN para transportar el tráfico, la capa de aplicación utiliza WAF y filtrado de límite de velocidad, y la capa de datos hace un buen trabajo de almacenamiento en caché para reducir el negativo.

En mi arquitectura actual, también añadí simulacros regulares, como simular un ataque una vez al mes para comprobar si había vulnerabilidades. En un simulacro descubrí que cierta interfaz API no tenía límites establecidos y estuvo a punto de convertirse en una brecha, por lo que me apresuré a parchearla.

Por último, hablemos de mentalidad. Esto de la defensa es como el juego del gato y el ratón, los medios de ataque cambian cada día, no puedes establecer las reglas y tumbarte.

Me he acostumbrado a mirar los resúmenes de los registros todos los días, vigilar la información sobre nuevas amenazas y ajustar las reglas según sea necesario. Por ejemplo, el año pasado hubo una oleada de ataques a recursos estáticos, así que limité la velocidad del directorio de imágenes en Nginx, y el efecto fue inmediato. En resumen, mantente alerta y sigue aprendiendo, que es fundamental.

Después de todo eso, mi servidor es ahora sólido como una roca y nunca ha vuelto a ser colapsado por un ataque de CC.

Si acaba de entrar en el pozo, recuerde estos puntos: monitorización primero, respuesta rápida; capas de defensa, no confíe en un único punto; herramientas para elegir fiables, como los proveedores de servicios CDN07 pueden ahorrarle mucho esfuerzo; por último, la práctica hace al maestro, más pruebas y más ajustes.

El camino hacia la defensa es largo, pero si estás dispuesto a darle vueltas, siempre puedes encontrar un método que te funcione.