Una idea de la magnitud del ataque

Me he hecho un script para sacar las IPs diferentes desde las que se conectan y me salen 27710 en menos de media hora.
¿Alguien sabe si APF/Iptables puede con tanta IP sin zamparse la CPU?

El AntiDoS del apf no es de gran ayuda

El Botnet es enorme, la cantidad de IPs desde la que se conectan es tal que el APF no llega a considerar DoS a ninguna IP por ser la frecuencia de conexión desde cada una muy baja... Hacer más duras las reglas supondría hacer que empezara a banear tráfico "bueno".

La página que intentan abrir es...

... /login.php

Todos los "bots", según el access_log, intentan abrir /login.php en todas las IPs, cosa curiosa porque esa página no existe en ninguna.
Me he creado un /login.php vacio para que no de un 404 cada página que piden, y que no salte la página por defecto de "no encontrada", pero eso hace que vaya a peor la cosa: Ahora el web tiene algo que servir, aunque sea una página vacia. ¿Alguien conoce alguna regla del APF para filtrar por peticiones HTTP concretas?

Antecedentes del ataque

Desde esta tarde a eso de las 16:30 empezamos a notar el web algo lento. Monitorizando el uso (un "top" de los de toda la vida) vimos que la máquina iba desahogada, sin una carga de trabajo excesiva, además de no aparecer muchos procesos httpd en memoria, lo típico cuando apareces en Digg o Kotaku.com . "La ADSL de telefónica", pensamos, que se da a la droga.
Tras media hora de no mejora, y como el resto del universo web se cargaba ante nuestros ojos a toda velocidad, empezamos a investigar, empezando por el /var/log/messages :

[root@www log]# tail -f messages
Nov 17 12:16:11 www kernel: printk: 1500 messages suppressed.
Nov 17 12:16:11 www kernel: ip_conntrack: table full, dropping packet.
Nov 17 12:16:16 www kernel: printk: 1571 messages suppressed.
Nov 17 12:16:16 www kernel: ip_conntrack: table full, dropping packet.
Nov 17 12:16:21 www kernel: printk: 1576 messages suppressed.
Nov 17 12:16:21 www kernel: ip_conntrack: table full, dropping packet.
Nov 17 12:16:26 www kernel: printk: 1614 messages suppressed.
Nov 17 12:16:26 www kernel: ip_conntrack: table full, dropping packet.
Nov 17 12:16:31 www kernel: printk: 1604 messages suppressed.
Nov 17 12:16:31 www kernel: ip_conntrack: table full, dropping packet.
Nov 17 12:16:36 www kernel: printk: 1529 messages suppressed.
Nov 17 12:16:36 www kernel: ip_conntrack: table full, dropping packet.

Coño, que mala pinta, pensamos. El apache que no mata los procesos. Tras re-arrancar el apache y el MySQL, y ver que no se solucionaba pasamos a la segunda comprobación evidente:

[root@www log]# netstat -an | grep :80 | sort |more
tcp 0 0 72.232.183.27:80 117.193.164.229:3051 SYN_RECV
tcp 0 0 72.232.183.27:80 117.194.4.154:2149 SYN_RECV
tcp 0 0 72.232.183.27:80 117.195.198.80:1160 SYN_RECV
tcp 0 0 72.232.183.27:80 117.96.175.85:2796 SYN_RECV
tcp 0 0 72.232.183.27:80 118.172.156.167:1765 SYN_RECV
tcp 0 0 72.232.183.27:80 118.173.244.219:9396 SYN_RECV
tcp 0 0 72.232.183.27:80 118.173.37.30:61907 SYN_RECV
tcp 0 0 72.232.183.27:80 118.71.207.175:15472 SYN_RECV
tcp 0 0 72.232.183.27:80 119.42.85.119:35661 SYN_RECV
tcp 0 0 72.232.183.27:80 121.245.67.179:2609 SYN_RECV
tcp 0 0 72.232.183.27:80 122.154.3.252:23200 SYN_RECV
tcp 0 0 72.232.183.27:80 122.162.96.234:3947 SYN_RECV
tcp 0 0 72.232.183.27:80 122.167.1.7:3774 SYN_RECV
tcp 0 0 72.232.183.27:80 12.218.69.117:1963 SYN_RECV
tcp 0 0 72.232.183.27:80 122.53.134.2:1137 SYN_RECV
tcp 0 0 72.232.183.27:80 123.202.66.252:26283 SYN_RECV
tcp 0 0 72.232.183.27:80 123.236.51.251:2537 SYN_RECV
tcp 0 0 72.232.183.27:80 123.24.60.231:23349 SYN_RECV
tcp 0 0 72.232.183.27:80 124.104.237.67:3219 SYN_RECV
tcp 0 0 72.232.183.27:80 124.106.207.229:1712 SYN_RECV
tcp 0 0 72.232.183.27:80 124.120.65.213:2043 SYN_RECV
tcp 0 0 72.232.183.27:80 124.120.8.230:50949 SYN_RECV
tcp 0 0 72.232.183.27:80 124.121.136.27:1523 SYN_RECV
tcp 0 0 72.232.183.27:80 124.195.47.0:1848 SYN_RECV
tcp 0 0 72.232.183.27:80 124.98.69.53:54525 SYN_RECV
tcp 0 0 72.232.183.27:80 125.200.187.87:12089 SYN_RECV
tcp 0 0 72.232.183.27:80 125.31.26.218:1379 SYN_RECV
tcp 0 0 72.232.183.27:80 125.3.38.84:48193 SYN_RECV
tcp 0 0 72.232.183.27:80 125.3.38.84:48194 SYN_RECV
tcp 0 0 72.232.183.27:80 143.244.252.194:55281 SYN_RECV
tcp 0 0 72.232.183.27:80 151.21.49.194:10593 SYN_RECV
.
.
.

Y así hasta el límite de 34576 del net.ipv4.ip_conntrack_max .

Ya está, a alguien le caemos mal: esto es un DoS (o eso parece). Teniendo en cuenta que TodoJuegos.com apunta a la IP 72.232.183.29 y que nos están conectando a todo el rango de IPs de la máquina (.27, .28 y .29) nuestras sospechas parecen confirmarse.

Ahora procederemos a investigar posibles soluciones paliativas. Posiblemente empezemos por decirle al APF que empiece a banear IPs, aunque asusta un poco dejarle que lo haga de forma "automática". Además no todo viene de una misma subred o de un mismo país, eso lo pondria demasiado fácil, así que nada de banear a los 222.255.255.255

Mientras investigamos, ¿alguna idea?

Lidiando con un Ataque de Denegación de Servicio

Hola a Todos.

Soy el administrador de TodoJuegos.com , web dedicado al mundo de los videojuegos que en estos momentos está sufriendo un ataque de denegación de servicio.
El propósito de este blog es contar en tiempo "real" cómo evoluciona el tema, medidas, contra medidas y luego usarlo como referencia. Si a alguien le sirve o alguien puede ayudar, mejor que mejor, si lees esto dentro de unos años espero que sirva para algo y que TodoJuegos.com siga vivo :-)