17.3. Servidor proxy: Squid

El caché proxy por excelencia para plataformas Linux/UNIX es Squid, del que veremos cómo realizar su configuración, qué especificaciones requerirá el sistema donde lo vayamos a instalar, cómo llevar a cabo la configuración de un servidor proxy transparente y, finalmente, cómo obtener estadísticas sobre el uso del caché con la ayuda de programas como Calamaris y cachemgr o cómo utilizar la aplicación squidGuard para realizar filtrado de páginas web.

17.3.1. ¿Qué es un caché proxy?

Squid se comporta como un caché proxy: esto es, actúa como un agente que recibe peticiones de clientes (en este caso navegadores web) y pasa estas peticiones al proveedor de servicios apropiado. Cuando los datos llegan de nuevo al agente, este almacena una copia de los datos en un caché de disco.

Las ventajas de este sistema aparecen cuando varios clientes intentan acceder a los mismos datos: ya no hará falta ir a buscarlos otra vez a Internet, sino que se servirán directamente desde el caché de disco. De esta forma, los usuarios se benefician de un ahorro importante del volumen de transferencias en red.

[Tip]Sugerencia

Squid ofrece ventajas como la posibilidad de intercomunicar jerarquías de servidores proxys para repartir la carga entre ellos o establecer estrictas reglas de control de acceso para los clientes de las redes que quieran acceder al proxy. Además, con la ayuda de otras aplicaciones es posible controlar el acceso a determinadas páginas web u obtener estadísticas sobre cuáles son las webs más visitadas, con qué frecuencia los usuarios se conectan, etc.

Squid no es un proxy genérico. Actúa como proxy entre conexiones vía HTTP y soporta también los protocolos FTP, Gopher, SSL y WAIS, pero no soporta otros protocolos de Internet como por ejemplo Real Audio, News o videoconferencia. Squid sólo soporta el protocolo UDP para realizar comunicaciones entre diferentes cachés, con lo que muchos programas multimedia quedarán igualmente excluidos.

17.3.2. Información general sobre cachés proxy

17.3.2.1. Squid y seguridad

También es posible emplear Squid junto con un cortafuegos para proteger una red interna del exterior mediante un caché proxy. Exceptuando a Squid, el cortafuego impide a todos los clientes establecer conexiones a servicios externos, haciendo que sea el proxy el que establezca todas las comunicaciones con la World Wide Web.

Si la configuración del cortafuegos incluye una zona desmilitarizada (DMZ), es allí donde se utilizará el servidor proxy. En ese caso, es importante que todos los ordenadores de la DMZ envíen sus archivos de registro (o logfiles) a ordenadores dentro de la red segura.

En el apartado 17.3.6, “Configuración de un proxy transparente” se describe un método de implementar un proxy “transparente”.

17.3.2.2. Cachés multinivel

Es posible configurar varios proxys para que cooperen intercambiando objetos entre ellos. De esta forma se reduce la carga total del sistema y se aumenta la probabilidad de que el objeto se encuentre ya en la red local. Es posible configurar incluso jerarquías de cachés, de forma que se pueda pedir páginas a cachés del mismo nivel o enviar peticiones a otros proxys de jerarquía más alta para que pidan las páginas a otros cachés existentes en la red o las obtengan directamente de la fuente.

Elegir una buena topología para los cachés es muy importante para no acabar creando más tráfico del que ya había en la red antes de instalar los cachés. Por ejemplo, en el caso de una red local muy extensa conviene configurar un servidor proxy para cada subred y conectar estos a un proxy de jerarquía superior conectado a su vez al caché proxy del ISP.

Toda esta comunicación se lleva a cabo mediante el protocolo ICP (Internet Cache Protocol) basado en UDP. Las transferencias de datos entre la mayoría de cachés se realizan mediante HTTP, protocolo basado en TCP.

Para encontrar el servidor más apropiado desde el que obtener un objeto, un caché envía una petición ICP a sus proxys vecinos. Estos le enviarán respuestas ICP con código “HIT”, si el objeto se encuentra efectivamente allí, o bien “MISS” en caso contrario. En caso que haya varios HIT, el proxy se decidirá por un servidor en especial en función de factores como la velocidad de respuesta o la proximidad, entre otros. Si las respuestas de los proxys vecinos no son satisfactorias, la petición se realizará al caché principal.

[Tip]Sugerencia

Para evitar duplicaciones de los objetos en varios cachés en la red se utilizan también protocolos ICP como CARP (Cache Array Routing Protocol) o HTCP (Hyper-Text Cache Protocol). Cuantos más objetos tengamos en la red, mayor será la posibilidad que esté el que buscamos.

17.3.2.3. Objetos cacheados en Internet

No todos los objetos disponibles en la red son estáticos. Existen páginas generadas dinámicamente por CGIs, contadores de visitantes o bien documentos que incluyen SSL para codificar el contenido y hacerlo más seguro. Por esos motivos se considera este tipo de objetos como no cacheables, ya que cada vez que se accede a ellos ya han cambiado.

