¿La calma antes de la tempestad?

Parece que la cosa se ha calmado. La solución ¿temporal? ha sido realmente sencilla:
En esa máquina hay asignadas 6 IPs, y no se usan todas. La IP de TodoJuegos.com no estaba siendo atacada ayer, sólo las 2 asignadas a los "dominios fantasma" que registraron hace unos días.

Todas las IPs están asignadas a interfaces de red virtuales, todas colgando de eth0 (esa máquina sólo tiene dos interfaces de red "hardware"). En cuanto tiramos los eth0:1 y eth0:2 todo se calmó. En realidad a la subred seguían llegando paquetes a saco como confirmó nuestro hosting, pero luego nunca llegaban a la máquina al ignorarlas las interfaces de red. Desde ese momento la web volvió a funcionar a pleno rendimiento, el tráfico normal del web más las decenas de miles de peticiones rechazadas al segundo no eran suficientes para saturar (ni de lejos) la subred interna de Layeredtech (el hosting) o los interfaces base 100 de los switches de los que cuelga nuestra máquina (maravillas de la ciencia oiga...) .
Viendo los gráficos de uso de red se aprecia que tras 4 horas de intentos futiles la cosa paró por completo, no se si por ser lo programado, lo "contratado" o por estar reconfigurando el botnet para atacar a otra de nuestras IPs o otro pobre incauto.

Más tarde os pongo un resumen de medidas y por qué sin un firewall hardware NO se puede hacer nada por parar un ataque de un botnet, leáis lo que leáis por esos mundos de Dios lo que se hace es paliativo y en la mayoría de los casos el remedio es peor que la enfermedad, sobre todo si el objetivo es tirar la máquina.

Solución temporal efectiva...

... Aunque no puedo daros datos aun, no quiero dar pistas. Si deciros que no es una solución ortodoxa y que si se lo proponen nos vuelven a tirar, pero así damos tiempo a TODAS las partes implicadas en el asunto a investigar (DNS registrar Ruso, nuestro Hosting, etc...).
También tengo guardada una lista de más de 40000 IPs pertenecientes al botnet.
¿Sugerencias de a que investigadores les pueden resultar interesantes además de a los evidentes?

PD: Hay CANTIDAD de IPs Españolas, no son mayoría pero es sorprendente.

ALUCINA: A quien atacan es a otros dominios...

Que resuelven a nuestra máquina Y NO SON NUESTROS. Según el audit log del mod_security los ataques van dirigidos a geforcesliconfig.info y sliconfigurator.net. Según el whois los dueños son:

Domain name: sliconfigurator.net

Name servers:
ns1.nameself.com
ns2.nameself.com

Registrar: RegTime.net Limited
Creation date: 2008-11-12
Expiration date: 2009-11-12

Registrant:
Timur Makarov
Email:
Organization: Private person
Address: Novocheremushkinskaya ulica dom 72a, korp 3, kv 96
City: Moskva
State: Moksva
ZIP: 113212
Country: RU
Phone: +7.4993321201
Fax: +7.4993321201
Administrative Contact:
Timur Makarov
Email:
Organization: Private person
Address: Novocheremushkinskaya ulica dom 72a, korp 3, kv 96
City: Moskva
State: Moksva
ZIP: 113212
Country: RU
Phone: +7.4993321201
Fax: +7.4993321201
Technical Contact:
Timur Makarov
Email:
Organization: Private person
Address: Novocheremushkinskaya ulica dom 72a, korp 3, kv 96
City: Moskva
State: Moksva
ZIP: 113212
Country: RU
Phone: +7.4993321201
Fax: +7.4993321201
Billing Contact:
Timur Makarov
Email:
Organization: Private person
Address: Novocheremushkinskaya ulica dom 72a, korp 3, kv 96
City: Moskva
State: Moksva
ZIP: 113212
Country: RU
Phone: +7.4993321201
Fax: +7.4993321201

Domain ID:D26880781-LRMS
Domain Name:GEFORCESLICONFIG.INFO
Created On:12-Nov-2008 12:51:16 UTC
Expiration Date:12-Nov-2009 12:51:16 UTC
Sponsoring Registrar:Regtime Ltd. (R455-LRMS)
Status:TRANSFER PROHIBITED
Registrant ID:CO386122-RT
Registrant Name:Timur Makarov
Registrant Organization:Private person
Registrant Street1:Novocheremushkinskaya ulica dom 72a, korp 3, kv 96
Registrant Street2:
Registrant Street3:
Registrant City:Moskva
Registrant State/Province:Moksva
Registrant Postal Code:113212
Registrant Country:RU
Registrant Phone:+7.4993321201
Registrant Phone Ext.:
Registrant FAX:+7.4993321201
Registrant FAX Ext.:
Registrant Email:
Admin ID:CA386122-RT
Admin Name:Timur Makarov
Admin Organization:Private person
Admin Street1:Novocheremushkinskaya ulica dom 72a, korp 3, kv 96
Admin Street2:
Admin Street3:
Admin City:Moskva
Admin State/Province:Moksva
Admin Postal Code:113212
Admin Country:RU
Admin Phone:+7.4993321201
Admin Phone Ext.:
Admin FAX:+7.4993321201
Admin FAX Ext.:
Admin Email:
Billing ID:CB386122-RT
Billing Name:Timur Makarov
Billing Organization:Private person
Billing Street1:Novocheremushkinskaya ulica dom 72a, korp 3, kv 96
Billing Street2:
Billing Street3:
Billing City:Moskva
Billing State/Province:Moksva
Billing Postal Code:113212
Billing Country:RU
Billing Phone:+7.4993321201
Billing Phone Ext.:
Billing FAX:+7.4993321201
Billing FAX Ext.:
Billing Email:
Tech ID:CT386122-RT
Tech Name:Timur Makarov
Tech Organization:Private person
Tech Street1:Novocheremushkinskaya ulica dom 72a, korp 3, kv 96
Tech Street2:
Tech Street3:
Tech City:Moskva
Tech State/Province:Moksva
Tech Postal Code:113212
Tech Country:RU
Tech Phone:+7.4993321201
Tech Phone Ext.:
Tech FAX:+7.4993321201
Tech FAX Ext.:
Tech Email:
Name Server:NS1.NAMESELF.COM
Name Server:NS2.NAMESELF.COM
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:

¡Registró el dominio la semana pasada apuntando a nuestras IPs! ¡Y el colega deja su teléfono en Rusia y todo!

El Mod_Security no es suficiente...

Le digo que me dropee todas las peticiones que vayan a login.php , lo que hace correctamente, pero eso hace que puedan entrar mas peticiones de los bots, con lo que las conexiones máximas siempre están saturadas...
¡Mi reino por un firewall hardware!

Más detalles y menos soluciones

Todas las líneas de log "parece" que vienen del mismo navegador:
- - [17/Nov/2008:13:34:20 -0600] "POST /login.php HTTP/1.1" 404 292 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"

Pero eso no es significativo, el user_agent se puede definir como se quiera. Me temo que devolver algo que "cargue" la máquina no serviría de mucho ya que imagino que descartarán las respuestas del web, sólo les interesa "cargar" nuestro servidor.

5 minutos despues, 1000 IPs mas

Pasamos a las 28730 distintas. ¡Qué tio!

PD: ¿Qué le habremos hecho? ¿Será un fanboy de Sony mosqueado por darle un 8,5 al Metal Gear Solid 4? ¿De Microsoft por no haber publicado aun la review del Gears of War 2? :-)))

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 :-)