Servidor Proxy SQUID

Emiliano L opez 13 de noviembre de 2006

Indice
1. Introducci on 2. Caracter sticas de un proxy 3. SQUID 3.1. Funcionamiento . . . . . . . . . . . . 3.2. Jerarqu a de servidores . . . . . . . . 3.3. Conguraci on . . . . . . . . . . . . . 3.3.1. Nombre del Host y Puerto . . 3.3.2. Tama no de la memoria cach e 3.3.3. Tiempo de vida de la cach e . 3.3.4. Jerarqu a de cach e . . . . . . 3.3.5. Control de acceso . . . . . . . 3.4. Autenticaci on . . . . . . . . . . . . . 3.5. Vericaci on de logs . . . . . . . . . . 3.6. Un ejemplo simple . . . . . . . . . . 4. Trabajo Pr actico 5. Referencias 1 1 2 2 3 3 3 3 3 4 4 5 7 7 7 8

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

1.

Introducci on

Un servidor proxy es un software que realiza tareas de servidor intermediario. El caso m as com un es utilizarlo para compartir internet en ambitos donde se posee una u nica conexi on a internet y varias computadoras. El servidor proxy se conecta directamente a internet y por otra interfaz a la red interna, de modo que todos los pedidos a internet de las computadoras pertenecientes a la LAN pasan a trav es del proxy y es este en realidad el que hace las conexiones hacia la web y luego entrega las respuestas a los hosts correspondientes.

2.

Caracter sticas de un proxy

Una de las funciones principales de un servidor proxy es actuar como cache de contenido principalmente web (http). Esto mejora el desempe no de una red consumiendo menos recursos, debido que frente a un nuevo pedido de un sitio que ya ha sido realizado, en vez de generar tr aco hacia internet se entrega el sitio cuyo contenido se encuentra almanecado en el servidor.

Figura 1: conexiones sin proxy

Figura 2: conexiones con proxy

3.

SQUID