Pero para todos los demás objetos que se guardan en el caché existe el problema de cuánto tiempo deben quedarse allí. Para determinarlo se asignan diferentes estados a los objetos del caché.

Los servidores web y los cachés proxy controlan el estado de un objeto añadiendo cabeceras como Last modified (última modificación) o Expires (expira) y la fecha correspondiente. También se utilizan otras cabeceras para especificar los objetos que no deben cachearse.

Normalmente, los objetos desaparecerán antes del caché por la falta de espacio en el disco. Se utiliza algoritmos para sustituir objetos en el caché, como el LRU (Last Recently Used) que consiste en sustituir los objetos menos utilizados por nuevos.

17.3.3. Requerimientos del sistema

Lo más importante es cuantificar la carga que va a tener que soportar nuestro sistema. Para esto es importante fijarse más en los picos de carga del sistema que en la media total, ya que los picos pueden llegar a ser varias veces la media del día. En caso de duda siempre es mucho mejor sobreestimar los requerimientos del sistema, ya que un Squid trabajando al límite de su capacidad puede repercutir negativamente en el funcionamiento de los servicios.

En las siguientes secciones se explican en orden de importancia los distintos factores del sistema.

17.3.3.1. Discos duros

Cuando se trata de cachés, la velocidad es un parámetro importantísimo. En los discos duros este parámetro se mide mediante su “tiempo medio de acceso” en milisegundos, que debe ser lo más bajo posible. Para lograr una velocidad elevada se recomienda utilizar discos duros rápidos.

Debido a que en la mayoría de los casos Squid lee o escribe pequeños bloques del disco duro, el tiempo de acceso del disco duro es más importante que su capacidad de transferencia de datos. Precisamente en este contexto muestran su valía los discos duros con una alta velocidad de rotación, ya que permiten un posicionamiento más rápido de la cabeza de lectura. Hoy en día, los discos duros SCSI de mayor rapidez pueden alcanzar tiempos de acceso inferiores a 4 milisegundos.

Otra posibilidad para aumentar la velocidad consiste en el uso paralelo de varios discos duros o de una estructura RAID.

17.3.3.2. Tamaño del caché de disco

Depende de varios factores. En un caché pequeño la probabilidad de un HIT (el objeto ya se encuentre en el caché) será pequeña, ya que el caché se llenará con facilidad y se deberá sustituir los objetos antiguos por nuevos. En cambio, en el caso de disponer de por ejemplo 1GB de disco para cachear, y de que los usuarios sólo necesiten 10MB al día para navegar, se tardará al menos 100 días en llenar el caché.

El método más fácil para determinar el tamaño del caché es en función del tráfico máximo que pase por el mismo. Si se dispone de una conexión de 1Mb/s, como mucho se transferirán 125KB por segundo. Si todo este tráfico va a parar al caché, en una hora será 450MB, y suponiendo que este tráfico se genera durante las 8 horas de trabajo, tendremos en total 3,6GB diarios. Como la línea no suele trabajar al máximo, la cantidad total de datos procesada por el caché es de unos 2GB. Así pues, para guardar todos los datos navegados por la WWW en un día, necesitamos en este ejemplo 2GB de memoria RAM para Squid.

17.3.3.3. Memoria RAM

La cantidad de memoria requerida por Squid está relacionada directamente con la cantidad de objetos que se encuentran en el caché. Squid también almacena referencias a los objetos en el caché y objetos utilizados frecuentemente en la memoria RAM para optimizar la obtención de los mismos. La memoria RAM es muchísimo más rápida que el disco duro.

Squid también guarda muchos otros datos en la memoria, como por ejemplo una tabla con todas las direcciones IP utilizadas, un caché para los nombres de dominio totalmente cualificados, objetos “calientes” (los que más se solicitan), buffers, listas de control de acceso, etc.

Es muy importante tener memoria más que suficiente para el proceso de Squid, ya que en el caso de tener que pasar el proceso al disco duro, las prestaciones del sistema se reducirán drásticamente. Para facilitar la administración de la memoria utilizada por el caché, podemos utilizar la herramienta cachemgr.cgi tal y como veremos en el apartado 17.3.7.1, “cachemgr.cgi”.

17.3.3.4. Potencia del procesador

Squid no es un programa que consuma mucho CPU. Solamente al arrancar y comprobar el contenido del caché es cuando se trabaja más intensamente con el procesador. El uso de máquinas con multiprocesador tampoco incrementa el rendimiento del sistema. Para obtener una mayor efectividad, es preferible aumentar la cantidad de memoria RAM o bien utilizar discos más rápidos antes que cambiar el procesador por otro más potente.

17.3.4. Arrancar Squid

