De un tiempo a esta parte, hemos evidenciado la necesidad de mejorar ciertos aspectos en la infraestructura IT. Uno de ellos, corresponde a algo tan crítico como el servidor web. En este sentido, las pruebas que hemos hecho y estamos haciendo nos hacen apuntar a una dirección concreta. Además, el día a día nos presenta un duro reto con respecto a Apache 2.X como servidor web, dada su antigüedad, vulnerabilidad ante ataques, etc. El último ha sido bastante claro y tiene un nombre no muy tranquilizador: Slowris
Ejemplo Denegación de Servicio
[Mon Jan 24 20:03:51 2011] [error]
[client 186.121.58.113] request failed: error reading the headers
Por si sólo, esta línea no quiere decir mucho. Pero cuando ves una bajada en la gráfica de tráfico, ves está línea repetida cientos de veces y buscas en Internet, todo apunta claramente al culpable. Y no es otro que la vulnerabilidad de Apache ante ciertos ataques.
Este “cliente” HTTP, que majo él (¬¬), abre tantas conexiones como puede hacia el servidor web y las mantiene abiertas tanto tiempo como sea posible. El software añade headers a la petición HTTP sin llegar a cerrarla completamente. Esto provoca, en ciertos servidores, que las conexiones abiertas se multipliquen provocando un DOS en el servicio, aparte de bloquear el acceso a peticiones legítimas de otros clientes.
Podemos mitigar el efecto de diveras maneras. Una de ellas rebajando la directiva “TimeOut” de la configuración de Apache. Sin embargo, está comprobado en sitios de media-alta carga, el final es el mismo. He probado con configuraciones de 30 segundos para TimeOut y consiguen tumbar el servicio.
La aproximación por limitación de iptables, tiene el inconveniente de que, estamos limitando también el acceso de clientes legítimos al servicio. Y los más actuales IPS tampoco resuelven el problema, porque insistimos que, las peticiones realizadas a nivel de TCP son totalmente “legítimas”.
Ha sido de gran ayuda encontrar un buen artículo escrito en español sobre el tema, que aporta gran cantidad de soluciones. Es curioso ver que una de las opciones, Lighttpd como proxy como apache como backend tampoco resuelve el problema. El autor, observa que la deficencia se encuentra en Apache, no en Lighttpd.
Una buena solución, como dicen en systemadmin.es, es utilizar Nginx como proxy como Apache en backend.
Otra de las opciones que circulan, es instalar mod_qos, pero ya necesitamos instalar “otro” módulo más a Apache y probar configuraciones diversas etc. Con lo que la opción Nginx (se pronuncia “engine-ex”) parece la más clara, rápida y aséptica.
Lista de webservers afectados
- Apache 1.x
- Apache 2.x
- dhttpd
- GoAhead WebServer
- WebSense “block pages” (unconfirmed)
- Trapeze Wireless Web Portal (unconfirmed)
- Verizon’s MI424-WR FIOS Cable modem (unconfirmed)
- Verizon’s Motorola Set-Top Box (port 8082 and requires auth – unconfirmed)
- BeeWare WAF (unconfirmed)
- Deny All WAF (unconfirmed)
Listado de servidores no afectados
- IIS6.0
- IIS7.0
- lighttpd
- Squid
- nginx
- Cherokee (verified by user community)
- Netscaler
- Cisco CSS (verified by user community)
Links
http://systemadmin.es
http://www.howtoforge.com
http://www.randombugs.com
http://www.pc-freak.net
