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

Un mod de Apache del que todavía no había hablado es mod_cache. Mod_cache se utiliza sobretodo cuando se montan Apaches que sirven de proxy entre el servidor original y el cliente. Pero no tiene sólo esta utilidad.

Mod_deflate, es un mod de Apache que comprime los contenidos a costa de tiempo de la CPU. Pues bien, si habilitamos mod_deflate, Apache ha de estar comprimiendo continuamente los contenidos que se le requieren. Si usamos también mod_cache y alguno de sus submódulos (mod_disk_cache, mod_file_cache o mod_mem_cache) evitamos que ciertas cosas se recompriman porque Apache las sirve de la cache que ha generado.

Para habilitarlo, hemos de activar los módulos:

El archivo de configuración sería así:

CacheRoot es el path a la carpeta donde se guarda la cache
CacheEnable disk / habilita el cacheo para todos los archivos
CacheDirLevels y CacheDirLength ordenan a Apache a crear N niveles de N profunidad en el path

Y por último, reiniciar Apache.

Luego, hemos de pensar que Apache y su mod_disk_cache, ocuparán espacio en disco. Podemos eliminarlo periódicamente con htcacheclean.

Links

• http://www.vicente-navarro.com
• http://httpd.apache.org/docs/2.2/mod/mod_cache.html
• http://www.howtoforge.com

El error era

Y si, ese era el problema. El módulo env_module no estaba cargado desde la configuración.

Reiniciamos y a otra cosa.

Una forma básica de ofrecer seguridad sobre directorios web en Linux es utilizando las posibilidades que nos ofrece la apache.

.htaccess

Hemos de crear primero, un archivo llamado “.htaccess” y editarlo con las siguientes directivas:

AuthUserFile: path absoluto hasta el fichero .htpasswd
AuthName: contendrá el nombre del prompt o ventana que el usuario leerá al acceder al directorio protegido
AuthType: el tipo de autenticación
require user: los usuarios que podrán acceder al directorio protegido

Un ejemplo de .htaccess sería

Recordad que este archivo se ha de guardar en la carpeta donde queremos implementar la seguridad. Incluso podríamos llegar a bloquear el acceso a archivos, añadiendo debajo de esas líneas lo siguiente:

.htpasswd

Este otro fichero, contiene el nombre del usuario y a continuación su password pero, encriptado. Para genera el archivo necesitamos, o bien acceso a nuestro apache para crear el password desde consola o bien, existen muchas webs que nos crean el texto del archivo .htpasswd, al entrar el nombre y el password que queremos.

Si tenemos acceso a la consola lo generamos nosotros mismos:

para añadirlo al .htpasswd directamente, lo podemos redireccionar con el cat

Sino, podemos buscar sitios en internet y luego editamos el fichero.

Si apache no te pide la autorización al acceder a la ventana, asegúrate de que lo tienes bien configurado.

Links
http://www.apacheweek.com/features/userauth
http://www.cristalab.com/tutoriales/proteger-carpetas-con-.htaccess-y-.htpasswd-c213l/
http://www.elated.com/articles/password-protecting-your-pages-with-htaccess/
http://chernando.eu/doc/apache/
http://www.colordeu.es/BLOG/proteger-carpetas-web-con-htaccess-y-htpasswd
http://readthefuckingmanual.net/error/1385/

Reiniciamos apache, y si todo está ok, deberíamos ver la información del mod.

Links

• http://www.mydigitallife.info/
• http://drupal.org/node/52511

También lo podemos configurar con nuestro .htacccess. Reinciamos apache y listo. El motivo de hacerlo ya es entrar en discusión de ciertos factores.

Links

• http://www.askapache.com/htaccess/apache-speed-etags.html

http://www.howtoforge.com/forums/showthread.php?t=17144

