cómo mitigar una DDoS de una botnet en su sitio web que proviene de direcciones IP aleatorias

7

Me pregunto cómo mitigar un ataque de ddos que proviene de una red de bots y está golpeando URL aleatorias en un sitio web.

Si hubiera una URL coherente con la que estaba llegando, sería bastante simple y no importaría que provenga de direcciones IP aleatorias.

¿Cómo evita un ataque que sea direcciones IP y URL aleatorias?

    
pregunta Zippy Zeppoli 05.02.2013 - 23:44
fuente

6 respuestas

9

La parte difícil es distinguir entre las solicitudes de la red de bots y las de los seres humanos que realmente desean leer las páginas. No hay una forma 100% confiable de hacerlo en general, porque algunas herramientas DDoS son bastante buenas para imitar a los humanos, y también porque la mayoría de los humanos parecen ser bastante buenos para comportarse como drones sin mente. Sin embargo, esa es la esencia del problema: debe encontrar una característica distintiva entre las solicitudes de botnet y las que no lo son (y si encuentra una, la botnet del próximo mes se habrá adaptado, esta es una carrera interminable).

Una posible defensa es requerir una Proof of Work de los clientes. Incorpore en su sitio algún código Javascript que realice un cálculo relativamente complejo, cuya salida se incrustará en la próxima solicitud de ese cliente. Si se hace correctamente, entonces podría asegurarse de que la botnet haya quemado al menos una cantidad sustancial de CPU en el proceso; la idea es que si DDoSing su servidor es demasiado caro, entonces el botnet master dirigirá su ira hacia otro objetivo. Después de todo, él es un hombre de negocios ...

No he visto PoW desplegado en un contexto web, y las idiosincrasias de Javascript pueden dificultar la acción (un navegador con un interpretador de Javascript no hará que "funcione" por segundo), pero el concepto parece correcto.

    
respondido por el Tom Leek 06.02.2013 - 00:51
fuente
7

Haga un poco de trabajo para averiguar si hay puntos en común: encabezados comunes que identifican de forma única los bots, etc. No se olvide de buscar cosas que los bots no tienen - un número deja campos como Host y Accept-Encoding porque se concentran en la solicitud HTTP mínima para maximizar su efectividad.

O bien vas a alcanzar un ancho de banda o un límite de cómputo: determina a qué te enfrentas porque es probable que puedas intercambiar uno con el otro.

A partir de ahí, tienes algunas opciones. Asumiré que los cambios de DNS no son lo suficientemente rápidos, está usando un alojamiento que dificulta el cambio de IP y que los balanceadores de carga, etc. están fuera del rango de precios (de lo contrario, es probable que conozca sus opciones de manejo) ):

  1. hable con su ISP; pueden tener opciones de mitigación que pueden habilitar para usted. Si puede darles una firma, es posible que simplemente puedan bloquearla. Es posible que puedan aumentar temporalmente el ancho de banda disponible para simplemente absorber los DDoS.
  2. Establecer una cookie en cada página legítima. Compruebe la cookie en la página 404. Si no ve esa cookie, la lista negra (si está en un límite de cómputo) o el agujero negro (si se está quedando sin ancho de banda) la IP.
  3. Haga una lista negra de países enteros que nunca ha visto en sus registros.
  4. Proof Of Work es una idea; podría ser muy simple: calcule la hora del día en JavaScript en tiempo UNIX y configure una cookie con ese valor. Verifique en cada página esa cookie, si está dentro de los 600 segundos, restaure la cookie a la hora actual. Si no lo eres, ejecuta while (1); en su backend al final de su página. Impacto mínimo en el usuario (la página es funcional, pero parece que se carga por alguna razón para siempre).
  5. Optimiza tus páginas. Si puede, cambie temporalmente a una configuración HTML totalmente estática (es una buena práctica tener un interruptor que haga esto de todos modos en un sitio grande, en caso de una popularidad repentina). Esto bien puede reducir el tiempo de cálculo lo suficiente como para que la DDoS no ofrezca al servidor. Esto cambia el tiempo de cálculo en favor del ancho de banda, por lo que aumentará su rendimiento.
  6. Haga lo contrario de 5: si tiene suficiente tiempo de cálculo disponible, disminuya la velocidad de su respuesta 404. Agregue un sueño de 60 a lo que esté usando para generar la página, mantenga el socket abierto todo el tiempo que pueda. Esto cambia el ancho de banda a favor del tiempo de cálculo, por lo que disminuirá el uso de ancho de banda y aumentará la carga.
respondido por el Bob Watson 06.02.2013 - 08:47
fuente
3

Los ataques DDoS tienen éxito principalmente agotando su ancho de banda, no evitando la detección por parte de su aplicación o infraestructura. Por lo tanto, la mejor forma de vencer los ataques DDoS es atraparlos en la fase inicial y muchos ISP ofrecen productos de mitigación DDoS diseñados específicamente para esto.

    
respondido por el Xander 06.02.2013 - 02:26
fuente
1

Si ejecuta su propio DNS, las "vistas" (o DNS de horizonte dividido ) pueden ser muy útiles como primera defensa, sin embargo, realmente necesita tener una lista blanca, que es donde está su histórico entran los registros del servidor web. También puede crear una lista negra, si puede reconocer a los clientes problemáticos . Los clientes sospechosos o no incluidos en la lista blanca obtienen 127.0.0.1 (o en algún lugar que no se puede enrutar) para hablar, todos los demás obtienen la (s) dirección (es) IP real (es).

El siguiente paso es asegurarse de haber leído esto:

Dependiendo de su plataforma, también puede optimizar su sistema (cookies SYN, filtrado de aceptación HTTP, mod_reqtimeout de Apache o opciones de terceros como mod_security ).

    
respondido por el mr.spuratic 06.02.2013 - 01:55
fuente
0

Sería mejor si pudieras usar un firewall de hardware. De lo contrario, necesitará una opción de software como esta enlace

    
respondido por el Travis Thompson 06.02.2013 - 00:43
fuente
0

Algunas personas han sugerido un esquema de prueba de trabajo de Javascript.

Realmente he visto un esquema de prueba de trabajo en la naturaleza. El supermercado británico Sainsbury's utiliza uno en www.sainsburys.co.uk .

El gran problema con esto es que los hackers son libres de usar las herramientas que deseen, por lo que pueden escribir una herramienta de craqueo que se ejecuta a una velocidad nativa. Mientras tanto, los usuarios legítimos pueden quedar bloqueados con una versión obsoleta de IE.

En el sitio de Sainsbury, los crackers nativos eran 100 veces más rápidos que IE6, por lo que no es una gran ventaja.

Hay más información sobre esta publicación de blog .

    
respondido por el James_pic 01.03.2013 - 18:49
fuente

Lea otras preguntas en las etiquetas