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?