Squid ya se encuentra preconfigurado en SUSE LINUX, así que casi se puede iniciar directamente después de la instalación. Los requisitos en este caso son: tener una red ya configurada, al menos un servidor de nombres, y, por supuesto, acceso a Internet. Pueden aparecer problemas en caso de utilizar una conexión telefónica que utilice configuración dinámica de DNS. En casos como este, al menos el servidor de nombres debe estar claramente especificado, ya que Squid solamente se iniciará si detecta un servidor DNS en el archivo /etc/resolv.conf.

Para iniciar Squid, introduzca (como root) el comando rcsquid start en la línea de comando. Durante el primer inicio del programa se define la estructura de directorios en var/squid/cache. Esta operación es llevada a cabo automáticamente por el script de inicio /etc/rc.d/squid y puede tardar desde pocos segundos a minutos. Cuando aparezca el mensaje done en color verde a la derecha de la pantalla, significa que Squid ya ha sido cargado. Se puede comprobar si Squid funciona correctamente en el sistema local dando los valores localhost y port 3128 como proxy en cualquier navegador web. Para permitir a todos los usuarios el acceso a Squid y por tanto a Internet, solamente es necesario cambiar una entrada en el archivo de configuración /etc/squid/squid.conf de http_acces deny all a http_acces allow all. Sin embargo, haciendo esto Squid se hace accesible para cualquiera. Por tanto, en cualquier caso deberá configurar listas de control de acceso o ACL para controlar el acceso al proxy. Más información sobre este tema en el apartado  17.3.5.2, “Listas de control de acceso o ACLs”.

Cada vez que se produce un cambio en el archivo de configuración /etc/squid/squid.conf, hay que indicar a Squid que vuelva a cargarlo. Esto se puede hacer con el comando: rcsquid reload.

De forma alternativa, también es posible reiniciar completamente Squid con rcsquid restart. Los siguientes comandos son igualmente importantes: rcsquid status, para determinar si el proxy se encuentra funcionando y rcsquid stop, para detener Squid. Este último comando puede tardar unos momentos ya que Squid espera hasta medio minuto (opción shutdown_lifetime en /etc/squid/squid.conf) antes de cortar las conexiones con los clientes y entonces todavía tendrá que guardar los datos en el disco.

[Warning]Terminar Squid

En caso que Squid sea terminado con un comando kill o bien killall, esto puede llevar a la destrucción del caché, que en ese caso tendrá que ser borrado completamente para poder reiniciar Squid.

Si Squid finaliza de forma inesperada tras un corto periodo de tiempo aunque pareciera que se había iniciado correctamente, puede ser debido a una entrada de DNS incorrecta o bien por no encontrar el archivo /etc/resolv.conf. Squid almacena la causa del error en el archivo /var/squid/logs/cache.log. Si Squid debe cargarse automáticamente cada vez que se inicie el sistema, solamente es necesario activarlo en el editor de niveles de ejecución de YaST.

Al desinstalar Squid no se borrará ni el caché ni los archivos de error. Se deberá borrar manualmente el directorio /var/cache/squid.

17.3.4.1. Servidor DNS local

Configurar un servidor DNS localmente como BIND9 es igualmente importante, incluso aunque el servidor proxy no controle su propio dominio. En ese caso actuará solamente como “caché-solamente DNS” y de esta manera será capaz de resolver peticiones DNS a través del servidor de nombres principal sin necesidad de realizar ninguna configuración especial. Si introduce en el archivo /etc/resolv.conf una entrada con dirección IP 127.0.0.1 para localhost, Squid detectará un servidor de nombres válido al iniciarse. La configuración de un servidor DNS ya es un capítulo en si misma y no será descrita con detalle en este capítulo. Será suficiente instalar el paquete e iniciarlo. El servidor de nombres del proveedor deberá especificarse en el archivo de configuración /etc/named.conf bajo forwarders junto con su dirección IP. En caso de disponer de un cortafuegos activado, incluso aunque se trate del cortafuegos personal, tendrá que asegurarse que deje pasar las peticiones DNS.

17.3.5. El archivo de configuración /etc/squid/squid.conf

La configuración de Squid se almacena en este archivo de configuración. Para poder iniciar Squid por primera vez, no es necesario hacer cambios en este archivo, aunque los clientes externos tendrán inicialmente el acceso denegado. El proxy necesita ejecutarse en localhost y normalmente utilizará el puerto 3128. Las opciones son muy extensas y están documentadas con muchos ejemplos en el archivo /etc/squid/squid.conf preinstalado. Casi todas las líneas comienzan por el símbolo # (significa que la línea está comentada y su contenido no se evaluará); las opciones relevantes se encuentran al final de la línea. Los valores por defecto corresponden casi siempre a los valores que necesitaremos, así que para muchas opciones sólo será necesario quitar el símbolo de comentario al principio de la líneas. De cualquier modo, es mejor dejar el ejemplo comentado y reescribir la línea con los nuevos parámetros una línea más abajo. De esta manera se puede ver fácilmente cuales son los valores por defecto y cuales son los cambios introducidos.