SQUID es un software de libre distribuci on para realizar la tarea de un servidor proxy con prestaciones muy profesionales. Suele acompa nar a las distribuiciones m as habituales, aunque tambi en puede obtenerse de su sitio ocial (http://www.squid-cache.org/). No se recomiendan versiones previas a la 2.4, ya que presentan fallas de seguridad, actualmente la versi on estable es la 2.6 STABLE. SQUID puede funcionar como Servidor Intermediario (Proxy) y cach e de contenido de Red para los protocolos HTTP, FTP, GOPHER y WAIS, Proxy de SSL, cach e transparente, cach e de consultas DNS y otras muchas m as como ltraci on de dominios y control de acceso por IP y por usuario. Provee potentes opciones para tener un completo control sobre los sitios que se visitan, asi como para ltrar, permitir o bloquear el acceso de determinados equipos, ips, dominios, etc.

3.1.

Funcionamiento
LRU (pol tica por defecto): Se eliminan de la cache los objetos que no han sido accedidos en mucho tiempo, manteniendo en la cache los que han sido utilizado mas recientemente. LFUDA: Los objetos m as solicitados permanecen en el cach e sin importar su tama no, de modo que un objeto grande que se solicite con mayor frecuencia impedir a que se pueda hacer cach e de objetos peque nos que se soliciten con menor frecuencia. 2

SQUID realiza el almacenamientos de objetos utilizando diferentes algoritmos:

GDSF: Optimiza la eciencia por objeto, manteniendo en el cach e los objetos peque nos m as frecuentemente solicitados; descarta del cach e objetos grandes que sean solicitado con frecuencia.

3.2.

Jerarqu a de servidores

SQUID permite especicar otros servidores intermediarios, utilizando la cach e en una jerarqu a como padres o como hermanos, dependiendo de la topolog a de la red estos pueden operar en cascada (padres) o en paralelo (hermanos).

Figura 3: jerarqu a de cach es

3.3.

Conguraci on

La conguraci on del servidor proxy SQUID se realiza en un u nico archivo de texto plano generalmente ubicado en /etc/squid/squid.conf. La sintaxis en este archivo debe comenzar en la primer columna, sin dejar espacios. 3.3.1. Nombre del Host y Puerto

La primera conguraci on b asica debe ser el nombre y los puertos del host. Por defecto SQUID escucha en el puerto 3128 y utiliza el 3130 para comunicarse mediante ICP (Internet Cache Protocol) con otras caches. visible_hostname mysquid http_port 3128 icp_port 3130 3.3.2. Tama no de la memoria cach e

Aqui se ja el el directorio y el espacio que se utilizar a del disco rigido para almacenar las p aginas. Por defecto SQUID usar a 100 MB, y lo almacenar a por defecto en 16 subdirectorios de primer nivel y en 256 subdirectorios de segundo nivel: cache_dir ufs /var/cache/squid 100 16 256 3.3.3. Tiempo de vida de la cach e

Podemos congurar el tiempo que los objetos permanecer an almacenados en el servidor. reference_age 1 month 3

3.3.4.

Jerarqu a de cach e

La sintaxis para la consulta de caches es la siguiente: cache_peer <ip-host> <tipo> <http_port> <icp_port> [opciones] Aqu se especica la ip del host servidor, el tipo (si es padre o hermano, parent-sibling ), en qu e puerto se realizar an los pedidos y el di alogo ICP. No necesariamente se deben especicar opciones. Las m as utilizadas son las siguientes: default Si es un servidor padre que no dialoga mediante ICP y es utilizado como u ltimo recurso. proxy-only No almacena localmente ninguna respuesta. no-query No utiliza ICP con ese servidor. 3.3.5. Control de acceso

Es necesario establecer listas de control de acceso (acl) que denan una red o bien ciertas m aquinas en particular. A cada acl se le asignar a una regla de control de acceso (acr) que funcionar a bloqueando o permitiendo el acceso a trav es de squid. Comunmente las acl se denen y aplican (acr) de la siguiente manera: acl [nombre de la lista] src/dst [ips que componen la lista] http_access allow/deny [nombre de la lista] Para el siguiente ejemplo, la red 192.168.0.0/24 llamada LAN1 tendr a permitido acceder al proxy: acl LAN1 src 192.168.0.0/255.255.255.0 http_access allow LAN1 Adem as de direcciones ip, en las acl es posible denir nombres de dominios y puertos utilizando dstdomain y port de la siguiente manera: acl educativas dstdomain edu.ar acl diario dstdomain clarin.com acl safeports port 443 http_access deny diario http_access allow educativas http_access allow safeports Es importante tener en cuenta que las acl educativas y diario no hubiesen coincidido si se visitaban sitios como ch.unl.edu.ar o deportes.clarin.com. Para bloquear tambi en los subdominios se debe utilizar el punto (.) como comod n antes del dominio: acl educativas dstdomain .edu.ar acl diario dstdomain .clarin.com Existe una acl que debe estar congurada para que squid funcione: acl all src 0.0.0.0/0.0.0.0 Esta acl, a diferencia de las dem as debe tener obligatoriamente la etiqueta all Coincidencia en las acl Para que se produzca una coincidencia (match) en una acl, se utiliza la funci on OR, para el siguiente ejemplo: acl ips src 192.168.0.10 192.168.0.11 192.168.0.16 , cuando la ip origen sea 192.168.0.11 la coincidencia se dar a luego de la segunda direcci on ip, y la acl ser a considerada verdadera. Por esta raz on, se recomienda incluir las opciones m as comunes al comienzo, para acelerar el proceso de evaluaci on. 4

Coincidencias en las acr Para que una acr coincida se utiliza la funci on AND. Para el ejemplo: http_access allow educativas safeport debe accederse a sitios .edu.ar al puerto 443 para que sea permitido el acceso. Permisos para ICP En las reglas de control de accesso tambi en se debe otorgar permiso al di alogo ICP con la directiva icp_access: icp_access [allow|deny] [nombre_acl] Par ametros extras Otro s mbolo reservado consiste en la utilizaci on del signo de admiraci on de cierre: ! .Se utiliza como negaci on de una determinada acl, para el ejemplo, !LAN1 signica que el acceso a SQUID es para todos los que no formen parte de LAN1. Una directiva importante es never_direct, utilizada en conjunto con una acl para aquellos pedidos que nunca deben ser enviados directamente hacia el servidor original. Por ejeplo que squid se encuentre ubicado detras de un rewall, debe poder dialogar con sus servidores internos directamente sin embargo para los pedidos hacia serviodores externos deben dirigirse hacia un rewall o proxy. En este sentido, squid no se conecta directamente a sitios fuera del rewall. Para realizar esto: acl sitios_internos dstdomain .fich.unl.edu.ar never_direct allow !sitios_internos SQUID por defecto intenta reenviar los pedidos a un parent o sibling, si se desea que intente conectarse directamente con el servidor debe habilitarse la opci on prefer_direct on Dos acl y acr que siempre son denidas por cuesti on de seguridad son : acl localhost src 127.0.0.1/255.255.255.255 acl admin proto cache_object http_access allow admin localhost http_access deny admin Se utilizan para permitir la administraci on de los objetos cacheados unicamente al localhost.

3.4.

Autenticaci on

SQUID permite realizar autenticaci on mediante diferentes m etodos, Basic, Digest y NTLM. Estos m etodos especican c omo SQUID recive el nombre de usuario y la clave desde los clientes. Por cada m etodo, SQUID provee varios m odulos de autenticaci on (helpers) que ser an los encargados de realizar la validaci on (NCSA, PAM, SASL, YP y SMB). Aqu veremos c omo congurar Basic utilizando el m odulo NCSA. Creaci on de usuarios Desde la linea de comandos, creamos un archivo en el directorio /etc/squid/claves: #touch /etc/squid/claves y luego los usuarios: # htpasswd2 /etc/squid/claves usuario1 Luego se solicitar a la clave y la conrmaci on de la misma. Hay que tener en cuenta que htpasswd2 debe estar instalado (pertenece a Apache2).

Conguraci on En el archivo /etc/squid/squid.conf se debe congurar el tipo de autenticaci on (basic), la ruta del m odulo NCSA y la ruta del archivo que contiene los usuarios y sus passwords. auth_param basic program /usr/sbin/ncsa_auth /etc/squid/claves Luego se debe crear una acl que al ser invocada en una regla de control de accesso solicitar a el usuario y la clave: acl con_clave proxy_auth REQUIRED Para comprender c omo se utiliza la acl que denimos veremos un ejemplo. Si se desea que todas las personas que accedan al sitio www.ociosos.com ingresen un usuario y clave, y que para el resto de las p aginas no haya restricci on alguna: acl all src 0.0.0.0/0.0.0.0 acl ocio dstdomain www.ociosos.com acl con_clave proxy_auth REQUIRED http_access allow ocio con_clave http_access allow all Si en cambio, quisieramos que para navergar por el proxy todos los usuarios de la red tengan que ingresar usuario y clave, dentro de las reglas de control de accesso basta con poner: http_access allow all con_clave La combinaci on de diferentes acl nos otorga gran felxibilidad, teniendo en cuenta que agregando a cualquier regla de control de accesso la acl con_clave obligamos a validar contra SQUID para permitir el acceso a un determinado sitio, ip, en alg un rango horario, etc. Autenticaci on por grupos La autenticaci on que vimos en el punto anterior tiene una deciencia, supongamos que quisieramos subdividir un cierto grupo de usuarios para que tengan diferentes permisos de acceso a sitios web. Por ejemplo, el grupo de comunicaci on deber a poder acceder a leer los diarios, no as el grupo de desarrollo que solo tiene permitido ingresar al sitio www.lawebdelprogramador.com. Con lo visto anteriormente no podr amos hacerlo ya que tenemos todos los usuarios y sus correspondientes claves en un mismo archivo. Para solucionar este inconveniente deber amos realizar peque nas modicaciones a las listas de contro de acceso. La denici on de los usuarios con sus claves ser a exactamente igual que en el punto anterior, a diferencia que ahora podremos denir en un nuevo archivo los usuarios que pertenecen a un determinado grupo. Con el siguiente ejemplo quedar a mas claro. acl acl acl acl acl acl all src 0.0.0.0/0.0.0.0 diario dstdomain www.litoral.com.ar web_programar dstdomain www.lawebdelprogramador.com con_clave proxy_auth REQUIRED comunicacion proxy_auth /etc/squid/comunicacion desarrolladores proxy_auth /etc/squid/desarrolladores

http_access allow desarrolladores web_programar http_access allow comunicacion diario Cada usuario que pertenezca a un grupo deber a encontrarse en una u nica linea ya sea para el grupo de comunicaci on ( /etc/squid/comunicacion ) como para el grupo de desarrolladores (/etc/squid/desarrolladores ). Y tambi en deber a estar creado mediante el comando htpasswd2 al igual que en el punto anterior en /etc/squid/claves. En conclusi on, todos los usuarios por m as que pertenezcan a diferentes grupos deben ser creados en un archivo utilizando htpasswd2, la divisi on de grupos se realizar a guardando los nombres de los usuarios en diferentes archivos, uno por linea y luego se aplicar an como se vio en el ejemplo mediante las acl y las reglas de control de acceso (http_access ).

3.5.

Vericaci on de logs

SQUID almacena en el directorio /var/log/squid informaci on sobre los accesos, di alogos con otros servidores SQUID, etc. Existen varios archivos de logs, el que nos brinda informaci on sobre el acceso al servidor es access.log. Cuando se entrega a un cliente un objeto que se encontraba almacenado, se produce un HIT y si el objeto debe ser consultado hacia internet entonces es un MISS. El analisis de los logs por lo general se realiza con herramientas de software independientes de SQUID. Dos de las m as utilizadas son SARG (Squid Analysis Report Grpahics) y Webalizer, las mismas generan reportes gr acos con estad sticas en un archivo html. Son una excelente herramienta para llevar un control detallado sobre la utilizaci on de la navegaci on web.

3.6.

Un ejemplo simple

Una servidor proxy simple podr a denirse de la siguiente manera: Listas de control de acceso:

#---parametros globales---# visible_hostname squid1 http_port 3128 icp_port 3130 cache_dir ufs /var/cache/squid 400 16 256 #---consulta de cach es---# #cache_peer <host> <type> <http_port> <icp_port> <options> cache_peer 192.168.1.252 parent 3128 7 no-query default cache_peer 192.168.1.108 sibling 3128 3130 proxy-only #--- ACL---# acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl webserver dst 192.168.1.10/255.255.255.255 acl todalared src 192.168.1.0/255.255.255.0 #--- Reglas de control de acceso---# http_access allow manager localhost http_access deny manager never_direct allow !webserver http_access allow todalared http_access deny all icp_access allow all

4.

Trabajo Pr actico

Para realizar el pr actico nos basaremos en la topolog a de la siguiente gura. En donde se congurar a tres servidores SQUID, uno como Parent y dos como Sibling

Figura 4: Estructura Jer arquica 1. Compruebe la conectividad entre tres hosts mediante el comando ping. 2. Congure tres servidores utilizando el puerto 3128 para pedidos http y el puerto 3130 para la comunicaci on entre servidores. 3. Conguraci on del servidor Parent 3.1 Este servidor debe realizar los pedidos al proxy 192.168.0.120 sin utilizar ICP, tenga en cuenta que para evitar pedidos ICP debe utilizar la opci on no-query. 3.2 Permita el acceso de toda la red 10.0.2.0/24 4. Conguraci on de los servidores Sibling 4.1 Estos servidores deben realizar los pedidos al servidor Parent 4.2 Entre ambos servidores Siblings deben consultarse sus caches sin almacenar localmente los objetos ya almacenados en el hermano (proxy-only ). 5. Compruebe el funcionamiento de los servidores visitando diferentes sitios y verique los logs. 6. Bloquee el acceso al dominio unl.edu.ar y compruebe su funcionamiento. 7. Bloquee el accesso de toda la red 10.0.2.0/24 y compruebe su funcionamiento.

5.

Referencias
OReilly - Squid The Denitive Guide 2004 Squid Web Proxy Cache - www.squid-cache.org The Linux Document Project - http://es.tldp.org ViSOLVE - www.visolve.com/squid/ SUSE LINUX - www.suse.com/training Linux Para Todos - www.linuxparatodos.net SARG - http://sarg.sourceforge.net/sarg.php Webalizer - http://www.mrunix.net/webalizer/