tail -f | sysadmin » .htaccess

Prevenir hotlinking con .htaccess en Apache

elbarto — Tue, 30 Dec 2008 23:21:16 +0000

El hotlinking (también conocido como inline linking y por otros varios sinónimos) es el uso de una imagen alojada en un sitio A para ser mostrada en un sitio B. Por ejemplo, yo podría en este blog incluir una imagen del sitio de Dataweb Hosting, pero en vez de descargarla y subirla a mi servidor, poner directamente el link a la imagen en el servidor de Dataweb, por ejemplo:

Entonces, cuando alguien entre al blog, el browser automáticametne va a ir a buscar esa imagen al servidor de Dataweb. Esto es algo absolutamente “legal” y es de gran ayuda en muchos casos. De hecho, esto mismo se puede hacer con cualquier archivo que uno incluya en un sitio web (una imagen, un video, un script de Javascript, una hoja de estilos CSS, etc.). Esto nos permite, por ejemplo, incluir en nuestros sitios videos de YouTube, los scripts de publicidad de Google AdSense, etc.

Apache Web Server

Por supuesto, al incluir un recurso de esta forma, se genera tráfico en el servidor de orígen. En algunos casos puede ser un problema, porque si yo tengo alojado mi sitio en un servidor chico y una persona publica una imagen de mi servidor en un sitio muy concurrido, mi tráfico se puede incrementar a niveles que quizás no sea capaz de manejar. En ese momento el hotlinking resulta nocivo.

Afortunadamente, Apache tiene muchos features interesantes y jugando un poco con mod_rewrite podemos evitar el hotlinking. Para ello debemos tener en cuenta que los requests de estas imágenes van a llevar siempre un HTTP Referer que va a ser igual a la URL donde éstas están incluidas. En el ejemplo anterior, al servidor de Dataweb le llegaría un request del archivo logo_dataweb_hosting.jpg con un referer que podría ser “http://www.tail-f.com.ar/”. Entonces, en nuestro archivo .htaccess hacemos lo siguiente:

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?mysite\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpg [L]

En este caso, cuando venga un request que tenga como referer una URL de un dominio diferente al mío (específicamente diferente de mi dominio principal y cualquier subdominio), que sea de un archivo con extensión jpeg, jpg, gif, bmp o png, se devolverá la imágen “nohotlink.jpg”.

Otra opción es bloquear el hotlinking por parte de dominios específicos. Por ejemplo:

RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http://(.+\.)?myspace\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(.+\.)?blogspot\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(.+\.)?livejournal\.com/ [NC]
RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpg [L]

En este caso, similar al anterior, lo que se bloquean son todos los requests que vengan de myspace.com, blogspot.com y livejournal.com.

Para cerrar debo decir que no estoy muy de acuerdo con estos métodos por una serie de razones. En primer lugar, por una cuestión de principios, siempre prefiero compartir mis imágenes (así como espero que los demás las compartan conmigo) a prohibir su uso. En segundo lugar, y más importante, este método dista mucho de ser ideal. De hecho, aunque usándolo el hotlinking resulte inútil para la persona del otro sitio que quiera usar nuestras imágenes, no dejamos de transferir la imagen nohotlink.jpg. Con lo cual, aunque se pudiera reducir el tráfico (suponemos que nohotlink.jpg sería una imagen muy liviana), no se reduciría la cantidad de requests que de por sí pueden resultar muy pesados para el servidor.

Una opción más interesante, porque evita transferir una imágen, es devolver un código de error HTTP, por ejemplo 403 (Forbidden). Para ello, en el código anterior reemplazaríamos:

RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpg [L]

por

RewriteRule .*\.(jpe?g|gif|bmp|png)$ - [F]

Sin embargo, me pareció un ejemplo interesante para publicar porque da más ideas sobre cómo usar mod_rewrite y puede aportar en la solución creativa de problemas similares.

Fuente: altlab.com

Reduciendo el tráfico usando cache en Apache

elbarto — Sun, 23 Nov 2008 02:52:13 +0000

Todos sabemos que en servidores de alta concurrencia el tema del tráfico es crítico. Reducir la cantidad de requests (pedidos) HTTP que hacen los clientes de un sitio muy visitado resulta clave para optimizar el rendimiento de nuestro servidor. Cada pedido implica una cantidad de ancho de banda que se consume (el pedido que va y la respuesta que vuelve) y procesamiento del lado del servidor y del cliente. Si logramos reducir la cantidad de los requests vamos a estar aliviando tanto el ancho de banda como la carga del servidor, con lo cual, vamos a poder atender a mayor cantidad de clientes con los mismos recursos.

Apache Web Server