[Important]Actualización de la versión 2.4 a la versión 2.5

Después de actualizar Squid de la versión 2.4 a la versión 2.5 es necesario borrar el caché de Squid, ya que el esquema de la estructura de directorios ha cambiado.

Si está actualizando desde una versión anterior de Squid, se recomienda editar el nuevo /etc/squid/squid.conf y añadirle la configuración del archivo anterior. Si trata de implementar directamente el antiguo archivo de configuración /etc/squid.conf, es posible que no funcione correctamente debido a modificaciones en algunas opciones o a los nuevos cambios en la nueva versión.

17.3.5.1. Opciones generales de configuración (selección)

http_port 3128

Este es el puerto en el que Squid escuchará las peticiones de los clientes. El puerto por defecto es 3128, aunque 8080 se usa también comúnmente. Es posible especificar varios puertos separándolos por espacios en blanco.

cache_peer <hostname> <tipo> <puerto-proxy> <puerto-icp>

En esta opción podemos especificar otro servidor proxy como “padre” (parent), por ejemplo si quiere o debe usar el de su proveedor o ISP. En la opción <hostname>, se especifica el nombre y la dirección IP del proxy al que nos vayamos a conectar, en la opción <tipo>, especificamos parent. Para <puerto-proxy>, se debe escribir el número de puerto, el que también se especifica para los navegadores, normalmente se utiliza el 8080. Se puede fijar el <puerto-icp> a 7 o bien 0 si no se conoce el puerto ICP del proxy padre y su uso carece de interés para el proveedor. Además de esto, default y no-query se deben especificar después de los números de puerto para no permitir el uso del protocolo ICP. Squid se comportará en ese caso como un navegador normal en lo que respecta al proxy del proveedor.

cache_mem 8 MB

Esta entrada define la cantidad máxima de memoria RAM que utilizará Squid para los cachés. El valor por defecto es 8 MB.

cache_dir ufs /var/cache/squid 100 16 256

La entrada correspondiente a cache_dir fija el directorio donde se almacenarán los datos. Los números al final indican el tamaño máximo en MB que se va a utilizar, seguido del número de directorios de primer y segundo nivel. El parámetro ufs debe dejarse tal y como está. El valor por defecto es 100 MB de espacio en disco ocupado en el directorio /var/cache/squid, para luego crear 16 subdirectorios más, y en cada uno de ellos se crearán 256 directorios más. Al especificar el espacio de disco a utilizar, siempre se debe dejar espacio suficiente de reserva. Se recomienda manejar valores de tamaño para el caché entre el 50 a un 80 por ciento del espacio total disponible. Los últimos dos números sólo deben ser incrementados con precaución ya que demasiados directorios pueden provocar problemas de funcionamiento. En caso de disponer de más discos para repartir entre ellos el caché, se pueden especificar varias líneas de cache_dir.

cache_access_log /var/log/squid/access.log

ruta para archivos log.

cache_log /var/log/squid/cache.log

ruta para archivos log.

cache_store_log /var/log/squid/store.log

Ruta para archivos log. Estas tres entradas especifican la ruta donde Squid guardará sus archivos de registro. Normalmente no hace falta cambiar nada. Si Squid soporta una carga relativamente elevada, puede ser necesario distribuir el caché y estos archivos de registro en discos diferentes.

emulate_httpd_log off

Si la entrada está configurada a on, se puede obtener archivos de log en formato legible. Sin embargo, algunos programas de evaluación no pueden interpretarlos.

client_netmask 255.255.255.255

Con esta entrada, es posible enmascarar las direcciones IP en los archivos de control para ocultar la identidad de los clientes. Especificando en esta opción el valor 255.255.255.0, el último dígito de la dirección IP se interpretará como cero.

ftp_user Squid@

Con esta opción se puede fijar la contraseña que Squid utilizará para realizar el registro (ingl. login) para FTP anónimo. Es importante especificar una dirección de correo electrónico válida, ya que algunos servidores FTP pueden comprobar si es válida o no.

cache_mgr webmaster

Dirección de correo electrónico a la que el Squid enviará un mensaje en caso que termine inesperadamente. Por defecto se enviarán al webmaster.

logfile_rotate 0

Squid puede rotar archivos de registro al ejecutar la orden squid -k rotate. Los archivos serán enumerados en este proceso y después de alcanzar el valor especificado, el archivo más antiguo será sobreescrito. El valor que se utiliza normalmente es 0 ya que para archivar y borrar archivos de registro en SUSE LINUX se utiliza un cronjob que se puede encontrar en el archivo de configuración /etc/logrotate/syslog.

append_domain <dominio>

Con la opción append_domain, se puede especificar qué dominio se añadirá automáticamente en caso de que no se facilite ninguno. Normalmente se especifica el propio dominio, de forma que basta con introducir www en el navegador para acceder al servidor web propio.

forwarded_for on

