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 prestacio-
nes 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).

Figura 3: jerarquı́a de cachés

3.3. Configuración
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á blo-
queando 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 si-
guiente 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 configu-
rará 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/