MONITORIZACIÓN Y LOGS mod_status El módulo de estado permite que un administrador del servidor pueda saber qué tal va su Servidor. Es una página HTML que se presenta y da las estadísticas del Servidor de una forma fácilmente legible. Instalación del Servicio a) Editamos httpd.conf y descomentamos la línea LoadModule status_module/mod_status.so. b) Añadimos las siguientes líneas: ExtendedStatus On (información extendida de cada solicitud) <Location /status> SetHandler server-status Definición SetHandler: Obliga a que el directorio al que hace referencia se maneje con el controlador server-status. Order Allow,Deny Allow 127.0.0.1 </Location> Tiempo de Refresco Se le puede pasar como parámetro el tiempo en segundos de refresco: http:// localhost/status?refresh=2 Datos que pueden Consultarse Firma del Servidor Bajo el título de la página está la firma del Servidor junto a Fecha de Compilación del paquete. Estado General del Servidor A continuación tenemos los datos generales del Servidor: - Fecha y Hora Actual - Cuando fue reiniciado el Servidor - Tiempo de Actividad del Servidor - Accesos Totales y Tráfico Total - Uso de la CPU .667 es menos del 1% - Hay una media de x consultas por Segundo .642 requests/sec (no llega a 1) - El tráfico generado es de x bytes por segundo 3595 B/second - De media las consultas generan x kbytes - Las peticiones que hay actualmente y número de slots (hilos) disponibles para atender futuras conexiones. MPM de Apache winnt Este módulo de multiprocesamiento (MPM) es el que viene por defecto para los sistemas operativos Windows NT. Crea un solo proceso de control que crea un solo proceso hijo que a su vez crea hilos para atender las peticiones que se produzcan. Esto es debido a que los sistemas Windows funcionan mejor con hilos que con un conjunto de procesos hijos constituyendo un Servicio. Definición Hilo: los hilos son procesos, que al contrario que estos, comparten recursos, datos y espacios de direcciones. El tiempo que requiere al sistema operativo para realizar el cambio de un proceso a otro es muy elevado, debido a que debe realizar un cambio de contexto, cambiar el proceso de un estado de ejecución a estado de espera, copiar toda la memoria del programa y colocar de nuevo el proceso en ejecución. En los hilos este tiempo es despreciable, pues todos pertenecen al mismo proceso (Apache) y además comparten memoria. La complejidad de los hilos viene en cuanto a su programación algo de lo que en este caso estamos totalmente exentos. # WinNT MPM # ThreadsPerChild: constant number of worker threads in the server process # MaxRequestsPerChild: maximum number of requests a server process serves <IfModule mpm_winnt.c> ThreadsPerChild 250 MaxRequestsPerChild 0 </IfModule> Notas: ThreadsPerChild: Aumentando la variable ThreadsPerChild se aumentan el número de Procesos (Hilos) que actúan en nuestro Servidor a la Espera de Peticiones. Determina el número máximo de conexiones que puede manejar el servidor en un momento dado. Cuando nos acercamos o llegamos al límite marcado, Apache no devuelve un TimeOut inmediato, sino que coloca la petición en cola. Las peticiones se irán encolando hasta llegar al valor ListenBackLog (por defecto 511) y a partir de este momento devolverán el dramático “Connection Refused”. El valor por defecto de 50 según Apache debería de ser perfecto para la mayor parte de las solicitudes. La media de Apache debería ser capaz de asignar un número máximo de 4096 hilos para el módulo winnt MPM, aunque a efectos de Server Status el máximo te lo ubica 1919. Probablemente y según la documentación de Apache con un número por debajo de 256 debería ser más que suficiente. Esta valoración se debe de estipular mediante prueba ensayo siempre teniendo en cuenta los recursos de los que se disponen y los recursos que se mueven en el Servidor en cuanto a lo que se gasta al realizar las diferentes peticiones de los Servicios que ofrecemos. Esta directiva no está especificada por defecto en el Archivo de configuración. ListenBackLog 511 MaxRequestPerChils: Número máximo de Peticiones permitidas por conexión, a 0 infinito, esto no es lo aconsejable previniendo posibles ataques para hacer caer tu Servidor. Lo que recomienda Apache es 1000, por otra parte, 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. Teniendo en cuenta que el MPM por defecto de Apache bajo Windows es mpm_winnt y que este cuando arrancamos Apache crea un Proceso de Control que crea un solo proceso hijo y este a su vez crea hilos para atender las peticiones recibidas. Para la visualización de los 2 Procesos Iniciales podemos ejecutar el comando Tasklist que nos muestra el consumo de memoria de estos Procesos. En este sistema de Servicio de Apache (winnt) la estimación de este valor es un poco subjetiva Práctica: Buscar información de cómo realizar un código en PHP para medir el consumo de memoria de una petición a una página PHP que realice un script. DIRECTIVAS DE APACHE Timeout - Es el valor que una conexión inactiva va a estar mantenida por el Servidor. Por defecto es 300 (segundos). Para mi es demasiado. Hay que tener en cuenta, que además, reducir estos segundos, nos va a beneficiar en casi todos los sentidos. Por lo tanto, mi recomendación es que sea entre 40-50. Suelo usar 30. Conclusión: Tiempo que una petición de un cliente no se puede procesar, esto puede ser debido a que está en cola al no poder atenderse su petición ya que no hay slots libres, o bien, que una consulta a la Base de Datos está tardando un tiempo excesivo en ser atendida, o un script en PHP que ha entrado en Bucle. Si reducimos el tiempo de TimeOut podemos liberar el slot para que atienda otras peticiones que a lo mejor van dirigidas a otros Servicios que tienen menos nivel de tráfico. KeepAlive - Son conexiones que se quedan abiertas para un cliente en la comunicación con el servidor (Usuario entra en la web, web sirve página, y la conexión queda abierta para cuando vuelva usuario, sería un ejemplo chapucero). De esta forma, la reaprovecha. Es ideal para páginas donde existen unos usuarios fijos. Además, se puede configurar para determinar opciones (ahora las explicamos). Se configura con el On/Off. Personalmente, a mí siempre me ha ido mejor Off. Conclusión: Si el tráfico de tu Servidor es dinámico (no disponemos de un Grupo de Usuario medianamente Regular), el mantener conexiones abiertas a la espera que este realice un volumen de peticiones constante es una pérdida de Tiempo. KeepAliveTimeout - Es la regulación del tiempo que mantiene abierto el servidor la conexión, a la espera de más peticiones. Por ejemplo, si le colocamos 15, el servidor esperara 15 segundos antes de cerrar la petición, a la espera de que el usuario realice otra. Yo recomendaría que se bajaran esos 15 segundos. Lo dejaría en 2 o 3 máximo. Conclusión: Ya que mantienes el KeepAlive activo minimiza el tiempo de espera de petición, no lo veo tampoco mala idea mantener abierta la conexión ya que posiblemente haya repetición en una misma sesión de conexión, pero eso si reducir el tiempo ante tráfico dinámico. MaxKeepAliveRequest - Numero máximo de peticiones permitidas por conexión. Sinceramente, yo esto lo pondria sobre el 1000. No creo que nunca exceda ese numero, y teniendo en cuenta que si en 2 o 3 segundos como hemos configurado arriba, no existe conexión, se cerraría. Pero depende de cómo lo tome el servidor. LOS SLOTS (HILOS) Tabla de caracteres representando (estado) cada uno de los slots que pone en marcha Apache: ya sabemos que este número de Hilos es controlable por la Directiva ThreadsPerChild. Se podría definir slots como la representación de la zona de memoria que puede a llegar a ser ocupada por un Hilo. El significado de los estados del ScoreBoard es el siguiente: “ _ ” Esperando conexión “ s “ Comienza la Conexión “ R “ El slot lee la consulta del cliente “ w “ El slot envía el contenido / resultado de la petición “ k “ Manteniendo la Conexión en espera de más Peticiones “ D “ Búsqueda de DNS. El slot hace una consulta de DNS para encontrar el host del cliente. Puede ser pesado en caso de servidor DNS lento. Se puede desactivar con la opción: HostnameLookups off en la configuración de Apache. “ c “ Cerrando la Conexión “ L “ Acceso a Logs “ G “ Estado raramente visible, se muestra únicamente cuando el Slot muere debido a un error. “ I “ idle limpieza de trabajador “ . “ Ranura abierta sin Proceso actual (no ocupa memoria) NOTAS en Base al Contenido del ScoreBoard: Exceso de W: Cuando un slot se encuentra en estado de W significa que este hilo está emitiendo una contestación. Sí que vemos que en todo el ScoreBoard se acumulan las W el Servidor está contestando muy lento por el motivo que sea o incluso se ha quedado colgao. Generalmente es claro indicativo de algún bloque en la Base de Datos. Para saber el tiempo que un proceso se encuentra en estado W deberemos fijarnos en la columna SS. Por lo tanto, las peticiones en estado W que tengan el SS más alto serán las primeras en ser investigadas. Evidentemente si desde nuestra Web emitimos contenido del tipo multimedia (.mp3, .avi) es lógico que el proceso que atiende esa petición tenga un SS alto. Exceso de estados K: Esto nos indica que tenemos demasiados procesos manteniendo conexiones abiertas a la espera de nuevas peticiones por parte de un Grupo de usuarios. En estos casos tendremos que ver si nos interesa reducir el Tiempo de KeepAlive de las conexiones. Esto como ya se indicó anteriormente depende de la regularidad y confianza del Grupo de usuarios que intervienen en nuestro Servidor. - Exceso de L: si la operación de escritura se alarga, o hay muchos Slots en este estado, puede que haya un problema con un tamaño excesivo de logs por encima del GB por ejemplo. Incluso en un servidor con una actividad moderada, la cantidad de información almacenada en los ficheros de registro es muy grande. El registro de acceso crece normalmente en 1MB por cada 10.000 peticiones. Por lo tanto, es necesario rotar periódicamente los registros moviendo o borrando su contenido. Exceso de D: el Servidor pierde excesivo tiempo en intentar resolver cada IP conectada a nuestro Servidor y eso genera un consumo de recursos innecesario. La directiva que controla esta característica es HostnameLookups cuyos estados son on/off. HostnameLookups Off A nivel General el exceso de tiempo de un proceso o varios en un estado determinado puede ser claro indicativo que algo no anda bien en nuestro servidor o que estamos sufriendo algún ataque al mismo. Generalmente a no ser que el proceso esté realizando alguna operación muy costosa se mantendrán en estado “Esperando Conexión” o “Ranura Abierta sin Proceso Actual”. Acc M SS Req Conn Child Slot Client VHost Request 0/0/0 R 5 0 0.0 0.00 0.00 ? ? ..reading.. 0/0/0 R 5 0 0.0 0.00 0.00 ? ? ..reading.. 0/1/1 R 5 2 0.0 0.00 0.00 ? ? ..reading.. 0/1/1 _ 6 2 0.0 0.00 0.00 127.0.0.1 administrador \x16\x03\x01 8/11/11 W 0 0 21.6 0.03 0.03 127.0.0.1 Eureka GET /status HTTP/1.1 Srv Número de Hilo PID Identificador de Proceso Acc Número de Accesos a esta conexión / hilo / ranura M Modo de Operación SS Tiempo desde que empezo la petición más reciente Req Milisegundos reuqreidos para procesar la petición más reciente Conn Kilobytes transferidos en esta conexión Child Megabytes transferidos por este proceso Slot Total megabytes transferidos por este hilo En esta zona muchas veces suelen aparecer solicitudes realizadas a la misma IP de retorno (127.0.0.1), esto es debido a que Apache cada cierto tiempo despierta procesos en escucha de nuevas conexiones. Para ello se utilizan solicitudes ficticias, llamadas solicitudes maniquí, que no son ni más ni menos que solicitudes que Apache se envía a si mismo. Detección de un Ataque de Denegación de Servicio: Un ataque de denegación de Servicio, consiste en saturar los recursos de algún tipo de servicio. En el caso del Servidor Apache se podría decir que un ataque se podría llevar a cabo mediante peticiones ilegítimas a través de aplicaciones diseñadas para tal fin o aprovechando algún fallo de seguridad, de modo que l falten recursos para procesar las legítimas Por muchos recursos de los que disponga un Servidor Apache, un ataque de denegación de Servicio puede saturar el Servidor. Hay que tener en cuenta que un ataque DoS puede ser distribuido, DDoS o Distributed Denial of Service, y contar con un gran número de máquinas que siempre superarán en recursos al servidor o servidores Web. Estos ataques pueden ser realizados sin conocimiento del usuario, poruqe su equipo ha sido infectado. Por Fuerza Bruta: Se basa simplemente en generar un gran número de peticiones HTTP de manera que el servidor no pueda responder a todas. Es posible realizarlo mediante una aplicación especialmente diseñada para tal fin. Ataques SYN Flood Cada conexión: Requiere la carga de al menos 3 paquetes para ser iniciada (SYN, SYN-ACK, ACK). El lado del cliente de una conexión realiza una apertura activa en un puerto enviando un paquete SYN inicial al servidor como parte de una negociación en 3 pasos. En caso que el puerto al que va dirigido la petición se encuentra abierto el lado del servidor respondería a la petición SYN válida con un paquete SYN/ACK. Finalmente el cliente debería responderle al servidor con un ACK completando así la fase de establecimiento de la conexión. Tratan de colapsar el servidor a nivel de TCP/IP y no de aplicación. Esto se consigue colapsando una estructura de datos en la que se almacena información sobre las conexiones TCP llamada Transmission Control Block o TCB. Para ello, en el hanshake de establecimiento de sesión TCP, el atacante envía el SYN inicial, el servidor responde con un SYN-ACK pero el atacante no envía el ACK final. Visión con netstat de un ataque DoS: Netstat permita monitorear y estar al tanto de todas las conexiones establecidas entre nuestro PC y el mundo exterior. Nos permite ver, conocer, detectar e identificar las conexiones activas establecidas con el exterior, tanto entrantes como salientes, su origen y dirección IP de procedencia, saber los puertos que tenemos abiertos a la escucha, ver e identificar las conexiones entrantes e intrusiones de red en nuestra PC, saber si tenemos programas que establezcan contacto con un host remoto… Sintaxis para el uso de NSTAT en la línea de comandos NETSTAT [opción] [-p protocolo] [intervalo] -a Muestra todas las conexiones y puertos a la escucha. -b Muestra las aplicaciones y archivos ejecutables involucrados en crear conexiones en los puertos a la escucha. -e Muestra estadísticas de Ethernet. -n Muestra los puertos y las direcciones en formato numérico. -o Permite ver la identidad de cada proceso (PID) involucrado. -r Muestra la tabla de rutas. -s Muestra las estadísticas por protocolos. -v Usado con -b, permite ver secuencias de componentes involucrados en crear una conexión. -p Muestra las conexiones por protocolos: TCP, UDP, TCPv6, o UDPv6. Intervalo Intervalo en número de segundos que se monitorea las conexiones. Continua hasta que se ejecuta Control+C. Ver que programas ocupan el puerto 80 como Origenes o Destinos netstat -abon | find ":80" tasklist /FI "PID eq 3716" taskkill /F /IM "Skype.exe" tcp tcp tcp tcp tcp tcp tcp tcp tcp tcp tcp tcp tcp tcp tcp tcp tcp tcp 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 192.168.0.3:80 192.168.0.3:80 192.168.0.3:80 192.168.0.3:80 192.168.0.3:80 192.168.0.3:80 192.168.0.3:80 192.168.0.3:80 192.168.0.3:80 192.168.0.3:80 192.168.0.3:80 192.168.0.3:80 192.168.0.3:80 192.168.0.3:80 192.168.0.3:80 192.168.0.3:80 192.168.0.3:80 192.168.0.3:80 192.168.0.5:60808 192.168.0.5:60761 192.168.0.5:60876 192.168.0.5:60946 192.168.0.5:60763 192.168.0.5:60955 192.168.0.5:60765 192.168.0.5:60961 192.168.0.5:60923 192.168.0.5:61336 192.168.0.5:61011 192.168.0.5:60911 192.168.0.5:60758 192.168.0.5:60828 192.168.0.5:61114 192.168.0.5:61074 192.168.0.5:60826 192.168.0.5:60959 LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING Visión en Server Status de un ataque DoS: El problema es que cuando el número de conexiones “Reading” llena el “ThreadsPerChild” del Apache no acepta nuevas peticiones, por lo que los nuevos clientes, aunque sean legítimos, no serán aceptados. Como Pararlo: MOD_EVASIVE Se trata de un módulo que permite implementar acciones de evasión ante los eventos de ataques DoS y DDoS. Su funcionamiento es simple, internamente crea una tabla hash dinámica de direcciones IP y URI’S (es la dirección URL cuando se complementa con subdirecciones a un recurso) la cual es tomada para realizar el proceso de validación y posterior denegación en base a los siguientes supuestos: a) Cuando un cliente solicita la misma página un número determinado de veces por segundo. b) Cuando un cliente realiza más de 50 peticiones concurrentes contra el mismo hilo que tramita esa petición por segundo. c) Cuando un cliente realiza peticiones mientras se encuentra temporalmente bloqueado en un lista negra. Ejemplo de Configuración: <IfModule mod_evasive.c> DOSHashTableSize 3097 DOSPageCount 2 DOSSiteCount 50 DOSPageInterval 1 DOSSiteInterval 1 DOSBlockingPeriod 900 </IfModule> Reducir el TimeOut: Para que las peticiones “Reading” sean “matadas” rápidamente, antes que pueda llenarse el ThreadsPerChild. Firewall Anti-Dos: (De Pago) - FortGuard - Kiwi Guard En IIS (Internet Information Service) – Restricciones de IP Dinámicas: Primeramente Inicie la consola de Administración de Internet Information Services, posiciones sobre el sitio web que quiere proteger o a nivel de servidor. Buscar y abrir “Dynamic IP Restrictions” Configure los parametros deseados: - Primeramente la cantidad de conexiones concurrentes desde un mismo IP. - La segunda opción denegar la dirección IP de acuerdo a la cantidad de pedidos (primer cuadro), en un periodo de tiempo en segundos (segundo cuadro) y la cantidad de tiempo a suspender en segundos (tercer cuadro). - La acción en este ejemplo al request será (HTTP 403 Forbidden) Ataques Bandwidth Attacks Este ataque, también conocido como hotlinking, consiste en incrustar enlaces en varios portales web a imágenes o archivos del sitio web atacado de manera que al visitar uno de estos portales automáticamente se realiza una costosa petición al sitio web atacado. Mediante este ataque se puede utilizar contenido de otros sitios web sin permiso ni «pagar» por el ancho de banda y también se puede llegar a colapsar el servidor atacado. Detección: Tenemos que comprobar el archive access.log de Apache, pero antes hay que realizar algunos cambios en la configuración. Por defecto el archivo Access.log me muestra la Ip del que realiza la petición, la fecha de la petición, la solicitud del cliente y el tipo de la misma y protocolo utilizado, código de estado del servidor y tamaño del objeto que devuelve el cliente. Para comprobar si las peticiones que se están realizando sobre los recursos de mi Servidor provienen de mi propio Servidor o de otros lugares tengo que activar en el Access.log la visualización de los campos Referer y User-Agent: Referer: dirección URL anterior que dio lugar a la solicitud. Dirección previa a la solicitud. Por ejemplo: si al realizar una llamada a http://www.mudanzaspro.es esta carga varias imágenes ubicadas en http://www.mudanzaspro.es/images/imagen1.jpg la cabecera Referer será http://www.mudanzaspro.es. User-Agent: Identifica el software de la máquina cliente (es decir, software instalado en el ordenador que solicita una página web). La identificación se realiza normalmente, mediante una combinación de sistema operativo y navegador. Para activar estos campos en el Access.log: a) Editar el httpd.conf b) Comentar la línea #CustomLog logs/access.log common – que proporcionaba el uso común de los logs. c) Descomentar la línea CustomLog logs/access.log combined – combina los dos modos de visión el común y el ampliado en un solo fichero. Ejemplo: a) El usuario de la máquina con IP 192.168.1.34 crea una página básica con una imagen apuntando a mi servidor –> 192.168.1.34/Hydrangeas.jpg b) Muestro en el Access.log como la referencia al recurso viene de un máquina que no es la mía. c) Introduzco la condición #Rewrite RewriteEngine On RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http://192.168.1.33 [nocase] RewriteRule .* - [forbidden] #/Rewrite d) Refresca su pantalla y la imagen no se muestra. Ejemplo de Servidor atacado por Iframe: 83.155.147.165 - - [17/Apr/2006:16:57:25 +0200] "GET / HTTP/1.1" 200 539 "http://piupiu23.100free.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT CLR 1.1.4322)" 24.141.160.234 - - [17/Apr/2006:16:57:25 +0200] "GET / HTTP/1.1" 200 539 "http://piupiu23.100free.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT CLR 1.1.4322)" 201.244.210.100 - - [17/Apr/2006:16:57:25 +0200] "GET / HTTP/1.1" 200 539 "http://piupiu23.100free.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT CLR 2.0.50727)" 81.31.8.118 - - [17/Apr/2006:16:57:25 +0200] "GET / HTTP/1.1" 200 539 "http://piupiu23.100free.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT CLR 1.1.4322; .NET CLR 2.0.50727)" 68.60.213.133 - - [17/Apr/2006:16:57:25 +0200] "GET / HTTP/1.1" 200 539 "http://piupiu23.100free.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 1.1.4322)" 81.193.26.49 - - [17/Apr/2006:16:57:25 +0200] "GET / HTTP/1.1" 200 539 "http://piupiu23.100free.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT CLR 1.1.4322)" 68.191.253.217 - - [17/Apr/2006:16:57:25 +0200] "GET / HTTP/1.1" 200 539 "http://piupiu23.100free.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 82.79.10.44 - - [17/Apr/2006:16:57:25 +0200] "GET / HTTP/1.1" 200 539 "http://piupiu23.100free.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT Mailinfo [313789]; .NET CLR 1.1.4322; .NET CLR 2.0.50727)" 5.1; SV1; .NET 5.1; SV1; .NET 5.1; SV1; .NET 5.1; SV1; .NET 5.1; .NET CLR 5.1; SV1; .NET 5.1)" 5.1; SV1; Existen muchas IPS origen y un solo denominador común "http://piupiu23.100free.com/". Comprobando la página del atacante: Miramos el código fuente de "http://piupiu23.100free.com/" y encontramos el iframe: <iframe src=http://foro.mudanzaspro.es/ width="1" height="1" align="center" scrolling="No" id="Resultado2" style="border: 2px dashed #78808C"> </iframe></body> Como pararlo: Este ataque se puede evitar mediante una regla de mod_rewrite que prohíba todas las peticiones de acceso a archivos cuya cabecera HTTP_REFERER, que contiene el sitio web desde el que se ha realizado la petición, no sea el del propio sitio web: #Rewrite RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http://mipaginaweb\.es [nocase] RewriteRule (\.gif|\.jpg|.\png|\.swf)$ $0 [forbidden] #/Rewrite Compresión del Contenido emitido por el Servidor: Apache prepara la respuesta que se enviará al cliente en varias etapas. Una de las etapas consiste en la modificación o transformación de los datos utilizando filtros de salida. mod_deflate, una vez cargado y activado, se inserta como un filtro, llamado DEFLATE, en la cadena de Apache de filtros de salida, que comprime todos los datos que va a través de él. Por ejemplo, se puede establecer el nivel de compresión, restringir la compresión a los tipos MIME en particular o prevenir algunos navegadores web, clientes u otros problemas de HTTP de recibir datos comprimidos desde el servidor. Las directivas de configuración siguientes se pueden insertar en el contexto del servidor principal de Apache o se pueden guardar en un archivo que será cargada desde el servidor principal o en la configuracion de un virtual host. Este módulo se encuentra ubicado dentro de la carpeta modules de la raíz principal de Apache, pero no se encuentra referenciado en el archivo de configuración. Implementación: a) LoadModule deflate_module modules/mod_deflate.so b) #Deflate #Para habilitar la compresión a cualquier tipo de contenido SetOutputFilter DEFLATE #Nivel de Compresión 9 Máximo DeflateCompressionLevel 9 #/Deflate Alternativamente se puede especificar el tipo de archivo que se quiere comprimir desde el filtro de salida DEFLATE desde la directiva AddOutputFilterByType. Ver los siguientes ejemplos: 1 AddOutputFilterByType DEFLATE text/plain 2 AddOutputFilterByType DEFLATE text/<a title="html" href="http://www.pedroventura.com/tag/html/">html</a> 3 AddOutputFilterByType DEFLATE text/xml 4 AddOutputFilterByType DEFLATE text/css 5 AddOutputFilterByType DEFLATE application/xml 6 AddOutputFilterByType DEFLATE application/xhtml+xml 7 AddOutputFilterByType DEFLATE application/rss+xml 8 AddOutputFilterByType DEFLATE application/<a title="javascript" href="http://www.pedroventura.com/javascript/">javascript</a> 9 AddOutputFilterByType DEFLATE application/x-javascript Reglas personalizadas para los navegadores problemática La compresión se puede activar o desactivar para los tipos text/html para navegadores que puedan dar problemas, o simplemente restringir la comprensión 1 BrowserMatch ^Mozilla/4 gzip-only-text/html 2 BrowserMatch ^Mozilla/4.0[678] no-gzip 3 BrowserMatch bMSIE !no-gzip !gzip-only-text/html