Al apagar esta opción y ponerla a off, Squid eliminará las direcciones IP y el nombre de la máquina de los clientes en las peticiones HTTP.

negative_ttl 5 minutes; negative_dns_ttl 5 minutes

Normalmente no es necesario cambiar estos valores. En caso de disponer de una conexión telefónica puede ser que a veces no se pueda acceder a Internet. Squid tomará nota de las peticiones fallidas y se negará a realizarlas otra vez, incluso aunque la conexión ya se haya restablecido. En ese caso puede cambiar el valor minutes a seconds. Después de esto, al pulsar en el botón de Recargar en el navegador la conexión se reiniciará al cabo de unos segundos.

never_direct allow <acl_name>

Si desea impedir que Squid conteste a peticiones que vengan directamente de Internet, puede utilizar el siguiente comando para forzar la conexión a otro proxy. Este debe estar ya introducido en la opción cache_peer. Si se especifica como <acl_name> el valor all, todas las peticiones serán redirigidas al caché padre. Esto puede ser necesario, por ejemplo, en caso de disponer de un proveedor que estipule estrictamente el uso de sus proxys o que no permita acceso directo a Internet a través de su cortafuegos.

17.3.5.2. Listas de control de acceso o ACLs

Squid implementa un inteligente sistema para controlar el acceso al proxy que puede configurarse fácil y detalladamente mediante las ACLs. Se trata de normas procesadas secuencialmente. Las ACLs deben ser definidas antes de poderse utilizar. Algunas ACLs como all y localhost ya están definidas. La mera definición de una ACL no tiene ningún efecto. Es necesario que se ponga en funcionamiento por ejemplo con http_access para que puedan procesarse las reglas definidas anteriormente.

acl <acl_nombre> <tipo> <datos>

Una ACL necesita por lo menos tres especificaciones para definirla. El nombre <acl_nombre> se puede elegir arbitrariamente. Para el <tipo> se puede elegir de entre diferentes opciones disponibles en la sección ACCESS CONTROLS del archivo /etc/squid/squid.conf. La parte de datos depende del tipo de ACL y también puede ser leída desde un archivo, por ejemplo que contenga nombres de máquinas, direcciones IP o bien URLs. A continuación unos ejemplos:

acl usuarios srcdomain .mi-dominio.com
acl profesores src 192.168.1.0/255.255.0.0
acl alumnos src 192.168.7.0-192.168.9.0/255.255.0.0
acl mediodía time MTWHF 12:00-15:00
      
http_access allow <acl_nombre>

http_access define a quién le está permitido usar el proxy y quién puede acceder a Internet. Para todo esto se deberán definir primero las ACL correspondientes. localhost y all ya han sido definidas con anterioridad. En general se puede permitir el acceso mediante allow o bien negarlo con deny. Se puede crear una lista completa de entradas http_access que será procesada de arriba hacia abajo y dependiendo de cómo estén configuradas las reglas se podrá acceder o no a Internet para cada URL. Por eso la última entrada de todas debe ser http_access deny all. En el ejemplo siguiente localhost dispone de acceso libre mientras que todos los otros hosts tienen el acceso denegado.

http_access allow localhost
http_access deny all

Otro ejemplo donde se utilizan las reglas definidas anteriormente: el grupo profesores siempre tendrá acceso a Internet, mientras que el grupo alumnos solamente tiene acceso de lunes a viernes durante el mediodía.

http_access deny localhost
http_access allow profesores
http_access allow alumnos mediodía time
http_access deny all

Esta lista con las entradas para http_access deberá colocarse en la parte del archivo /etc/squid/squid.conf a partir de la entrada

# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR 
# CLIENTS

y finalizar en

http_access deny all
      
redirect_program /usr/bin/squidGuard

Con esta opción se puede especificar un programa de redirección como squidGuard capaz de bloquear el acceso a URL no deseadas. El acceso a Internet puede ser controlado individualmente para varios grupos de usuarios con la ayuda de autentificación por proxy y listas de control de acceso apropiadas. squidGuard es un paquete independiente que se debe instalar y configurar separadamente.

authenticate_program /usr/sbin/pam_auth

Si los usuarios deben ser autentificados en el proxy, se puede especificar un programa que realice esta función como pam_auth. Cuando se accede a pam_auth por primera vez, el usuario verá una pantalla de login donde se deberá introducir el nombre de usuario y la contraseña. Además será necesario especificar una ACL correspondiente para que sólo los usuarios registrados puedan acceder a Internet:

acl password proxy_auth REQUIRED

http_access allow password
http_access deny all

El texto REQUIRED después de proxy_auth debe ser sustituido por una lista de usuarios permitidos o por la ruta a una lista.

ident_lookup_access allow <acl_nombre>

