|
DoS involuntario
|
|
Por luchonidas
departamento nuestro-querido-proxy , Sección Diarios
Puesto a las Fri Oct 15th, 2004 at 03:09:12 PM CET
|
 |
El jueves de la semana pasada (7/10) fue bastante movido. Tenemos un cliente que nos hizo un ataque DoS involuntario.
La solución, después de la publicidad... perdón, en el cuerpo de la entrada.
|
Antecedentes:
Resulta que donde trabajo hacen un programa, y el día anterior al mencionado se subió a la web una actualización del dichoso programita. Por lo visto se le avisó a algunos clientes, y uno de ellos, ni corto ni perezoso se puso a descargar el programa.
Síntomas:
Viendo que me llamaban cada dos por tres desde el día anterior para decirme que el correo no funcionaba, que si el Outlook les pedía la contraseña, que si les daba timeout (no me lo decían así, pero bueno). Uno, que no es bofh, ni siquiera aprendiz, miraba el servidor a ver que le pasaba, restauraba la contraseña (siempre hay alguno que se le olvida la contraseña), etc, etc. Estaba convencido que era el servidor de correo el problema... más que nada porque miraba los logs del apache y se veía el movimiento normal.
Entonces pensé... vamos a ver que es lo que está pasando por el firewall... ssh... iptraf... bueno, que uno de los servidores, el de la web se estaba comiendo todo el ancho de banda. Primero pensé en un ataque DoS (con la típica duda en mente: ¿quién nos va a atacar a nosotros?), aunque como dije antes, era un solo cliente (cosa que no se sabía a priori)
Mirando más detalladamente (tcpdump -i eth1 -n -no-me-acuerdo-que-mas "port 80 and host 192.168.x.x") en el volcado ascii salía un montón de simbolejos extraños... entonces paré el apache en el servidor y lo volví a iniciar... y en los logs me volvía a salir un tocho de caracteres ascii sin sentido aparente entre los que se veía "GET /soft/****.zip". Voila. PEncontrado el culpable. Pasemos al problema.
Problema:
Resulta que la actualización del dichoso programa ocupa unos 100 Mbytes comprimida. Pero bueno, direis, eso no llega a comerse todo el ancho de banda, siendo que era un solo cliente el que estaba descargando, como descubrí más tarde. Activo el módulo mod_status de apache y miro... había unas 89 peticiones del dichoso fichero desde la misma IP. ¿Y eso?. (Nota: el directorio de descargas está protegido con contraseña.) Por lo visto el personaje se había puesto a descargar el programa con algún gestor de descargas, no se cual ya que simula ser un IE, este programita realiza tropocientas peticiones y me satura la línea... supongo que el hombre tendrá un ADSL, un modem o como mucho un RDSI (por el tipo de empresas a las que va dirigido el programa no pienso que tengan una conexión mucho más grande) y eso no puede saturar la línea de los sarvidores, por muchas peticiones que hagas desde la misma IP. me pongo a mirar la resolución de la IP... recurro a mi querido comando dig, y que me encuentro:
[root@localhost /root]# dig -x 80.58.19.107
;; ANSWER SECTION:
107.19.58.80.in-addr.arpa. 33410 IN PTR 80.58.19.107.proxycache.rima-tde.net.
;; AUTHORITY SECTION:
19.58.80.in-addr.arpa. 33410 IN NS rsdbet1-06.rima-tde.net.
19.58.80.in-addr.arpa. 33410 IN NS rsdmno1-06.rima-tde.net.
;; ADDITIONAL SECTION:
rsdbet1-06.rima-tde.net. 88115 IN A 80.58.32.103
rsdbet1-06.rima-tde.net. 88115 IN A 80.58.32.39
rsdmno1-06.rima-tde.net. 88115 IN A 80.58.0.39
rsdmno1-06.rima-tde.net. 88115 IN A 80.58.0.103
;; Query time: 5 msec
;; SERVER: 192.168.1.4#53(192.168.1.4)
;; WHEN: Fri Oct 15 11:33:26 2004
;; MSG SIZE rcvd: 207
¡Me está atacando un proxy de Telefónica!. ¿Cómor?
Supongo que el puñetero proxy cogería todas las peticiones del puñetero gestor de descargas y las lanzaría todas a la vez, si a eso le unimos el canuto que tendrán los proxys... pues llegamos al título de la entrada: tenemos un ataque DoS involuntario.
Solución:
- Primera solución: lo sentí mucho por el hombre que le hacía falta el programa, pero el correo tenía que seguir saliendo y entrando, y ya me empezaba a llamar algún que otro cliente que no podía acceder a su máquina... así que saqué mi lado mini-bofh y bloqueé la IP esa para el directorio soft: (configuración del httpd.conf)
<Directory "/home/httpd/html/datagruas/soft">
Order allow,deny
Deny from 80.58.19.107
</Directory>
Reinicié apache y problema resuelto... nadie que pase por ese proxy podría acceder al programa, y la línea dejó de estar saturada... pero esta solución no me convencía, así que pasemos a la segunda y por el momento definitiva solución.
- Segunda Solución: Hace tiempo que vengo pensando en que la red de los servidores necesita una configuración de QOS decente y no la chapuza que tengo ahora, así que me fui al firewall y me puse a trastear con el QOS (tc por aquí, tc por allí, mientras intentaba entender el capítulo nueve del howto del lartc). Tras un rato de pruebas llegué a la conclusión que esto no era lo que me resolvía este problema, así que recordando un artículo que había leído en la Linux Magazine nº32 (edición en castellano, en papel, aquí el enlace al artículo en inglés), me puese a trastear con mod_throttle, módulo para regular la carga y el ancho de banda en apache. Tuve que pasar del apache 2.0.47 (lo se, es antigüillo) al apache 1.3.31, compilar apache, compilar módulo, configurar apache con todos los dominios y demás cosas, y ponerme a hacer pruebas... Después de un par de días de pruebas me encuentro con la situación que el módulo hace lo que le da la gana. Las diferentes políticas permiten o deniegan el acceso al contenido según la configuración, pero después pasaba un buen tiempo hasta que desbloqueban el acceso, por ejemplo: si ponía un límite de cinco accesos simultaneos a un directorio, mientras no se cumplia la condición no había problemas, pero si se intentaba un sexto acceso lo bloqueaba (lo que yo quería), aunque no desbloqueba el acceso si los accesos anteriores terminaban (lo que yo no quería). Con todo este jaleo estuve dos días, hasta que...
Al final, me decanté por otro módulo que había encontrado mod_bandwidth y que fue más fácil de configurar, aparte de que permite mezclar diferentes tipos de directivas, pero pasemos al ajo.
Compilar:
Primero descargamos mod_bandwidth de la página indicada anteriormente, solo es un fichero, mod_bandwidth.c, y lo compilamos. Yo personamente me decanté por compilarlo como un módulo dinámico, así que siguiendo la documentación hice lo siguiente: /path_to_apache/bin/apxs -c /path/mod_bandwidth.c -o /path_to_apache/libexec/mod_bandwidth.so, y añadí las siguiente dos líneas a la configuración de apache:
LoadModule bandwidth_module libexec/mod_bandwidth.so
AddModule mod_bandwidth.c
Nota: El autor recomienda que estas líneas se añadan al inicio de las líneas que cargan los módulos de apache, para que tengan la menor prioridad y se ejecuten después de otros módulos.
Después de instalado el módulo se crean una estructura de directorios que usará el módulo para controlar la descarga. Estos directorios deben tener permisos rwx para el usuario del apache:
mkdir /tmp/apache-bandwidth
mkdir /tmp/apache-bandwidth/link
mkdir /tmp/apache-bandwidth/master
chown -R nobody /tmp/apache-bandwidth
chmod -R 750 /tmp/apache-bandwidth
Configurar:
En la configuración del apache añado:
<IfModule mod_bandwidth.c>
BandWidthDataDir "/tmp/apache-bandwidth"
BandWidthModule On
BandWidthPulse 1000000
</IfModule>
No me entretendré explicando las directivas de configuración porque vienen claramente explicadas en la documentación (por una vez encuentro una documentación clara).
También en la configuración del apache, pero en el directorio que quiero limitar añado:
<Directory "/home/httpd/****/*****/soft">
BandWidth 192.168 0
BandWidth all 30000
MinBandWidth all 4096
MaxConnection 6
</Directory>
Aquí si que explico un poco. BandWidth permite limitar el ancho de banda. Con Bandwidth 192.168 0 digo que todo el rango 192.168.0.0/16 no tenga límite de ancho de banda. Con Bandwidth all 30000 limito el resto de las redes a unos 30000 bytes por segundo compartidos, es decir, si se conecta uno y quiere descargar un archivo, irá a 30000 bytes/seg, si se conectan dos, irán a 15000 bytes/seg cada uno, y así.
Con MinBandWidth all 4096 especifico que el límite inferior para el ancho de banda son 4096 bytes por segundo, es decir que si siguen entrando personas para descargarse los ficheros, la velocidad mínima a la que irán será de 4096 bytes por segundo.
Por último, MaxConnection 6 limita el número de conexiones simultáneas.
Aunque aquí no lo he puesto, en la documentación pone que si uno pone límites de ancho de banda dentro de un VirtualHost, hay que añadir un "BandWidthModule On" a la configuración del VirtualHost para que se controle el ancho de banda para el dominio.
Ahora reiniciamos apache y ¡Tachán! tenemos control de ancho de banda.
Resultados:
En las pruebas que realizé, descargando el dichoso fichero desde otras máquinas, tanto con el navegador como con el comando wget y el ab, el módulo se comportó correctamente, tanto en el control de la velocidad como con las conexiones simultáneas, aunque tiene unas peculiaridades:
- El programa usa el directorio link para mantener información sobre las conexiones actuales y así calcular la velocidad. Lo hace creando un fichero por conexión. Si uno detiene el apache, estos ficheros no se eliminan, con lo que al iniciarlos de nuevo el módulo considerará que hay una conexión y lo restará del ancho de banda a usar. El autor recomuienda usar un script cleanlink.pl que elimina las conexiones falsas.
- El número de MaxConnection espécifica el número de conexiones desde la que se bloquea el acceso al fichero, no el número de conexiones permitidas. Me explico, en mi configuración MaxConnection 6 me permitirá 5 conexiones simultáneas y a partir de la sexta me bloqueará.
- El módulo no trae nada para mostrar estadísticas (bueno, no se puede pedir todo en esta vida).
En mi búsqueda de la solución me encontré con un par más de posibles soluciones: usar un proxy inverso, otro módulo que realiza lo mísmo bwshare y que podría estar mejor que los otros dos (mod_throttle y mod_bandwidth), ya que funciona en apache 1.3.x y 2.0.44 (y supongo que superior), y los otros dos no.
Se aceptan y se agradecen los diversos consejos, recomendaciones, etc, etc, etc.
Para la semana que viene, a seguir peleándome para instalar SpamAssassin en el servidor de correo.
Buen fin de semana |
|
|