En las instalaciones típicas de Apache 2.0.X el mod_expire, al igual que una legión de modulos, ya viene compilado y cargado en la configuración por defecto. Si tenemos dudas de si está o no, lo podemos comprobar con la extensión de Mozilla Firebug, YSlow. Utilizando esta extensión vemos la fecha de expiración de un archivo en concreto.

Primero, compilamos el modulo sino lo tenemos por defecto, utilizando apxs. Si no tenemos este binario, podemos instalarlo con

Necesitamos el fichero .c del mod_expires, lo podemos bajar o copiar del paquete de httpd. Una vez lo tengamos todo, ejecutamos:

Se deja el módulo en la ubicación por defecto

Comprobamos en el fichero de configuración de apache, que se ha cargado la línea de configuración adecuada:

Salvamos los cambios y reiniciamos apache

Podemos utilizar mod_expires en diferentes contextos, pero seguiremos el ejemplo encontrado en Yukei.net, por comodidad, más que nada. Nos referimos a utilizar htaccess, con lo cual, explícitamente necesitamos mod_rewrite.

Vamos al directorio donde tenemos el contenido que queremos controlar por expiración y creamos el htaccess

Añadimos

o bien

Añadimos esto en el fichero httpd.conf de nuestro apache

Reiniciamos apache again

Ahora, es cuando debemos comprobar con Yslow que nuestro contenido expira en el tiempo que nosotros hemosindicado. Para mod_expire hay dos directivas, ExpireDefault y ExpireByType. Son muy similares

ExpireDefault

ExpireByType

http://www.yukei.net

http://mapopa.blogspot.com

http://httpd.apache.org/docs/2.0/mod/mod_expires.html

Hay muchas maneras pero dejamos dos simples. Es necesario por motivos obvios, conocer la versión de apache instalada en nuestro sistema y el modo en el que ha sido compilado.

Output:

Compiled in modules:

core.c
prefork.c
http_core.c
mod_so.c

De esta manera sabemos que estamos ante un servidor Apache / 2.2.3 y en modo prefork:

Prefork MPM: el modo prefork utiliza múltiples procesos hijo, cada proceso hijo se ocupa de una conexión a la vez. Prefork es muy adecuado para sistemas con doble CPU, la velocidad es comparable al del Worker MPM y es altamente tolerante con los fallos en los módulos y los procesos hijos colgados. Por contra, el uso de memoria es alto y cuanto más tráfico tenemos más memoria consume

Worker MPM: utiliza múltiples procesos hijo. Es multi-thread dentro de cada proceso hijo y cada thread se encarga de una conexión. Worker es más rápido y escalable y el uso de memoria es comparativamente bajo. Es también adecuado para múltiples procesadores. Worker es menos tolerante ante fallos de módulos y un fallo en un thread puede afectar a todos los threads de un proceso hijo.

Este Módulo de MultiProcesamiento (MPM) implementa un servidor híbrido multiproceso-multihebra. Usando hebras para atender peticiones, el servidor puede servir un mayor número de peticiones con menos recursos de sistema que un servidor basado únicamente en procesos. No obtante, se mantiene casi por completo la estabilidad de un servidor basado en procesos manteniendo la capacidad multiproceso, pudiendo cada proceso tener muchas hebras.

Directivas de Apache

• MaxClients: es el número total de procesos hijo httpd que pueden ser procesados simultáneamente. El valor por defecto es bastante elevado para la mayoría de servidores (256). Cada proceso hijo es capaz de mapear (allocate) en memoria un número de información X. En Drupal, por ejemplo, cada proceso puede utilizar unos 10-15 Mb de memoria. 20 procesos, por 20MB de RAM cada uno, consume cerca de 500MB de memoria física. Cuando nos acercamos o llegamos al límite marcado, apache no devuelve un TimeOut inmediato, sino que coloca la petición en cola. Una aproximación racional al número adecuado para esta directiva podría ser la división de la cantidad total de RAM disponible (dejando una generosa cantidad para otros procesos) entre el máximo tamaño del proceso apache. Podemos saber el consumo de memoria de apache por proceso con el comando ps.