Con esta opción se consigue que para todos los clientes que pertenezcan a la ACL especificada se ejecute un programa que determine la identidad del cliente. Al especificar el valor all como <acl_nombre>, esto será válido para todos los clientes. Para esto deberá ejecutar un daemon denominado ident en todos los clientes. En Linux, se puede utilizar para este propósito el paquete pidentd; para Windows, hay software libre disponible que se puede descargar de Internet. Para asegurar que sólo se permite acceso a clientes correctamente identificados, se deberá igualmente especificar otra ACL tal y como se define a continuación:

acl identhosts ident REQUIRED

http_access allow identhosts
http_access deny all
      

Aquí también se puede cambiar el valor REQUIRED por una lista de usuarios autorizados. El uso de ident puede reducir la velocidad del sistema debido a que el proceso de autentificación se repite para cada petición.

17.3.6. Configuración de un proxy transparente

Normalmente la forma en la que se trabaja con servidores proxy es la siguiente: el navegador web envía peticiones a un puerto determinado del servidor proxy, y este se encarga de servirle las páginas, se encuentren o no en su caché. A la hora de trabajar con una red real se pueden dar los siguientes casos:

  • Por motivos de seguridad, es más seguro que todos los usuarios utilicen un proxy para navegar por Internet.

  • Se requiere que todos los usuarios utilicen un proxy, sean los usuarios conscientes de ello o no.

  • Si el proxy de una red cambia de ubicación, los clientes existentes mantienen su antigua configuración.

En cualquiera de estos casos se puede utilizar un proxy transparente. El principio es muy sencillo: el proxy intercepta y responde a las peticiones del navegador web, así que el navegador recibirá las páginas solicitadas sin saber exactamente de dónde provienen. El proceso completo se realiza de forma transparente, de ahí el nombre que este procedimiento recibe.

17.3.6.1. Configuración del kernel

Primero hay que comprobar que el kernel del servidor proxy dispone de soporte para proxy transparente. En caso contrario habrá que añadir estas opciones al kernel y compilarlo de nuevo. Más detalles sobre este proceso en el capitulo 10, El kernel de Linux. Los módulos del kernel cambian en cada versión. Compruebe el estado del actual en /usr/share/doc/howto/en/html/mini/TransparentProxy-3.html o en Internet: http://www.tldp.org/HOWTO/mini/TransparentProxy-3.html.

17.3.6.2. Opciones de configuración en /etc/squid/squid.conf

Ahora vamos a ocuparnos de las opciones que hay que activar en el archivo /etc/squid/squid.conf para activar el proxy transparente. Dichas opciones son:

  • httpd_accel_host virtual

  • httpd_accel_port 80 # número de puerto del servidor HTTP

  • httpd_accel_with_proxy on

  • httpd_accel_uses_host_header on

17.3.6.3. Configuración del cortafuegos con SuSEfirewall2

Ahora sólo falta redirigir las peticiones de los clientes por el cortafuegos hacia el puerto en el que está Squid. Para la configuración utilizaremos la herramienta proporcionada por SuSE SuSEfirewall2. El archivo de configuración correspondiente se encuentra en /etc/sysconfig/scripts/SuSEfirewall2-custom. Este archivo está formado por diferentes entradas muy bien documentadas. Tendremos que configurar algunas opciones más. En nuestro ejemplo:

  • Dispositivo apuntando a Internet: FW_DEV_EXT="eth1"

  • Dispositivo apuntando a la red: FW_DEV_INT="eth0"

Se accederá a los puertos y servicios (ver /etc/exports) del cortafuegos desde redes no seguras como Internet. En este ejemplo sólo se especifican servicios web hacia el exterior:

FW_SERVICES_EXT_TCP="www"

Se accederá a los puertos y servicios (ver /etc/exports) del cortafuegos desde la red segura. Tanto TCP como UDP:

FW_SERVICES_INT_TCP="domain www 3128"

FW_SERVICES_INT_UDP="domain"

Accedemos a servicios web y al programa Squid (cuyo puerto por defecto es 3128). El servicio “domain” especificado anteriormente se trata del DNS o Domain Name Server. Lo más normal es utilizar este servicio, pero en caso contrario, se elimina de las entradas superiores y se configura la opción siguiente a no:

FW_SERVICE_DNS="yes"

La opción más importante es la número 15:

Ejemplo 17.1. Opción 15 de la configuración del cortafuegos

#
# 15.)
# Which accesses to services should be redirected to a localport
# on the firewall machine?
#
# This can be used to force all internal users to surf via your 
# squid proxy, or transparently redirect incoming webtraffic to 
# a secure webserver.
#
# Choice: leave empty or use the following explained syntax of 
# redirecting rules, separated by a space.
# A redirecting rule consists of 1) source IP/net, 2) destination 
# IP/net, 3) original destination port and 4) local port to 
# redirect the traffic to, separated by a colon. e.g. 
# "10.0.0.0/8,0/0,80,3128 0/0,172.20.1.1,80,8080"
#

