Y no hemos vuelto a saber del tema

Dos meses después no ha vuelto a pasar nada. En su día escribimos un mail (sin muchas esperanzas) a los correos con los que se habían registrado los dominios que apuntaban a nuestras IPs, y recibimos respuesta. Nosotros les pedíamos una explicación además de contarles lo que estaba pasando y exigirles que retiraran de sus DNSs la entrada que apunta a nuestras IPs.
La respuesta fue tal que "Sorry, it's fixed now".

¿Qué pienso de todo esto? Pues que hemos sido blanco de una prueba de ataque o que se equivocaron al asignar la IP del dominio que se usa para atacar.
La mecánica parece sencilla: apuntan un dominio registrado por ellos (los botmasters) a la IP que se quieren "cargar" y luego, cuando se ha propagado el cambio de DNS, le dicen a los bots que pidan una página de ese dominio. Normalmente aunque no esté configurado el dominio en el servidor web del incauto (en este caso nosotros) siempre se tienen configurados los webservers para que respondan por IP o que redirijan a la página correspondiente del dominio "madre".

La pregunta evidente es: ¿Y por qué no atacan directamente a la IP y se dejan de historias? Pues no lo se con seguridad, quiero conjeturar que de esta forma hacen menos sospechoso el ataque para los ISPs de los bots, además de pasar por proxies que filtren IPs, etcétera.

Sobre las medidas a tomar cuando se sufre uno de estos ataques deciros que desgraciadamente MUY pocas. Si lo que hacen (como en nuestro caso) es pedir páginas web lo primero es tirar el servidor para conseguir dos cosas: que el hosting no os eche por exceso de tráfico y para poder entrar en la máquina y ver si la cosa es más grave (que nos hayan hackeado y el bot seamos nosotros mandando SPAM a saco). Si tenéis contratado un firewall hardware haceros un script que a partir del access_log saque las IPs de todos los que piden la página en concreto e id cargandolas en el firewall. Limpiad los logs, arrancad durante un rato el servidor web y repetir el proceso. Nosotros encontramos hasta 50.000 IPs diferentes, tenedlo en cuenta para saber si el firewall lo aguanta.

Si el firewall es software olvidaros del tema. De hecho lo podéis hasta tirar hasta que pase el DoS. Nosotros ni con el APF ni directamente metiendo las IPs en iptables pudimos hacer más que fundirnos la máquina mientras cargaban las reglas, quedando además inusable una vez cargadas (demasiadas comprobaciones por petición TCP/UDP).

En resumen, si no eres la CNN, Microsoft o El Pais lo tienes jodido si te ataca un botnet de tamaño normalito.

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