Hay muchos aspectos en el diseño de la arquitectura de una aplicación que deben ser tenidos en cuenta para reducir la cantidad de requests. No podemos cubrir todos aquí, pero uno fundamental es el cache. El cache es, por lo general, una reproducción estática de un conjunto de información dinámica. Es decir, un almacenamiento temporal de una información que puede cambiar, durante un período de tiempo en el que se supone que no ha de hacerlo.

Por ejemplo, si yo tengo un conjunto grande de datos sobre los ingresos de los miembros de una familia y debo mostrar informes realizados sobre esos datos, tendría que hacer toda una serie de cálculos que mes a mes irían dando resultados distintos. Si yo sé que a lo largo de un mes, los datos de orígen no van a cambiar, puedo hacer un cache (una copia de los resultados ya calculados) para mostrarlos durante todo ese mes y no volver a hacer los cálculos.

Hay varios tipos de cache, que se pueden implementar en distintos segmentos de la arquitectura de una aplicación. En este caso nos ocuparemos del cache que se hace en el cliente HTTP (el browser) para evitar hacer consultas innecesarias al servidor (el Apache), con los beneficios que mencionamos más arriba.

Cuando cualquiera de nosotros visita un sitio web con un browser común, éste último se ocupa de hacer un request HTTP al servidor pidiendo el contenido de la URL que solicitamos (por ejemplo, el contenido del archivo http://www.tail-f.com.ar/index.php). Ahora bien, cuando recibe el contenido del archivo, si es HTML, es muy probable que éste incluya referencias a toda otra serie de archivos (imágenes, archivos de CSS, archivos de JavaScript, etc.). Automáticamente, y en forma totalmente transparente para nosotros, el browser va a hacer los requests de esos archivos, para bajar las imágenes y archivos que necesite para mostrarnos la página web a la que nosotros queremos acceder. Pero ¿qué sucede?, muchos de estos archivos, especialmente las imágenes, lo más probable es que no cambien casi nunca. El logo de la empresa dueña del sitio seguirá siendo el mismo y si yo actualizo la página o voy de la home a la sección de contacto, el logo que aparece en el encabezado se estaría descargando muchas veces. La gente que definió el protocolo HTTP ya tenía en mente este tipo de situaciones, entonces definió una serie de directivas que se envían en los headers de los mensajes HTTP, a través de las cuales el servidor le puede indicar al cliente si debe guardar ese archivo y por cuánto tiempo. De esta manera, al visitar la home del sitio por primera vez, el servidor puede decirme “este logo va a permanecer igual por todo un mes, así que guardalo y no me lo vuelvas a pedir hasta entonces”, y si yo soy obediente, lo haré, y nos haré un favor a los dos. Porque la próxima vez que vea que un HTML de este sitio me indica que tengo que poner la imagen logo.jpg en algún lado, la buscaré en mi disco rígido en vez de pedírsela al servidor, pudiendo mostrarla mucho más rápido al visitante.

¿Cómo se configura esto en Apache?

Hay dos módulos de Apache que nos servirán en este punto:

El primero permite manipular los headers (cabeceras) de los requests y responses que envía Apache. El segundo sirve para control uno de esos headers en particular, que es justamente el llamado “Expires”, que define el tiempo de expiración del archivo que se está mandando en un response.

Por lo tanto, aplicando unas reglas con expresiones regulares y estos dos módulos, en el httpd.conf de Apache o en un .htaccess, podemos definir cómo será el tratamiento de distintos tipos de archivos.

Por una cuestión de simplicidad yo lo he probado con un .htaccess, pero usarlo en el httpd.conf resultaría más óptimo aún, porque el procesamiento del .htaccess de por sí le quita rendimiento a Apache.

A continuación, dejo un ejemplo de configuración de un .htaccess en el cual se define que los archivos multimedia (sonido y video) deberán ser cacheados por un año, las imágenes por una semana, los archivos estáticos más comunes (html, css, js) cada 2 horas y los archivos dinámicos (php, cgi, pl) no deberán tener cache.

# Turn on Expires and set default to 0
ExpiresActive On
ExpiresDefault A0

# Set up caching on media files for 1 year (forever?)

ExpiresDefault A29030400
Header append Cache-Control "public"


# Set up caching on media files for 1 week

ExpiresDefault A604800
Header append Cache-Control "public"


# Set up 2 Hour caching on commonly updated files

ExpiresDefault A7200
Header append Cache-Control "proxy-revalidate"


# Force no caching for dynamic files

ExpiresActive Off
Header set Cache-Control "private, no-cache, no-store, proxy-revalidate, no-transform"
Header set Pragma "no-cache"

Fuente del código: AskApache.com