Servidor Proxy SQUID Emiliano López 13 de noviembre de 2006 Índice 1. Introducción 1 2. Características de un proxy 1 3. SQUID 2 3.1. Funcionamiento........................................ 2 3.2. Jerarquía de servidores.................................... 3 3.3. Configuración......................................... 3 3.3.1. Nombre del Host y Puerto.............................. 3 3.3.2. Tamaño de la memoria caché............................ 3 3.3.3. Tiempo de vida de la caché............................. 3 3.3.4. Jerarquía de caché.................................. 4 3.3.5. Control de acceso................................... 4 3.4. Autenticación......................................... 5 3.5. Verificación de logs...................................... 7 3.6. Un ejemplo simple...................................... 7 4. Trabajo Práctico 7 5. Referencias 8 1. Introducción Un servidor proxy es un software que realiza tareas de servidor intermediario. El caso más común es utilizarlo para compartir internet en ámbitos donde se posee una única conexión 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és del proxy y es éste 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ño 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áfico hacia internet se entrega el sitio cuyo contenido se encuentra almanecado en el servidor. 1
Figura 1: conexiones sin proxy Figura 2: conexiones con proxy 3. SQUID SQUID es un software de libre distribución para realizar la tarea de un servidor proxy con prestaciones muy profesionales. Suele acompañar a las distribuiciones más habituales, aunque también puede obtenerse de su sitio oficial (http://www.squid-cache.org/). No se recomiendan versiones previas a la 2.4, ya que presentan fallas de seguridad, actualmente la versión estable es la 2.6 STABLE. SQUID puede funcionar como Servidor Intermediario (Proxy) y caché de contenido de Red para los protocolos HTTP, FTP, GOPHER y WAIS, Proxy de SSL, caché transparente, caché de consultas DNS y otras muchas más como filtración 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 filtrar, permitir o bloquear el acceso de determinados equipos, ip s, dominios, etc. 3.1. Funcionamiento SQUID realiza el almacenamientos de objetos utilizando diferentes algoritmos: 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ás solicitados permanecen en el caché sin importar su tamaño, de modo que un objeto grande que se solicite con mayor frecuencia impedirá que se pueda hacer caché de objetos pequeños que se soliciten con menor frecuencia. 2
GDSF: Optimiza la eficiencia por objeto, manteniendo en el caché los objetos pequeños más frecuentemente solicitados; descarta del caché objetos grandes que sean solicitado con frecuencia. 3.2. Jerarquía de servidores SQUID permite especificar otros servidores intermediarios, utilizando la caché 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). 3.3. Configuración Figura 3: jerarquía de cachés La configuración del servidor proxy SQUID se realiza en un ú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 configuración básica 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ño de la memoria caché Aqui se fija el el directorio y el espacio que se utilizará del disco rigido para almacenar las páginas. Por defecto SQUID usará 100 MB, y lo almacenará 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é Podemos configurar el tiempo que los objetos permanecerán almacenados en el servidor. reference_age 1 month 3
3.3.4. Jerarquía de caché La sintaxis para la consulta de caches es la siguiente: cache_peer <ip-host> <tipo> <http_port> <icp_port> [opciones] Aquí se especifica la ip del host servidor, el tipo (si es padre o hermano, parent-sibling), en qué puerto se realizarán los pedidos y el diálogo ICP. No necesariamente se deben especificar opciones. Las más utilizadas son las siguientes: default Si es un servidor padre que no dialoga mediante ICP y es utilizado como ú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 definan una red o bien ciertas máquinas en particular. A cada acl se le asignará una regla de control de acceso (acr) que funcionará bloqueando o permitiendo el acceso a través de squid. Comunmente las acl se definen 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á permitido acceder al proxy: acl LAN1 src 192.168.0.0/255.255.255.0 http_access allow LAN1 Además de direcciones ip, en las acl es posible definir 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 fich.unl.edu.ar o deportes.clarin.com. Para bloquear también 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 configurada para que squid funcione: acl all src 0.0.0.0/0.0.0.0 Esta acl, a diferencia de las demás debe tener obligatoriamente la etiqueta all Coincidencia en las acl Para que se produzca una coincidencia (match) en una acl, se utiliza la función 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á luego de la segunda dirección ip, y la acl será considerada verdadera. Por esta razón, se recomienda incluir las opciones más comunes al comienzo, para acelerar el proceso de evaluación. 4
Coincidencias en las acr Para que una acr coincida se utiliza la función 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én se debe otorgar permiso al diálogo ICP con la directiva icp_access: icp_access [allow deny] [nombre_acl] Parámetros extras Otro símbolo reservado consiste en la utilización del signo de admiración de cierre:!.se utiliza como negación de una determinada acl, para el ejemplo,!lan1 significa 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 firewall, debe poder dialogar con sus servidores internos directamente sin embargo para los pedidos hacia serviodores externos deben dirigirse hacia un firewall o proxy. En este sentido, squid no se conecta directamente a sitios fuera del firewall. 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ón prefer_direct on Dos acl y acr que siempre son definidas por cuestión 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ón de los objetos cacheados unicamente al localhost. 3.4. Autenticación SQUID permite realizar autenticación mediante diferentes métodos, Basic, Digest y NTLM. Estos métodos especifican cómo SQUID recive el nombre de usuario y la clave desde los clientes. Por cada método, SQUID provee varios módulos de autenticación (helpers) que serán los encargados de realizar la validación (NCSA, PAM, SASL, YP y SMB). Aquí veremos cómo configurar Basic utilizando el módulo NCSA. Creación 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á la clave y la confirmación de la misma. Hay que tener en cuenta que htpasswd2 debe estar instalado (pertenece a Apache2). 5
Configuración En el archivo /etc/squid/squid.conf se debe configurar el tipo de autenticación (basic), la ruta del módulo 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á el usuario y la clave: acl con_clave proxy_auth REQUIRED Para comprender cómo se utiliza la acl que definimos 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áginas no haya restricción 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ón 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ún rango horario, etc. Autenticación por grupos La autenticación que vimos en el punto anterior tiene una deficiencia, 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ón 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ñas modificaciones a las listas de contro de acceso. La definición de los usuarios con sus claves será exactamente igual que en el punto anterior, a diferencia que ahora podremos definir en un nuevo archivo los usuarios que pertenecen a un determinado grupo. Con el siguiente ejemplo quedará mas claro. acl all src 0.0.0.0/0.0.0.0 acl diario dstdomain www.litoral.com.ar acl web_programar dstdomain www.lawebdelprogramador.com acl con_clave proxy_auth REQUIRED acl comunicacion proxy_auth /etc/squid/comunicacion acl 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á encontrarse en una única linea ya sea para el grupo de comunicación ( /etc/squid/comunicacion) como para el grupo de desarrolladores (/etc/squid/desarrolladores ). Y también deberá estar creado mediante el comando htpasswd2 al igual que en el punto anterior en /etc/squid/claves. En conclusión, todos los usuarios por más que pertenezcan a diferentes grupos deben ser creados en un archivo utilizando htpasswd2, la división de grupos se realizará guardando los nombres de los usuarios en diferentes archivos, uno por linea y luego se aplicarán como se vio en el ejemplo mediante las acl y las reglas de control de acceso (http_access ). 6
3.5. Verificación de logs SQUID almacena en el directorio /var/log/squid información sobre los accesos, diálogos con otros servidores SQUID, etc. Existen varios archivos de logs, el que nos brinda información 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ás utilizadas son SARG (Squid Analysis Report Grpahics) y Webalizer, las mismas generan reportes gráficos con estadísticas en un archivo html. Son una excelente herramienta para llevar un control detallado sobre la utilización de la navegación web. 3.6. Un ejemplo simple Una servidor proxy simple podría definirse 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és---# #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áctico Para realizar el práctico nos basaremos en la topología de la siguiente figura. En donde se configurará tres servidores SQUID, uno como Parent y dos como Sibling 7
Figura 4: Estructura Jerárquica 1. Compruebe la conectividad entre tres hosts mediante el comando ping. 2. Configure tres servidores utilizando el puerto 3128 para pedidos http y el puerto 3130 para la comunicación entre servidores. 3. Configuración 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ón no-query. 3.2 Permita el acceso de toda la red 10.0.2.0/24 4. Configuración 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 verifique 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 O Reilly - Squid The Definitive 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/ 8