El 15 y 16 de abril de 2006 mi página se quedó inaccesible durante varias horas debido a un ataque de denegación de servicio: varios ordenadores (unos 60) estuvieron creando conexiones sin parar, todos a la vez, con lo que gastaban todo el ancho de banda. Aquí explico más detalles de la historia, y las pocas cosas que pude hacer mientras duraba.
21-4-2006 (actualizado el 21-09-2011). Daniel Clemente Laboreo. GFDL.
Tengo mi página web alojada en un servidor propio, o sea, un ordenador en mi casa que está encendido todo el día (detalles). Mi instalación es:
217.126.10.173, y velocidad 1024/300 kbits. Se supone que eso da un máximo teórico de 128 Kb/s para la bajada y 37'5 Kb/s para la subida
El ordenador lo aguanta todo, de momento. Está encendido desde febrero de 2004, sin reiniciar (eso son más de 2 años) y me extraña que el disco duro aún gire. El router, en cambio, se cuelga sólo por entrar en la página de configuración, y se le han ido estropeando puertos con el paso del tiempo.
Por la noche del 16-4-2006 estaba usando mi ordenador, que es uno distinto al servidor y está separado por más de 70 metros de cable.
A las 23:30, vi que el mi navegador no entraba en una página normal (como http://slashdot.org/),
y me imaginé que se habría cortado el acceso a Internet, cosa que pasa de vez en cuando.
En esos casos, normalmente la culpa es de mi router, y lo que hago es conectarme por telnet para reiniciarlo.
Pero me extrañó, porque desde mi ordenador (con Debian Linux) hacía telnet router,
y no conectaba.
En realidad, el ping router tampoco lo respondía, y eso sí que era más raro.
Se me ocurrió que quizás el cable desde mi habitación hasta el router se había estropeado,
ya que lo he forzado un poco para que pase por sitios difíciles.
En cambio, ping amarok (al servidor) sí que funcionaba, o sea, que la conexión estaba bien.
Fui a ver el router y vi que la luz que indica si hay conexión a Internet
se encendía y se apagaba cada medio segundo.
Nunca había visto esto, ya que se supone que con ADSL tiene que estar siempre encendida.
Le quité la corriente al router y lo encendí otra vez, pero acababa haciendo lo mismo.
Pensé en que el router se había estropeado del todo, y me asusté,
porque no tengo ninguno de repuesto.
Pero más tarde, el ping router empezó a funcionar, alternando tiempos de respuesta muy altos con otros más bajos.
Aquí abajo pongo una muestra;
también hay una más larga,
y un ping en condiciones normales.
64 bytes from 172.26.0.1: icmp_seq=10 ttl=255 time=187.8 ms 64 bytes from 172.26.0.1: icmp_seq=11 ttl=255 time=375.2 ms 64 bytes from 172.26.0.1: icmp_seq=12 ttl=255 time=191.3 ms 64 bytes from 172.26.0.1: icmp_seq=13 ttl=255 time=345.6 ms 64 bytes from 172.26.0.1: icmp_seq=14 ttl=255 time=141.6 ms 64 bytes from 172.26.0.1: icmp_seq=15 ttl=255 time=277.7 ms 64 bytes from 172.26.0.1: icmp_seq=16 ttl=255 time=62.9 ms 64 bytes from 172.26.0.1: icmp_seq=17 ttl=255 time=298.1 ms 64 bytes from 172.26.0.1: icmp_seq=18 ttl=255 time=65.7 ms 64 bytes from 172.26.0.1: icmp_seq=19 ttl=255 time=204.5 ms 64 bytes from 172.26.0.1: icmp_seq=20 ttl=255 time=3.3 ms 64 bytes from 172.26.0.1: icmp_seq=21 ttl=255 time=141.8 ms
Parece que quien lo estaba pasando mal era el router, que se desconectaba a ratitos.
Como mi router tiene un hub (no un switch), desde mi ordenador puedo espiar fácilmente
lo que envía y recibe el servidor, ya que también me llega a mí.
Se me ocurrió hacer un tcpdump -n, y empecé a verlo todo.
Un extracto (versión larga aquí):
00:01:24.784303 IP 125.212.121.13.52092 > 172.26.0.11.80: S 2186611081:2186611081(0) win 25200 <mss 1260,nop,nop,sackOK> 00:01:24.808319 IP 172.26.0.11.80 > 125.212.121.13.52092: R 0:0(0) ack 2186611082 win 0 00:01:24.832258 IP 67.163.53.153.4183 > 172.26.0.11.80: S 3755025832:3755025832(0) win 65535 <mss 1440,nop,wscale 2,nop,nop,timestamp 0 0,nop,nop,sackOK> 00:01:24.856578 IP 172.26.0.11.80 > 67.163.53.153.4183: R 0:0(0) ack 3755025833 win 0 00:01:24.856843 IP 81.64.87.114.4749 > 172.26.0.11.80: S 3091380300:3091380300(0) win 62464 <mss 1452,nop,wscale 1,nop,nop,sackOK> 00:01:24.857246 IP 172.26.0.11.80 > 81.64.87.114.4749: R 0:0(0) ack 3091380301 win 0 00:01:24.859813 IP 88.104.128.246.63007 > 172.26.0.11.80: S 192565129:192565129(0) win 65535 <mss 1460,nop,nop,sackOK> 00:01:24.860120 IP 172.26.0.11.80 > 88.104.128.246.63007: R 0:0(0) ack 192565130 win 0 00:01:24.861237 IP 201.152.51.140.3994 > 172.26.0.11.80: S 1259655457:1259655457(0) win 65535 <mss 1440,nop,nop,sackOK> 00:01:24.861612 IP 172.26.0.11.80 > 201.152.51.140.3994: R 0:0(0) ack 1259655458 win 0 00:01:24.870184 IP 70.70.207.54.3360 > 172.26.0.11.80: S 3811965293:3811965293(0) win 16384 <mss 1460,nop,nop,sackOK> 00:01:24.870506 IP 172.26.0.11.80 > 70.70.207.54.3360: R 0:0(0) ack 3811965294 win 0 00:01:24.875504 IP 81.64.87.114.4771 > 172.26.0.11.80: S 1273035026:1273035026(0) win 62464 <mss 1452,nop,wscale 1,nop,nop,sackOK> 00:01:24.875850 IP 172.26.0.11.80 > 81.64.87.114.4771: R 0:0(0) ack 1273035027 win 0 00:01:24.877125 IP 201.145.132.53.2344 > 172.26.0.11.80: S 314640656:314640656(0) win 16384 <mss 1452,nop,nop,sackOK> 00:01:24.877455 IP 172.26.0.11.80 > 201.145.132.53.2344: R 0:0(0) ack 314640657 win 0 00:01:24.883535 IP 85.144.140.99.1135 > 172.26.0.11.80: S 4033096825:4033096825(0) win 65535 <mss 1460,nop,nop,sackOK>
Y así todo el rato. IPs muy distintas (parece que elegidas al azar) se van conectando al servidor web: le mandan un paquete con el bit SYN activado. El servidor puede contestar con un SYN+ACK aceptando la conexión (siguiendo la negociación en 3 pasos), pero en este caso contesta RST+ACK, o sea, que no admite conexiones. Supongo que ya estaba muy saturado.
Entonces voy a ver al servidor web: me conecto por SSH y compruebo que en el registro del sistema (syslog) hay avisos de conexiones perdidas. En el registro del servidor web (thttpd) salía:
... 83.32.14X.XX - - [15/Apr/2006:23:11:24 +0200] "GET /www.danielclemente.com/html/gris.css HTTP/1.1" 200 2123 "http://www.danielclemente.com/html/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)" 83.32.14X.XX - - [15/Apr/2006:23:11:24 +0200] "GET /www.danielclemente.com/menu/menu.css HTTP/1.1" 200 1269 "http://www.danielclemente.com/html/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)" 83.32.14X.XX - - [15/Apr/2006:23:11:24 +0200] "GET /www.danielclemente.com/menu/menubody.js HTTP/1.1" 200 5017 "http://www.danielclemente.com/html/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)" 200.121.71.226 - - [15/Apr/2006:23:17:52 +0200] "UNKNOWN /amarok UNKNOWN" 408 0 "" "" 62.163.3.64 - - [15/Apr/2006:23:17:52 +0200] "UNKNOWN /amarok UNKNOWN" 408 0 "" "" 84.87.147.147 - - [15/Apr/2006:23:17:52 +0200] "UNKNOWN /amarok UNKNOWN" 408 0 "" "" 81.244.34.100 - - [15/Apr/2006:23:17:52 +0200] "UNKNOWN /amarok UNKNOWN" 408 0 "" "" 82.158.173.134 - - [15/Apr/2006:23:18:27 +0200] "UNKNOWN /amarok UNKNOWN" 408 0 "" "" 70.48.197.185 - - [15/Apr/2006:23:18:32 +0200] "UNKNOWN /amarok UNKNOWN" 408 0 "" "" 69.198.186.101 - - [15/Apr/2006:23:22:27 +0200] "UNKNOWN /amarok UNKNOWN" 400 0 "" "" 201.35.131.111 - - [15/Apr/2006:23:22:30 +0200] "UNKNOWN /amarok UNKNOWN" 400 0 "" "" ...
Eso dice varias cosas.
Primero, que el ataque empieza a las 23:17:52.
Puedo dar la hora exacta porque la tengo sincronizada con los relojes atómicos :-)
Al principio pensé que estaban pidiendo la página http://www.danielclemente.com/amarok/ de mi sitio web,
porque pone que piden /amarok.
Pero en realidad no piden nada, porque:
GET, no UNKNOWN. Lo he mirado en el código fuente de thttpd
Esto último lo probé desde mi ordenador: me conecté al servidor (nc amarok 80)
y, al cabo de 1 minuto de no decir nada, me da una página que dice
408 Request Timeout. No request appeared within a reasonable time period.
Y en el servidor queda registrado como:
172.26.0.3 - - [16/Apr/2006:12:37:08 +0200] "UNKNOWN /amarok UNKNOWN" 408 0 "" ""
Pues me parece que no podía hacer nada para evitarlo. Lo mejor era esperar a que pasara. Me explico:
El ordenador no tenía ningún problema en aguantar esa carga,
ya que la detecta y se protege.
Cuando entré por SSH, todo estaba tranquilo: no había ningún proceso gastando
toda la CPU, ni la memoria, ni el disco, ni nada parecido.
El problema lo tenía el router, ya que de Internet le estaban llegando muchas conexiones,
y parece que no podía soportar tantas (los pings de arriba muestran que se bloquea a ratos).
Y si alguien tiene mucho ancho de banda disponible y decide enviar
una avalancha de datos contra mi router,
no tengo ningún poder para pararlo, porque no controlo las cosas que pasan fuera de mi red.
Cuando una empresa grande sufre un ataque como éste, lo que debe hacer es contactar con su proveedor de Internet y conseguir que paren el ataque. Eso debe de costar mucho trabajo, y no creo que los usuarios normales puedan permitírselo.
Por tanto, creo que lo mejor es esperar "tranquilamente", y reconocer que nos quedaremos un tiempo indefinido sin Internet. Lo malo es si nunca para... Bueno, cada uno sabrá cuál es su límite de paciencia.
Lo que yo decidí fue:
La parte de investigar es la más interesante (y complicada...).
Me interesa saber varias cosas:
Todo esto lo estudié dos veces: una durante el ataque, y otra después. Y también me equivoqué muchas veces: por ejemplo, elegí varias IPs de las que estaban atacando (que parecían números elegidos al azar) e intenté conectar, hacer escaneos de puertos, pings, etc. No contestaba ninguna, así que deduje: están usando direcciones IP de origen falsas. No pensé en que en ese momento yo tenía saturado Internet, y por tanto ninguna conexión de las que hiciera saldría bien. Cuando probé a conectar después del ataque vi que sí que respondían, así que no descarto la posibilidad de que sean IPs reales.
Pero lo más interesante que hice durante el ataque fueron estadísticas.
Quería contar los ordenadores que había, y sólo tenía largos registros (cada vez más grandes) de todas las conexiones.
Estaba grabando todo el tráfico desde mi ordenador,
mediante tcpdump -w dump.
Al leerlo (con tcpdump -n -r dump), salía algo como:
00:13:14.454572 IP 84.29.11.51.2591 > 172.26.0.11.80: S 3810912234:3810912234(0) win 65535 <mss 1460,nop,nop,sackOK> 00:13:14.454880 IP 172.26.0.11.80 > 84.29.11.51.2591: R 0:0(0) ack 3810912235 win 0 00:13:14.456936 IP 84.105.59.220.3882 > 172.26.0.11.80: S 1968348093:1968348093(0) win 65535 <mss 1460,nop,nop,sackOK> 00:13:14.457244 IP 172.26.0.11.80 > 84.105.59.220.3882: R 0:0(0) ack 1968348094 win 0 00:13:14.458147 IP 80.177.167.197.22050 > 172.26.0.11.80: S 2010562016:2010562016(0) win 65535 <mss 1460,nop,nop,sackOK> 00:13:14.458487 IP 172.26.0.11.80 > 80.177.167.197.22050: R 0:0(0) ack 2010562017 win 0 00:13:14.463323 IP 60.48.58.9.2460 > 172.26.0.11.80: S 712467650:712467650(0) win 65535 <mss 1440,nop,wscale 0,nop,nop,sackOK> 00:13:14.463623 IP 172.26.0.11.80 > 60.48.58.9.2460: R 0:0(0) ack 712467651 win 0 00:13:14.465361 IP 86.82.31.1.61310 > 172.26.0.11.80: S 1652920468:1652920468(0) win 65535 <mss 1460,nop,nop,sackOK> 00:13:14.465695 IP 172.26.0.11.80 > 86.82.31.1.61310: R 0:0(0) ack 1652920469 win 0 ...
Suponía que las IPs eran falsas, así que no intenté contarlas. Lo que hice fue estudiar los demás parámetros de los paquetes TCP e IP, que son distintos entre ordenadores. Aviso que no entiendo mucho del tema, por lo que no explicaré cosas muy técnicas, pero si necesitas más información, busca por Wikipedia (ej: TCP). Actualización 15-7-2006: este artículo me motivó para escribir otro en Wikipedia, bastante largo: Implementaciones de TCP
Empecé mirando los puertos de origen que estaban usando. Hice este programita para extraer un listado de los puertos usados:
tcpdump -n -r dump | perl -lne '/\.(\d+) > 172.26.0/; print $1 >lista'
Y entonces pasé de la lista a un gráfico, mediante gnuplot (comando plot "lista"):
Esto muestra que no es todo tan aleatorio como parecía... Se ven claramente varias tendencias, lo que me hace pensar que son varios ordenadores, o incluso sistemas operativos diferentes. Alguien hace las conexiones incrementando el puerto de origen desde 50000 hasta el final (probablemente 49152-65535, que son los puertos dinámicos), mientras que otros intentos se hacen desde el 60000 para arriba, otros cerca del 18000, etc.
Pero quien más tráfico genera son los que usan un puerto de origen entre 1025 y 5000 (abajo), que es lo típico en muchas implementaciones de TCP. No sé si todo ese bloque rojo corresponde a un mismo ordenador o a varios, así que me hice un programa que pone a cada punto del gráfico un color distinto dependiendo de la IP anunciada al hacer la conexión. Queda algo más bonito:
Se sigue viendo un lío ahí abajo, pero se notan algunos patrones: líneas diagonales que van creciendo, igual que las de arriba.
Adapté el programa en Perl para hacer un gráfico de los números de secuencia iniciales que se encuentran en los paquetes TCP que enviaban los "visitantes". Queda un gráfico interesante:
A primera vista se ven 7 líneas, pero 3 de ellas salen por arriba y vuelven a verse por abajo, así que sólo quedan 4. Son 4 que se incrementan secuencialmente, pero el resto (el ruido de fondo) son varios ordenadores más que usan números de secuencia iniciales aleatorios.
Cada sistema operativo elige los núm. sec. inic. (ISN) de una forma distinta. Hay un interesante estudio sobre atractores extraños e ISNs que muestra cómo muchos sistemas no usan números realmente aleatorios, sino que repiten los mismos patrones.
Es curioso lo de que algunas líneas se vean dobles. Me imagino que eso es porque los paquetes no estaban llegando en el mismo orden en que se enviaban, sino que algunos se retrasaban (y por eso llegan con un número de secuencia más bajo que los actuales).
De todo esto se deduce poca cosa:
Hay más información sobre este tema en el artículo (muy bueno) sobre técnicas de identificación del sistema operativo a partir de la pila TCP/IP.
Los números del campo window (ventana) también muestran varios comportamientos distintos:
Se pueden contar 7. Varias IPs (el 26%) se concentran en la línea de abajo, en el número 16384, que es el valor que usan los Windows XP/2000 (según bases de datos de algunos programas de identificación remota). Pero el 58% anuncian una ventana de 65535 bytes, que es muy normal.
El campo id del protocolo IP normalmente da bastantes datos sobre cuántos paquetes ha enviado cada ordenador. Durante los ataques, los id recibidos hacen un dibujo muy original:
Es curioso que todos se comporten de la misma manera (incrementando igual los id). No hay ningún id 0.
Quizás sí que sean ordenadores distintos... porque cada color es una IP, y el contador id es específico para cada ordenador. Si un ordenador enviara IPs de origen falsas, las curvas tendrían trozos de colores distintos. Aunque naturalmente, también se puede falsificar el campo id.
Pues al principio creía que eran IPs falsas, elegidas al azar, porque vi muchos números distintos. Pero al acabar el ataque, hice un recopilatorio de IPs que habían participado, y son "pocas" (yo diría que unas 60).
Aquí pongo el listado de IPs; la primera columna indica la actividad (número de paquetes enviados durante la captura), y la tercera indica el nombre de equipo, que resolví al día siguiente.
Naturalmente, podrían ser falsas. He pensado en tres casos (dos extremos, y el otro mixto):
Creo que la hipótesis de un solo ordenador no es la correcta, porque en las pruebas que he hecho se veían varios comportamientos distintos. Además, los datos usados no son simplemente al azar, sino que siguen algunos patrones reales. Por ejemplo, si fueran IPs al azar, esperaría encontrarme IPs variadas; sin embargo, en la lista se puede ver que todas son del mismo tipo: usuarios normales (no empresas) que tienen cable o ADSL. Además, el servidor web (thttpd) estaba detectando las conexiones, y por tanto el cliente estaba mandando el paquete ACK en el tercer paso de la negociación en 3 pasos; para hacerlo se necesita usar la IP real (o hacer predicción de números de secuencia, cosa poco probable).
Por eso me parece que se trata de un grupo de ordenadores de usuarios normales, infectados con algún programa de control remoto para hacer ataques DDoS como éste. En el gráfico de los puertos de origen se ve que no todos participan con la misma intensidad; eso puede ser porque tienen distintas conexiones. Hay unos 7 importantes, y unos 50 más que se conectan a un ritmo más lento.
Pero sigo pensando en que quizás algunos de ésos son falsos, y en realidad hay menos ordenadores. Porque es que 60 me parecen muchos...
Había empezado a las 23:17 del sábado, y me quedé unas horas haciendo pruebas para ver si acababa. Por ejemplo, probé a iniciar el servidor web en un momento de mucho tráfico, y aparecieron estos mensajes en el syslog:
Apr 16 02:05:52 amarok thttpd[24328]: 83.18.11.242 connection timed out reading Apr 16 02:05:52 amarok thttpd[24328]: 85.144.131.112 connection timed out reading Apr 16 02:05:52 amarok thttpd[24328]: 88.2.124.18 connection timed out reading Apr 16 02:05:52 amarok thttpd[24328]: 84.242.164.237 connection timed out reading Apr 16 02:05:52 amarok thttpd[24328]: 84.242.164.237 connection timed out reading Apr 16 02:05:52 amarok kernel: ip_conntrack: table full, dropping packet. Apr 16 02:05:55 amarok kernel: Out of socket memory Apr 16 02:05:56 amarok last message repeated 8 times Apr 16 02:05:57 amarok thttpd[24328]: 70.70.207.54 connection timed out reading Apr 16 02:05:57 amarok thttpd[24328]: 83.18.11.242 connection timed out reading Apr 16 02:05:57 amarok thttpd[24328]: 201.152.51.140 connection timed out reading Apr 16 02:05:57 amarok thttpd[24328]: 60.48.165.55 connection timed out reading Apr 16 02:05:58 amarok kernel: NET: 4 messages suppressed. Apr 16 02:05:58 amarok kernel: Out of socket memory Apr 16 02:06:02 amarok thttpd[24328]: 60.48.165.55 connection timed out reading Apr 16 02:06:02 amarok thttpd[24328]: 60.48.165.55 connection timed out reading
Lo de "connection timed out reading" quiere decir que el cliente se ha conectado al servidor, pero no ha pedido ninguna página. Pero en principio ha hecho una conexión correcta (SYN, SYN/ACK, ACK) desde una IP real, ya que el kernel ha pasado la conexión al programa servidor.
El mensaje Out of socket memory y lo que hace después (4 messages suppressed)
es porque Linux se entera de que está recibiendo un ataque DoS,
y decide no seguir aceptando conexiones, ya que le gastarían todos los recursos.
Se puede ver en el código de Linux (2.4):
en /usr/src/linux/net/ipv4/tcp_timer.c,
función tcp_out_of_resources(...).
En este mensaje también lo explican.
Era normal que hiciera eso, porque había muchos sockets abiertos (cada vez más), y en algún momento tiene que parar.
amarok:root # netstat -n | wc -l
2178
El Linux también detectaba el ataque (conocido como SYN flood) y envía galletitas SYN (vaya nombre más absurdo). Esto lo decía el syslog:
Apr 16 07:08:01 amarok kernel: possible SYN flooding on port 80. Sending cookies.
A ojo (bueno, con ayuda de ethereal) vi que había unos 200 paquetes por segundo.
El ataque no paraba y yo tenía que irme a la cama, así que tuve que dejar que continuara. Me hubiera gustado estar levantado cuando acabara para hacer dos cosas:
Así que me preparé un programita para hacer esto:
#!/bin/sh while true; do cons=`netstat -n | wc -l` if test $cons -ge 100 ; then date echo "¡Matar a thttpd! (cons= $cons )" killall thttpd echo 'Me espero 10 minutos' sleep 600 # 600 echo 'Lo vuelvo a abrir' #/root/servsinlogs /root/servweb sleep 4 # un momentito para que se abra else date echo "Todo va bien, cons= $cons" echo "En 5 minutos lo vuelvo a mirar" sleep 180 # 180 fi done
Lo que hace es:
Dejé el programa funcionando en el servidor y cerré la conexión SSH
(por si no lo sabías, eso se hace mediante un programa magnífico llamado screen).
Ah, y lo ejecuté como ./espera.sh | tee sal_espera para tener una versión en fichero
(además de en pantalla),
por si algo salía mal y no podía volver a conectarme al servidor.
Eso lo puse a las 3h de la madrugada del domingo, y me fui a dormir.
Cuando lo miré, vi que hasta las 7h había habido mucha actividad,
y luego sólo quedaba una IP: 207.134.210.213 (más datos).
Podría ser falsa, pero bueno, al ser sólo una pude bloquearla bien con iptables
y entonces iniciar el servidor web.
Ya iba bastante bien Internet.
Esa IP siguió molestando hasta las 14h, o sea, que el ataque duró unas 15 horas.
Creo que éste es un ataque DDoS típico: alguien tenía muchos ordenadores infectados con un programa, y los dirigió a todos contra mi IP. Creo que no usó IPs falsas, pero que los ordenadores eran de usuarios normales (de ADSL y cable), probablemente con Windows.
No conozco los motivos, pero seguro que no fue para aprender. Alguien que estudie el SYN flood sabrá que, si quiere saturar un servidor, unos pocos paquetes bien elegidos son más efectivos que un montón de tráfico a lo bestia. Y si el autor de esto sólo quería aprender, no se habría estado 15 horas.
Por cierto, que mi ataque fue únicamente para consumir ancho de banda, pero el ataque SYN flood (el de los pocos paquetes) sí que puede evitarse. Para más información, mira este artículo de Security Focus: Hardening the TCP/IP stack to SYN attacks.
Algunas notas y consejos para estar prevenido:
tcpdump >fichero, sino tcpdump -w fichero, que graba más información de la que muestra en pantalla
tcpdump -n
Escrito el 21-4-2006; retocado por última vez el 21-09-2011.
Autor: Daniel Clemente Laboreo,
e-mail n142857/en/-g-m-a-i-l/punto/-com.
Licencia GFDL.