Los comentarios indican la sintaxis que hay que seguir. En primer lugar, se escribe la dirección IP y la máscara de las “redes internas” de donde vienen nuestros datos. En segundo lugar, la dirección IP y la máscara de red a donde se “dirigen” las peticiones. En el caso de navegadores web, especificaremos la dirección de red 0/0, un comodín que quiere decir “a cualquier dirección”. A continuación, el número de puerto “original” al que se dirigen las peticiones, y finalmente, el puerto a donde “redirigimos” las peticiones.

Como Squid tiene soporte para más protocolos además de http; existe la posibilidad de desviar las peticiones dirigidas a otros puertos al proxy, como por ejemplo FTP (puerto 21), HTTPS o SSL (Puerto 443).

En el ejemplo dado, los servicios web (puerto 80) se desvían al puerto del proxy (aquí 3128). En el caso de disponer de más redes para añadir, sólo hace falta separar las diferentes entradas con un espacio en blanco en la línea correspondiente.

FW_REDIRECT_TCP="192.168.0.0/16,0/0,80,3128 192.168.0.0/16,0/0,21,3128"

FW_REDIRECT_UDP="192.168.0.0/16,0/0,80,3128 192.168.0.0/16,0/0,21,3128"

Para que el cortafuegos se inicie y con él la nueva configuración, se debe editar una entrada en el archivo /etc/sysconfig/SuSEfirewall2 y asignar el valor "yes" a la entrada FW_START:

Inicie Squid tal como se mostró en el apartado 17.3.4, “Arrancar Squid”. Para comprobar que todo funciona correctamente, compruebe los archivos de registro de Squid en /var/log/squid/access.log. Para verificar que todos los puertos están correctamente configurados, se puede realizar un escaneo de puertos en la máquina desde un ordenador que se encuentre fuera de la red local. Sólo deberá estar abierto el puerto de servicios web (80). Para llevar a cabo el portscan se puede utilizar nmap -O dirección_IP.

17.3.7. Squid y otros programas

En esta sección veremos cómo otros programas interactúan con Squid. cachemgr.cgi permite al administrador del sistema comprobar la cantidad de memoria necesaria para cachear los objetos, squidGuard filtra páginas web, y calamaris es un generador de informes para Squid.

17.3.7.1. cachemgr.cgi

El administrador de caché (cachemgr.cgi) es una utilidad CGI para mostrar estadísticas sobre el consumo de memoria del proceso Squid. Este método representa una forma más sencilla de controlar el uso del caché y ver estadísticas sin necesidad de registrarse en el servidor.

17.3.7.2. Configuración

En primer lugar, se necesita tener un servidor web ejecutándose en el sistema. Para comprobar si Apache está funcionando, escriba como usuario root: rcapache status.

Si aparece un mensaje como el siguiente, Apache se está ejecutando en el ordenador:

Checking for service httpd: OK

Server uptime: 1 day 18 hours 29 minutes 39 seconds

Si no es así, ejecute el comando rcapache start para iniciar Apache con la configuración por defecto de SUSE LINUX.

El último paso es copiar el archivo cachemgr.cgi del directorio /usr/share/doc/packages/squid/scripts/ al directorio de Apache /srv/www/cgi-bin.

17.3.7.3. ACLs para el administrador de caché en /etc/squid/squid.conf

Hay algunas opciones configuradas ya por defecto en el archivo de configuración para el administrador de caché:

acl manager proto cache_object

acl localhost src 127.0.0.1/255.255.255.255

Con las siguientes normas de acceso:

http_access allow manager localhost

http_access deny manager

La primera ACL es la más importante, ya que el administrador de caché tratará de comunicarse con Squid mediante el protocolo cache_object. Las reglas siguientes asumen que el servidor web y Squid se encuentran en la misma máquina. Si la comunicación entre el administrador de caché y Squid se origina en el servidor de web en otro ordenador, tendremos que incluir una ACL adicional como en la figura 17.2, “Reglas de acceso”.

Ejemplo 17.2. Reglas de acceso

acl manager proto cache_object

acl localhost src 127.0.0.1/255.255.255.255
acl webserver src 192.168.1.7/255.255.255.255 # IP webserver
    

También son necesarias las reglas siguientes del archivo 17.3, “Reglas de acceso”.

Ejemplo 17.3. Reglas de acceso

http_access allow manager localhost

http_access allow manager webserver
http_access deny manager

Igualmente también se puede configurar una contraseña para el administrador si deseamos tener acceso a más opciones, como por ejemplo poder cerrar el caché de forma remota o ver más información sobre el mismo. En ese caso sólo hay que configurar la entrada cachemgr_passwd con una contraseña para el administrador y la lista de opciones que deseamos ver. Esta lista aparece como una parte de los comentarios a la entrada en /etc/squid/squid.conf.

Cada vez que se modifique el archivo de configuración es necesario reiniciar Squid. Utilice para ello el comando rcsquid reload.

17.3.7.4. Leer las estadísticas

