Reducir uso de CPU y memoria del servidor
¡OJO! Probablemente este artículo sólo te interese si tienes un servidor donde alojas algún blog o sitio web.
Antes de comenzar, debemos tener claros una serie de conceptos que vamos a manejar bastante en este manual. Si ya los conoces, puedes saltártelos:
- Referer o referido: Es la página de donde procede el visitante. Te reporta sitios desde donde se accede a tu página (buscadores -con las palabras clave que buscó-, foros -donde te citaron-, blogs -que te han mencionado-, etc...).
- Requests o peticiones. Se llama así a cada uno de los accesos a ficheros de tu página (imagenes, páginas, descargas, etc...). Es importante darse cuenta de que una petición a una página conlleva varias peticiones asociadas a todas las imagenes y otros recursos que la componen (siempre que estén dentro de tu servidor).
Sistema anti-hotlink
La primera solución en estos casos es recurrir a un sistema anti-hotlink: Evitar que usen las imágenes de nuestro servidor en otras páginas. En la mayoría de los sitios proponen un código donde bloquear todas las páginas excepto una lista blanca que crearemos. Sin embargo, esta solución no me agrada demasiado.
Armonth se acerca más a lo que considero mi sistema anti-hotlink ideal: un código donde no bloquear ninguna página salvo las de una lista negra.
# Sistema anti hotlink
RewriteCond %{HTTP_REFERER} \.wordpress\.com [OR]
RewriteCond %{HTTP_REFERER} \.myspace\.com [OR]
RewriteCond %{HTTP_REFERER} \.spaces\.live\.com [OR]
RewriteCond %{HTTP_REFERER} \.blogcindario\.com [OR]
RewriteCond %{HTTP_REFERER} \.blogspot\.com [OR]
RewriteCond %{HTTP_REFERER} youtube\.com [OR]
RewriteCond %{HTTP_REFERER} blogger\.com [OR]
RewriteCond %{HTTP_REFERER} livejournal\.com [OR]
RewriteCond %{HTTP_REFERER} miarroba\.com [OR]
RewriteCond %{HTTP_REFERER} showthread\. [OR,NC]
RewriteCond %{HTTP_REFERER} viewtopic\. [NC]
RewriteRule \.(jpg|gif|png)$ /img/hotlink.png [L]
El único defecto es el no proteger del enlazado en foros, así que le añadí showthread y viewtopic, nombre de variables bastante comunes en foros.
Es importante también que no tengamos ningún foro en nuestra página. Si lo tenemos, tendríamos que incluirlo en una lista blanca, para no bloquear imágenes en nuestro sitio.
Bots/Agentes masivos
Muchas veces existen bots o usuarios que realizan demasiadas peticiones, a veces inconscientemente, otras veces hasta con ánimo de provocar una denegación de servicio. En Robots.txt, todo lo que debería saber y .htaccess, bloqueando a la fuerza tienen dos completos manuales con información sobre como bloquear usuarios perjudiciales.
Verificar bots en una Lista negra
En muchas ocasiones, podemos comprobar si ciertas IPs pertenecen a bots spammers conocidos, y si estos están en algún tipo de lista negra. Por ejemplo, la IP 195.225.177.136 realizaba muchas peticiones en mi servidor. Comprobando la IP en DomainTools vemos que está incluida en la lista negra de spam. Podemos estar seguros de bloquearla.
Formularios
La mayoría de los bots spammers tienen una especial tendencia a sentirse atraídos por los formularios. Especialmente en los comentarios y trackbacks, para hacer publicidad. Muchos, incluso, pueden intentar acceder a formularios que no existen en tu sitio web (sistemas automatizados buscando vulnerabilidades):
grep “POST” access.log | cut -d” ” -f6-7 | sort | uniq -c | sort -n
Esta secuencia de comandos te muestra el número de peticiones en las que se hace un POST (comentarios, envío de emails, etc...). Podemos fijarnos, y si vemos algo raro comprobar.
Bots sin/con WWW
Un truco bastante interesante es el siguiente. En mi caso, la dirección principal del blog es www.emezeta.com. Si intentamos acceder a emezeta.com seremos redireccionados al primero. Bien, podemos aprovechar esta característica para descubrir a nuestros «enemigos».
Muchos bots adquieren el nombre del dominio y comienzan a realizar peticiones, incluyendo en su referer la dirección de nuestra página web (en mi caso, sin www) para despistar. Si somos despiertos, nos habremos dado cuenta que es imposible que vengamos de una dirección sin www puesto que habíamos redireccionado.
SetEnvIfNoCase Referer “http://emezeta\.com” bad_bot
deny from env=bad_bot
Solo tendremos que bloquear los referer sin www, como muestra este código.
Esta técnica es bastante efectiva. A mi me ha reducido el spam en un gran porcentaje.
Anti Hotlink para Google Images
La forma en la que Google ha diseñado la búsqueda de imágenes, tiene una característica que puede perjudicar mucho a algunos servidores. No sólo está el problema del hotlink (del que hablamos antes), sino que cuando accedemos a una imagen, nos muestra un marco superior con una miniatura de la imagen, mientras que en el marco inferior se carga la página que la contiene.
La mayoría de los usuarios ni siquiera miran esa página, pero deben pasar por ahí para llegar a la imagen. En Customize Google (extensión para firefox) ya lo pensaron y modifican la página si usas la extensión.
Si a esto añadimos que nos posicionamos en la primera página y primera imagen para búsquedas como perros o Lindsay Lohan, la saturación se puede llegar a notar bastante en servidores pequeños.
Si no nos interesa la indexación de imagenes de nuestro sitio, solo tenemos que bloquear al robot en nuestro robots.txt, pero si en lugar de eso, queremos que no se cargue la página del marco, sólo tenemos que incluir esto:
SetEnvIfNoCase Referer "http://images\.google\..*start" refblock
deny from env=refblock
start es una variable contador que Google incluye sólo en la página intermedia del marco (y no en las finales) y que utilizaremos para bloquear. Luego, si queremos redireccionar a nuestra página principal, en lugar de acceder a la imagen:
RewriteCond %{HTTP_REFERER} ^http://images\.google\. [NC]
RewriteRule \.(jpg|gif|png)$ http://www.pagina.com/ [L]
O bloquearla también:
RewriteCond %{HTTP_REFERER} ^http://images\.google\. [NC]
RewriteRule .* - [F]
Reducir el número de peticiones por página
Otro sistema, también bastante efectivo es el de reducir el número de elementos a cargar en la página principal de un sitio, por ejemplo. Si la página principal de un blog, contiene 45 imagenes (aunque sean iconos) y esta página tiene 7.000 peticiones a su página principal, se van a producir ¡315.000 peticiones diarias!. Todo ello sin contar ficheros CSS, javascript y demás.
cut -d” ” -f7 access.log | sort | uniq -c | sort -n
Con esta secuencia de comandos obtendremos la lista de peticiones de ficheros. Prestar mayor atención a aquellos con mayor número de peticiones. Una buena optimización puede mejorar mucho el rendimiento del servidor.
Intentar solucionar las peticiones erroneas
Finalmente, y análogo al caso anterior. Sería bueno intentar solucionar las peticiones erróneas que se producen en nuestro servidor. Una gran mayoría son debidas a problemas externos de buscadores, usuarios que enlazan mal en foros o similares. Pero también puede darse el caso de que nosotros hayamos cometido algún error.
cut -d”:” -f4 error.log | cut -d”,” -f1 | sort | uniq -c | sort -n