Lo fundamental para entender como gestionar la directiva MaxClients, es comprender que puede tener un valor “alto” sino nuestro servidor está sirviendo contenido estático, pero con aplicaciones modernas tipo PHP de contenido dinámico, podemos tener graves problemas de estabilidad si no calculamos bien el número total de MaxClients. Una fórmula para calcular el valor apropiado del MaxClients sería (hay muchas) la siguiente:

MaxClients = Total RAM dedicated to the web server / Max child process size

En un ejemplo práctico, tenemos una máquina virtual (OpenVZ) con 1Gb de RAM asignado. Después de averiguar el tamaño total del proceso apache, dividimos:

1 GB (1024 MB) / 2,3 MB = 445 MaxClients

Siempre pensando en un servidor que “sólo” ejecutara apache, obviamente, este valor es sólo un ejemplo. Nunca se debería asumir esa cantidad total de MaxClients. Lo mejor sería aumentar un poco el valor y comprobar el funcionamiento del servidor. Pero sería un buen punto de referencia.

• StartServers: número de procesos iniciales.
• MinSpareServers: número de procesos iniciales en iddle que esperan una petición.
• MaxSpareServers: número máximo de procesos en iddle esperando.
• MaxRequestsPerChild: cuando un proceso excede este valor, el proceso es destruido y, si es necesario, un nuevo proceso lo reemplaza. Esto puede reducir la memoria total usada en muchas situaciones, con los archivos dinámicos incrementando constantemente su uso de RAM y reiniciando los procesos para reducir su uso.
• ServerLimit: si nosotros queremos aumentar el número total de MaxClients de 256 a 300, debemos en principio aumentar el ServerLimit a la misma cantidad. Sino, el apache se quejará mostrándolo por la salida estándar.
• KeepAlive: por defecto está en off. Al estar on, permitimos a una misma conexión TCP hacer múltiples peticiones sin descartar la conexión (conexiones persistentes).
• MaxKeepAliveRequests: el número total de peticiones permitidas por una misma conexión TCP.
• KeepAliveTimeOut: el número máximo de segundos que permanecerá el proceso esperando a ser respondido.

Ejemplo configuración por defecto de Apache

Calcular memoria consumida por Apache

–sort rss (lista ordenando por RSS(Resident Set Size), kb del proceso en memoria)

Output:

2904 / 1024 = 2,8 MB ocupados por proceso de Apache. Ahora, debemos saber el número total de procesos:

Output:

# 15

De este modo, tenemos que por proceso utilizamos 2,8 MB de memoria (no swap). Y sabemos que hay 15 procesos de apache en memoria, con lo cual 2,8 MB x 15 = 42 MB usados. Otra forma, quizá más fácil de calcular como está rindiendo nuestro apache, es utilizar este script escrito en python (gracias al admin de Devside ) Os dejo un output de lo que muestra el script:

Private + Shared = RAM used Program

84.0 KiB + 312.0 KiB = 396.0 KiB klogd
128.0 KiB + 452.0 KiB = 580.0 KiB syslogd
128.0 KiB + 524.0 KiB = 652.0 KiB init
824.0 KiB + 600.0 KiB = 1.4 MiB bash
568.0 KiB + 1.1 MiB = 1.6 MiB sftp-server
1.6 MiB + 1.9 MiB = 3.5 MiB sshd (3)
37.4 MiB + 2.1 MiB = 39.5 MiB httpd (180)

Optimización

No hablaremos de optimización totalmente pero, si comentaremos que una de las cosas que se recomiendan por toda la comunidad es deshabilitar los módulos de apache que no necesitemos. En el ejemplo que me ocupa, una máquina virtual de 1GB de RAM de OpenVZ, deshabilitamos de 52 procesos 35, dejando sólo activos 17. Volvimos a hacer el calculo de la memoria utilizada por apache entonces:

2,3 MB por proceso x 12 procesos = 33,6 MB! (22 % menos en memoria). No está mal.

Otro consejo que se da en todos los manuales de tunning de Apache, es el deshabilitar la resolución de DNS, HostnameLookups. Esta directiva intenta resolver cada IP conectada a tu servidor y eso genera un consumo de recursos innecesario.

Conexiones Persistentes

En sus inicios, el protocolo HTTP no permitía las conexiones persistentes, lo que significaba que era necesaria una conexión al servidor por cada archivo que tuviese que ser descargado. Esto era una manera ineficiente de hacer las cosas, especialmente desde que Internet comenzó a tener sitios webs con gran cantidad de archivos. ¿Por qué?:

1. Cada conexión requiere la carga de al menos, 3 paquetes para ser iniciada (SYN,SYN-ACK,ACK). Esto significa que al menos 3 viajes de ida y vuelta para abrir una conexión.
2. Dada la naturaleza de TCP, bajo protocolo HTTP, una conexión funciona más rápido cuanto más tiempo está “abierta”. El cerrar y abrir continuamente conexiones, no permite a HTTP utilizar su ancho de banda total.

Directivas de KeepAlive

• KeepAlive: habilita o deshabilita las conexiones persistentes [ On - Off]
• KeepAliveTimeout: cuanto tardará Apache, en segundos, después de que una petición haya sido respondida para pasar a otra antes de cerrar la conexión.
• MaxKeepAliveRequests: el número total de peticiones que se permite a una conexión abierta.

Cuando un cliente se conecta al servidor web, se le permite realizar múltiples peticiones en la misma conexión TCP, lo cual reduce la latencia asociada a las múltiples conexiones. Esto es útil cuando, por ejemplo, una conexión a una página web requiere varias imágenes, y todas esas imágenes son recibidas por el cliente en una misma conexión. El lado malo es que cada proceso o worker en el servidor debe esperar a que se cierre la sesión por el cliente antes de poder resolver la siguiente conexión. Es difícil decir si es adecuado o no, activar las conexiones persistentes. En caso de que lo activemos, debemos dejar un valor muy bajo, 2, en la directiva KeepAliveTimeout. De esta manera, nos aseguramos de que cualquier cliente puede hacer las peticiones con bastante tiempo, y que el proceso no estará esperando eternamente a que el cliente cierre la conexión y se moverá a la siguiente conexión TCP. Resumiendo, sólo podemos probar su uso y ver si responde a nuestras necesidades.

Una curiosidad. Después de activar el KeepAlive, lo pude ver reflejado al instante en las gráficas del Cacti.

Un poco después de las 16.00 hice el cambio y se puede ver perfectamente. Es lo bueno de tener herramientas como esta. Era viernes y como no es bueno hacer cambios en fin de semana, lo desactivé.

Por último, comentar que la compresión de Apache logra muy buenos resultados. Revisar mod_deflate.

Fuentes:

http://drupal.org/node/215516

http://www.mysqlperformanceblog.com

http://www.mysqlperformanceblog.com/

http://www.devside.net/articles/apache-performance-tuning

http://publib.boulder.ibm.com

http://www.onlamp.com/pub/a/onlamp/2004/02/05/lamp_tuning.html

http://www.pacosanchez.com/2007/11/21/optimizando-apache

http://httpd.apache.org/docs/2.0/mod/worker.html

http://httpd.apache.org/docs/2.0/mod/prefork.html

http://www.ibm.com/developerworks/web/library/l-tune-lamp-2.html#listing1

http://www.apache-es.org/?p=20

http://www.pixelbeat.org/scripts/ps_mem.py – Reporta la memoria consumida por el sistema

Reiniciar apache y ya está. Esta es una de las causas, hay más que pueden afectar a nuestros servidor web.