En primer lugar, diríjase a la página web correspondiente: http://miservidor.ejemplo.org/cgi-bin/cachemgr.cgi. Pulse en continue y navegue a través de las diferentes estadísticas. Hay más detalles para cada entrada mostrada por el administrador de cachés en la FAQ de Squid en la http://www.squid-cache.org/Doc/FAQ/FAQ-9.html.

17.3.7.5. squidGuard

Este capítulo no pretende mostrar una configuración completa de squidGuard, sino más bien presentarlo y comentar su utilización. Para ver las opciones de configuración con más detalle, visite la web de squidGuard en http://www.squidguard.org.

squidGuard es un programa gratuito, bajo licencia GPL, que funciona como un filtro flexible ultra rápido capaz de redireccionar páginas web y que funciona como “plugin de control de acceso” para Squid. Permite definir diversas reglas de acceso con diferentes restricciones para distintos grupos de usuarios que trabajen sobre un caché de Squid. squidGuard utiliza la interfaz estándar de redirección de Squid. Algunos ejemplos de utilización de squidGuard:

  • Limitar el acceso por web para una serie de usuarios a una lista de servidores web o URL conocidas y aceptadas.

  • Bloquear el acceso para algunos usuarios a servidores web o URLs que estén en alguna lista negra.

  • Bloquear para algunos usuarios el acceso a URLs que coincidan con una determinada lista de expresiones o palabras.

  • Redireccionar URLs bloqueadas a una página de información “inteligente” basada en CGI.

  • Redireccionar usuarios no registrados a una página de registro.

  • Redireccionar banners a un GIF vacío.

  • Tener diferentes normas de acceso basadas en la hora del día, día de la semana, etc.

  • Tener diferentes normas para diferentes grupos de usuarios.

Ni squidGuard ni Squid se pueden usar para:

  • Editar, filtrar o censurar texto dentro de documentos.

  • Editar, filtrar o censurar lenguajes de script con HTML embebido como JavaScript o VBscript.

17.3.7.6. Utilizar squidGuard

Instale el paquete squidgrd. Edite un archivo mínimo de configuración /etc/squidguard.conf. Hay muchos ejemplos diferentes de configuración en http://www.squidguard.org/config/. Siempre se puede experimentar más tarde con configuraciones más complicadas.

El paso siguiente es crear una página web que será la página que mostrará el mensaje de “acceso denegado” o una página CGI más o menos inteligente a la cual redirigir Squid en caso que algún cliente pida algún sitio web que esté en la lista negra. Una vez más, el uso de Apache es altamente recomendable.

Ahora debemos decirle a Squid que utilice squidGuard. Lo haremos mediante las siguientes entradas en el archivo /etc/squid/squid.conf:

redirect_program /usr/bin/squidGuard

Existe todavía otra opción llamada redirect_children que configura el número de procesos diferentes para “redirigir” (en este caso procesos de squidGuard). squidGuard es suficientemente rápido para procesar grandes cantidades de solicitudes (squidGuard es realmente rápido: 100.000 consultas en 10 segundos en un Pentium 500MHz con 5.900 dominios, 7.880 URLs, en total 13.780). Por eso no se recomienda configurar más de cuatro procesos a la vez para no gastar memoria innecesariamente en la asignación de los procesos.

redirect_children 4

Por último vuelva a cargar la configuración de Squid con rcsquid reload. A continuación ya se puede comprobar la configuración con cualquier navegador.

17.3.7.7. Generación de informes con Calamaris

Calamaris es un script en Perl utilizado para generar informes de la actividad del caché en formatos ASCII o HTML. Funciona directamente con los archivos de registro de acceso de Squid. La página web de Calamaris está en http://Calamaris.Cord.de/. La utilización del programa es bastante fácil. Entre al sistema como root y ejecute: cat access.log.files | calamaris [options] > reportfile.

Al enviar más de un archivo de registro es importante que estos estén cronológicamente ordenados, es decir, primero los archivos más antiguos.

Las diferentes opciones:

-a

utiliza todos los informes disponibles

-w

muestra los resultados en formato HTML

-l

muestra un mensaje o un logotipo en la cabecera del informe

Puede obtener más información sobre las diferentes opciones del programa en la página de manual de calamaris: man calamaris.

Otro completo generador de informes es SARG (Squid Analysis Report Generator). . Más información sobre SARG se puede encontrar en las páginas web correspondientes en: http://web.onda.com.br/orso/

17.3.8. Información adicional sobre Squid

Visite la página web de Squid: http://www.squid-cache.org/. Aquí encontrará la Guía de Usuario de Squid y una extensa colección de FAQ sobre Squid.

El Mini-Howto sobre proxys transparentes se encuentra en el paquete howtoen, bajo /usr/share/doc/howto/en/mini/TransparentProxy.gz

También existen listas de correo para Squid en: squid-users@squid-cache.org. El archivo para estas listas se encuentra en: http://www.squid-cache.org/mail-archive/squid-users/