MONITORIZACIÓN Y LOGS

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