Proxy Squid

Proxy
La palabra proxy se usa en muchas situaciones en donde tiene sentido un intermediario:
• El uso más común es el de servidor proxy, que es un ordenador que intercepta

las conexiones de red que un cliente hace a un servidor de destino.
o De ellos, el más famoso es el servidor proxy de web (comúnmente
conocido solamente como "proxy"). Intercepta la navegación de los
clientes por páginas web, por varios motivos posibles: seguridad,
rendimiento, anonimato, etc.
o También existen proxies para otros protocolos, como el proxy de FTP.
o El proxy ARP puede hacer de enrutador en una red, ya que hace de
intermediario entre ordenadores.
• Proxy (patrón de diseño) también es un patrón de diseño (programación) con el
mismo esquema que el proxy de red.
• Un componente hardware también puede actuar como intermediario para otros
(por ejemplo, un teclado USB al que se le pueden conectar más dispositivos
USB).
• Fuera de la informática, un proxy puede ser una persona autorizada para actuar
en representación de otra persona; por ejemplo, alguien a quien le han delegado
el derecho a voto.
• Una guerra proxy es una en la que las dos potencias usan a terceros para el
enfrentamiento directo.
Como se ve, proxy tiene un significado muy general, aunque siempre es sinónimo de
intermediario. También se puede traducir por delegado o apoderado (el que tiene el
poder).
Ventajas
En general (no sólo en informática), los proxies hacen posibles varias cosas nuevas:
• Control. Sólo el intermediario hace el trabajo real, por tanto se pueden limitar y
restringir los derechos de los usuarios, y dar permisos sólo al proxy.
• Ahorro. Por tanto, sólo uno de los usuarios (el proxy) ha de estar equipado para
hacer el trabajo real.
• Velocidad. Si varios clientes van a pedir el mismo recurso, el proxy puede hacer
caché: guardar la respuesta de una petición para darla directamente cuando otro
usuario la pida. Así no tiene que volver a contactar con el destino, y acaba más
rápido.
• Filtrado. El proxy puede negarse a responder algunas peticiones si detecta que
están prohibidas.
• Modificación. Como intermediario que es, un proxy puede falsificar
información, o modificarla siguiendo un algoritmo.
• Anonimato. Si todos los usuarios se identifican como uno sólo, es difícil que el
recurso accedido pueda diferenciarlos. Pero esto puede ser malo, por ejemplo
cuando hay que hacer necesariamente la identificación.
Desventajas
En general (no sólo en informática), el uso de un intermediario puede provocar:
• Abuso. Al estar dispuesto a recibir peticiones de muchos usuarios y

responderlas, es posible que haga algún trabajo que no toque. Por tanto, ha de
controlar quién tiene acceso y quién no a sus servicios, cosa que normalmente es
muy difícil.
• Carga. Un proxy ha de hacer el trabajo de muchos usuarios.
• Intromisión. Es un paso más entre origen y destino, y algunos usuarios pueden
no querer pasar por el proxy. Y menos si hace de caché y guarda copias de los
datos.
• Incoherencia. Si hace de caché, es posible que se equivoque y dé una respuesta
antigua cuando hay una más reciente en el recurso de destino.
• Irregularidad. El hecho de que el proxy represente a más de un usuario da
problemas en muchos escenarios, en concreto los que presuponen una
comunicación directa entre 1 emisor y 1 receptor (como TCP/IP).
Funcionamiento
A continuación se hablará del servidor proxy de web, el más común.
Un proxy permite a otros equipos conectarse a una red de forma indirecta a través de él.
Cuando un equipo de la red desea acceder a una información o recurso, es realmente el
proxy quien realiza la comunicación y a continuación traslada el resultado al equipo
inicial. En unos casos esto se hace así porque no es posible la comunicación directa y en
otros casos porque el proxy añade una funcionalidad adicional, como puede ser la de
mantener los resultados obtenidos (p.ej.: una página Web) en una cache que permita
acelerar sucesivas consultas coincidentes. Con esta denominación general de proxy se
agrupan diversas técnicas.
Proxy de web / Proxy cache de web

Se trata de un proxy para una aplicación específica: el acceso a la web. Aparte de la
utilidad general de un proxy, proporciona una cache para las páginas web y los
contenidos descargados, que es compartida por todos los equipos de la red, con la
consiguiente mejora en los tiempos de acceso para consultas coincidentes. Al mismo
tiempo libera la carga de los enlaces hacia Internet.
Funcionamiento
1. El cliente realiza una petición (p.e. mediante un navegador web) de un recurso

de Internet (una página web o cualquier otro archivo) especificado por una URL.
2. Cuando el proxy caché recibe la petición, busca la URL resultante en su caché
local. Si la encuentra, devuelve el documento inmediatamente, si no es así, lo
captura del servidor remoto, lo devuelve al que lo pidió y guarda una copia en su
caché para futuras peticiones.
El caché utiliza normalmente un algoritmo para determinar cuándo un documento está

obsoleto y debe ser eliminado de la caché, dependiendo de su antigüedad, tamaño e
histórico de acceso. Dos de esos algoritmos básicos son el LRU (el usado menos
recientemente, en inglés "Least Recently Used") y el LFU (el usado menos
frecuentemente, "Least Frequently Used").
Los proxies web también pueden filtrar el contenido de las páginas Web servidas.
Algunas aplicaciones que intentan bloquear contenido Web ofensivo están
implementadas como proxies Web. Otros tipos de proxy cambian el formato de las
páginas web para un propósito o una audiencia específicos, para, por ejemplo, mostrar
una página en un teléfono móvil o una PDA. Algunos operadores de red también tienen
proxies para interceptar virus y otros contenidos hostiles servidos por páginas Web
remotas.
Ejemplo
Un cliente de un ISP manda una petición a Google la petición llega en un inicio
al servidor Proxy que tiene este ISP, no va directamente a la dirección IP del
dominio de Google. Esta página concreta suele ser muy solicitada por un alto
porcentaje de usuarios, por lo tanto el ISP la retiene en su Proxy por un cierto
tiempo y crea una respuesta mucho menor en tiempo. Cuando el usuario crea
una búsqueda el servidor Proxy ya no es utilizado y el ISP envía su petición y el
cliente recibe su respuesta ahora sí desde Google.
Otros usos
Como método extra y de ayuda en las descargas mediante aplicaciones P2P; el
cual es usado en Lphant y algunos Mods del Emule. (ver Webcaché en
aplicaciones P2P).
Ventajas
• Ahorro de Tráfico: Las peticiones de páginas Web se hacen al servidor Proxy y

no a Internet directamente. Por lo tanto, aligera el tráfico en la red y descarga los
servidores destino, a los que llegan menos peticiones.
• Velocidad en Tiempo de respuesta: El servidor Proxy crea un caché que evita
transferencias idénticas de la información entre servidores durante un tiempo
(configurado por el administrador) así que el usuario recibe una respuesta más
rápida.
• Demanda a Usuarios: Puede cubrir a un gran número de usuarios, para
solicitar, a través de él, los contenidos Web.
• Filtrado de contenidos: El servidor proxy puede hacer un filtrado de páginas o
contenidos basándose en criterios de restricción establecidos por el
administrador dependiendo valores y características de lo que no se permite,
creando una restricción cuando sea necesario.
• Modificación de contenidos: Basándose en la misma función del filtrado, y
llamado Privoxy, tiene el objetivo de proteger la privacidad en Internet, puede
ser configurado para bloquear direcciones y Cookies por expresiones regulares y
modifica en la petición el contenido.
Desventajas
Las páginas mostradas pueden no estar actualizadas si éstas han sido

modificadas desde la última carga que realizó el proxy caché.
Un diseñador de páginas web puede indicar en el contenido de su web que los

navegadores no hagan una caché de sus páginas, pero este método no funciona
habitualmente para un proxy.
• El hecho de acceder a Internet a través de un Proxy, en vez de mediante

conexión directa, impide realizar operaciones avanzadas a través de algunos
puertos o protocolos.
• Almacenar las páginas y objetos que los usuarios solicitan puede suponer una
violación de la intimidad para algunas personas.
Proxies transparentes
Muchas organizaciones (incluyendo empresas, colegios y familias) usan los proxies

para reforzar las políticas de uso de la red o para proporcionar seguridad y servicios de
caché. Normalmente, un proxy Web o NAT no es transparente a la aplicación cliente:
debe ser configurada para usar el proxy, manualmente. Por lo tanto, el usuario puede
evadir el proxy cambiando simplemente la configuración.
Un proxy transparente combina un servidor proxy con NAT de manera que las
conexiones son enrutadas dentro del proxy sin configuración por parte del cliente, y
habitualmente sin que el propio cliente conozca de su existencia. Este es el tipo de
proxy que utilizan los proveedores de servicios de internet (ISP). En España, la
compañía más expandida en cuanto a ADSL se refiere, ISP Telefónica, dejó de utilizar
proxy transparente con sus clientes a partir de Febrero de 2006.
Reverse Proxy
Un reverse proxy es un servidor proxy instalado en el domicilio de uno o más servidores

web. Todo el tráfico entrante de Internet y con el destino de uno de esos servidores web
pasa a través del servidor proxy. Hay varias razones para instalar un "reverse proxy":
• Seguridad: el servidor proxy es una capa adicional de defensa y por lo tanto

protege los servidores web.
• Cifrado / Aceleración SSL: cuando se crea un sitio web seguro, habitualmente el
cifrado SSL no la hace el mismo servidor web, sino que es realizada por el
"reverse proxy", el cual está equipado con un hardware de aceleración SSL
(Security Sockets Layer).
• Distribución de Carga: el "reverse proxy" puede distribuir la carga entre varios
servidores web. En ese caso, el "reverse proxy" puede necesitar reescribir las
URL de cada página web (traducción de la URL externa a la URL interna
correspondiente, según en qué servidor se encuentre la información solicitada).
• Caché de contenido estático: Un "reverse proxy" puede descargar los servidores
web almacenando contenido estático como imágenes u otro contenido gráfico.
Proxy NAT (Network Address Translation) / Enmascaramiento
Otro mecanismo para hacer de intermediario en una red es el NAT.
La traducción de direcciones de red (NAT, Network Address Translation) también es

conocida como enmascaramiento de IPs. Es una técnica mediante la cual las direcciones
fuente o destino de los paquetes IP son reescritas, sustituidas por otras (de ahí el
"enmascaramiento").
Esto es lo que ocurre cuando varios usuarios comparten una única conexión a Internet.
Se dispone de una única dirección IP pública, que tiene que ser compartida. Dentro de la
red de área local (LAN) los equipos emplean direcciones IP reservadas para uso privado
y será el proxy el encargado de traducir las direcciones privadas a esa única dirección
pública para realizar las peticiones, así como de distribuir las páginas recibidas a aquel
usuario interno que la solicitó. Estas direcciones privadas se suelen elegir en rangos
prohibidos para su uso en Internet como 192.168.x.x, 10.x.x.x, 172.16.x.x y 172.31.x.x
Esta situación es muy común en empresas y domicilios con varios ordenadores en red y
un acceso externo a Internet. El acceso a Internet mediante NAT proporciona una cierta
seguridad, puesto que en realidad no hay conexión directa entre el exterior y la red
privada, y así nuestros equipos no están expuestos a ataques directos desde el exterior.
Mediante NAT también se puede permitir un acceso limitado desde el exterior, y hacer
que las peticiones que llegan al proxy sean dirigidas a una máquina concreta que haya
sido determinada para tal fin en el propio proxy.
La función de NAT reside en los Cortafuegos y resulta muy cómoda porque no necesita
de ninguna configuración especial en los equipos de la red privada que pueden acceder a
través de él como si fuera un mero encaminador.
Proxy Abierto
Este tipo de proxy que acepta peticiones desde cualquier ordenador, esté o no conectado
a su red.
En esta configuración el proxy ejecutará cualquier petición de cualquier ordenador que

pueda conectarse a él, realizándola como si fuera una petición del proxy. Por lo que
permite que este tipo de proxy se use como pasarela para el envío masivo de correos de
spam. Un proxy se usa, normalmente, para almacenar y redirigir servicios como el DNS
o la navegación Web, mediante el cacheo de peticiones en el servidor proxy, lo que
mejora la velocidad general de los usuarios. Este uso es muy beneficioso, pero al
aplicarle una configuración "abierta" a todo internet, se convierte en una herramienta
para su uso indebido.
Debido a lo anterior, muchos servidores, como los de IRC, o correo electrónicos,

deniegan el acceso a estos proxys a sus servicios, usando normalmente listas negras
("BlackList").
SQUID
Squid es un Servidor Intermediario (Proxy) de alto desempeño que se ha venido

desarrollando desde hace varios años y es hoy en día un muy popular y ampliamente
utilizado entre los sistemas operativos como GNU/Linux y derivados de Unix®. Es muy
confiable, robusto y versátil y se distribuye bajo los términos de la Licencia Pública
General GNU (GNU/GPL). Siendo sustento lógico libre, está disponible el código
fuente para quien así lo requiera.
Entre otras cosas, 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, WWCP, aceleración HTTP, caché de consultas
DNS y otras muchas más como filtración de contenido y control de acceso por IP y por
usuario.
Squid consiste de un programa principal como servidor, un programa para búsqueda en

servidores DNS, programas opcionales para reescribir solicitudes y realizar
autenticación y algunas herramientas para administración y y herramientas para clientes.
Al iniciar Squid da origen a un número configurable (5, de modo predefinido a través
del parámetro dns_children) de procesos de búsqueda en servidores DNS, cada uno de
los cuales realiza una búsqueda única en servidores DNS, reduciendo la cantidad de
tiempo de espera para las búsquedas en servidores DNS.
NOTA ESPECIAL: Squid no debe ser utilizado como Servidor Intermediario

(Proxy) para protocolos como SMTP, POP3, TELNET, SSH, IRC, etc. Si se requiere
intermediar para cualquier protocolo distinto a HTTP, HTTPS, FTP, GOPHER y
WAIS se requerirá implementar obligatoriamente un enmascaramiento de IP o NAT
(Network Address Translation) o bien hacer uso de un servidor SOCKS como Dante
(http://www.inet.no/dante/).
Algoritmos de caché utilizados por Squid.
A través de un parámetro (cache_replacement_policy) Squid incluye soporte para los

siguientes algoritmos para el caché:
• LRU Acrónimo de Least Recently Used, que traduce como Menos

Recientemente Utilizado. En este algoritmo los objetos que
no han sido accedidos en mucho tiempo son eliminados
primero, manteniendo siempre en el caché a los objetos más
recientemente solicitados. Ésta política es la utilizada por
Squid de modo predefinido.
• LFUDA Acrónimo de Least Frequently Used with Dynamic Aging,

que se traduce como Menos Frecuentemente Utilizado con
Envejecimiento Dinámico. En este algoritmo los objetos más
solicitados permanecen en el caché sin importar su tamaño
optimizando la eficiencia (hit rate) por octetos (Bytes) a
expensas de la eficiencia misma, 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.
• GDSF Acrónimo de GreedyDual Size Frequency, que se traduce

como Frecuencia de tamaño GreedyDual (codicioso dual),
que es el algoritmo sobre el cual se basa GDSF. Optimiza la
eficiencia (hit rate) por objeto manteniendo en el caché los
objetos pequeños más frecuentemente solicitados de modo que
hay mejores posibilidades de lograr respuesta a una solicitud
(hit). Tiene una eficiencia por octetos (Bytes) menor que el
algoritmo LFUDA debido a que descarta del caché objetos
grandes que sean solicitado con frecuencia.
Sustento lógico necesario.
Para poder llevar al cabo los procedimientos descritos en este manual y documentos
relacionados, usted necesitará tener instalado al menos lo siguiente:
• Al menos squid-2.5.STABLE6
• httpd-2.0.x (Apache), como auxiliar de caché con aceleración.
• Todos los parches de seguridad disponibles para la versión del sistema
operativo que esté utilizando. No es conveniente utilizar un sistema con
posibles vulnerabilidades como Servidor Intermediario.
Debe tomarse en consideración que, de ser posible, se debe utilizar siempre las
versiones estables más recientes de todo sustento lógico que vaya a ser instalado para
realizar los procedimientos descritos en este manual, a fin de contar con los parches de
seguridad necesarios. Ninguna versión de Squid anterior a la 2.5.STABLE6 se
considera como apropiada debido a fallas de seguridad de gran importancia.
Squid no se instala de manera predeterminada a menos que especifique lo contrario

durante la instalación del sistema operativo, sin embargo viene incluido en casi todas las
distribuciones actuales. El procedimiento de instalación es exactamente el mismo que
con cualquier otro sustento lógico.
Instalación a través de yum.
Si cuenta con un sistema con CentOS o White Box Enterprise Linux 3 o versiones
posteriores, utilice lo siguiente y se instalará todo lo necesario junto con sus
dependencias:
yum -y install squid httpd
Instalación a través de up2date.
Si cuenta con un sistema con Red Hat™ Enterprise Linux 3 o versiones posteriores,
utilice lo siguiente y se instalará todo lo necesario junto con sus dependencias:
up2date -i squid httpd
Otros componentes necesarios.
El mandato iptables se utilizará para generar las reglas necesarias para el guión de
Enmascaramiento de IP. Se instala de modo predefinido en todas las distribuciones
actuales que utilicen núcleo (kernel) versiones 2.4 y 2.6.
Es importante tener actualizado el núcleo del sistema operativo por diversas cuestiones
de seguridad. No es recomendable utilizar versiones del kernel anteriores a la 2.4.21.
Actualice el núcleo a la versión más reciente disponible para su distribución.
Si cuenta con un sistema con CentOS o White Box Enterprise Linux 3 o versiones
posteriores, utilice lo siguiente para actualizar el núcleo del sistema operativo e
iptables, si acaso fuera necesario:
yum -y update kernel iptables
Si cuenta con un sistema con Red Hat™ Enterprise Linux 3 o versiones posteriores,
utilice lo siguiente para actualizar el núcleo del sistema operativo, e iptables si acaso
fuera necesario:
up2date -u kernel iptables
Antes de continuar.
Tenga en cuenta que este manual ha sido comprobado varias veces y ha funcionado en
todos los casos y si algo no funciona solo significa que usted no lo leyó a detalle y no
siguió correctamente las indicaciones.
Evite dejar espacios vacíos en lugares indebidos. El siguiente es un ejemplo de como

no se debe habilitar un parámetro.
Mal
# Opción incorrectamente habilitada
http_port 3128
El siguiente es un ejemplo de como si se debe habilitar un parámetro.
Bien
# Opción correctamente habilitada
http_port 3128
Configuración básica.
Squid utiliza el fichero de configuración localizado en /etc/squid/squid.conf, y podrá

trabajar sobre este utilizando su editor de texto simple preferido. Existen un gran
número de parámetros, de los cuales recomendamos configurar los siguientes:
• http_port
• cache_dir
• Al menos una Lista de Control de Acceso
• Al menos una Regla de Control de Acceso
• httpd_accel_host
• httpd_accel_port
• httpd_accel_with_proxy
Parámetro http_port: ¿Que puerto utilizar para Squid?
De acuerdo a las asignaciones hechas por IANA y continuadas por la ICANN desde el
21 de marzo de 2001, los Puertos Registrados (rango desde 1024 hasta 49151)
recomendados para Servidores Intermediarios (Proxies) pueden ser el 3128 y 8080 a
través de TCP.
De modo predefinido Squid utilizará el puerto 3128 para atender peticiones, sin
embargo se puede especificar que lo haga en cualquier otro puerto disponible o bien que
lo haga en varios puertos disponibles a la vez.
En el caso de un Servidor Intermediario (Proxy) Transparente, regularmente se

utilizará el puerto 80 o el 8000 y se valdrá del re-direccionamiento de peticiones de
modo tal que no habrá necesidad alguna de modificar la configuración de los clientes
HTTP para utilizar el Servidor Intermediario (Proxy). Bastará con utilizar como
puerta de enlace al servidor. Es importante recordar que los Servidores HTTP, como
Apache, también utilizan dicho puerto, por lo que será necesario volver a configurar el
servidor HTTP para utilizar otro puerto disponible, o bien desinstalar o desactivar el
servidor HTTP.
Hoy en día puede no ser del todo práctico el utilizar un Servidor Intermediario
(Proxy) Transparente, a menos que se trate de un servicio de Café Internet u oficina
pequeña, siendo que uno de los principales problemas con los que lidian los
administradores es el mal uso y/o abuso del acceso a Internet por parte del personal. Es
por esto que puede resultar más conveniente configurar un Servidor Intermediario
(Proxy) con restricciones por clave de acceso, lo cual no puede hacerse con un Servidor
Intermediario (Proxy) Transparente, debido a que se requiere un diálogo de nombre
de usuario y clave de acceso.
Regularmente algunos programas utilizados comúnmente por los usuarios suelen traer
de modo predefinido el puerto 8080 (servicio de cacheo WWW) para utilizarse al
configurar que Servidor Intermediario (Proxy) utilizar. Si queremos aprovechar esto
en nuestro favor y ahorrarnos el tener que dar explicaciones innecesarias al usuario,
podemos especificar que Squid escuche peticiones en dicho puerto también. Siendo así
localice la sección de definición de http_port, y especifique:
#
# You may specify multiple socket addresses on multiple
lines.
#
# Default: http_port 3128
http_port 3128
http_port 8080
Si desea incrementar la seguridad, puede vincularse el servicio a una IP que solo se
pueda acceder desde la red local. Considerando que el servidor utilizado posee una IP
192.168.1.254, puede hacerse lo siguiente:
#
# You may specify multiple socket addresses on multiple
lines.
#
# Default: http_port 3128
http_port 192.168.1.254:3128
http_port 192.168.1.254:8080
Parámetro cache_mem.
El parámetro cache_mem establece la cantidad ideal de memoria para lo siguiente:
• Objetos en tránsito.
• Objetos frecuentemente utilizados (Hot).
• Objetos negativamente almacenados en el caché.
Los datos de estos objetos se almacenan en bloques de 4 Kb. El parámetro cache_mem

especifica un límite máximo en el tamaño total de bloques acomodados, donde los
objetos en tránsito tienen mayor prioridad. Sin embargo los objetos Hot y aquellos
negativamente almacenados en el caché podrán utilizar la memoria no utilizada hasta
que esta sea requerida. De ser necesario, si un objeto en tránsito es mayor a la cantidad
de memoria especificada, Squid excederá lo que sea necesario para satisfacer la
petición.
De modo predefinido se establecen 8 MB. Puede especificarse una cantidad mayor si así
se considera necesario, dependiendo esto de los hábitos de los usuarios o necesidades
establecidas por el administrador.
Si se posee un servidor con al menos 128 MB de RAM, establezca 16 MB como valor

para este parámetro:
cache_mem 16 MB
Parámetro cache_dir: ¿Cuanto desea almacenar de Internet en el

disco duro?
Este parámetro se utiliza para establecer que tamaño se desea que tenga el caché en el
disco duro para Squid. Para entender esto un poco mejor, responda a esta pregunta:
¿Cuanto desea almacenar de Internet en el disco duro? De modo predefinido Squid
utilizará un caché de 100 MB, de modo tal que encontrará la siguiente línea:
cache_dir ufs /var/spool/squid 100 16 256
Se puede incrementar el tamaño del caché hasta donde lo desee el administrador.

Mientras más grande sea el caché, más objetos se almacenarán en éste y por lo tanto se
utilizará menos el ancho de banda. La siguiente línea establece un caché de 700 MB:
cache_dir ufs /var/spool/squid 700 16 256
Los números 16 y 256 significan que el directorio del caché contendrá 16 directorios
subordinados con 256 niveles cada uno. No modifique esto números, no hay
necesidad de hacerlo.
Es muy importante considerar que si se especifica un determinado tamaño de caché y

éste excede al espacio real disponible en el disco duro, Squid se bloqueará
inevitablemente. Sea cauteloso con el tamaño de caché especificado.
Parámetro ftp_user.
Al acceder a un servidor FTP de manera anónima, de modo predefinido Squid enviará

como clave de acceso Squid@. Si se desea que el acceso anónimo a los servidores FTP
sea más informativo, o bien si se desea acceder a servidores FTP que validan la
autenticidad de la dirección de correo especificada como clave de acceso, puede
especificarse la dirección de correo electrónico que uno considere pertinente.
ftp_user proxy@su-dominio.net
Controles de acceso.
Es necesario establecer Listas de Control de Acceso que definan una red o bien ciertas
máquinas en particular. A cada lista se le asignará una Regla de Control de Acceso que
permitirá o denegará el acceso a Squid. Procedamos a entender como definir unas y
otras.
Listas de control de acceso.
Regularmente una lista de control de acceso se establece con la siguiente sintaxis:
acl [nombre de la lista] src [lo que compone a la lista]
Si se desea establecer una lista de control de acceso que abarque a toda la red local,
basta definir la IP correspondiente a la red y la máscara de la sub-red. Por ejemplo, si se
tiene una red donde las máquinas tienen direcciones IP 192.168.1.n con máscara de sub-
red 255.255.255.0, podemos utilizar lo siguiente:
acl miredlocal src 192.168.1.0/255.255.255.0
También puede definirse una Lista de Control de Acceso especificando un fichero

localizado en cualquier parte del disco duro, y la cual contiene una lista de direcciones
IP. Ejemplo:
acl permitidos src "/etc/squid/permitidos"
El fichero /etc/squid/permitidos contendría algo como siguiente:
192.168.1.1
192.168.1.2
192.168.1.3
192.168.1.15
192.168.1.16
192.168.1.20
192.168.1.40
Lo anterior estaría definiendo que la Lista de Control de Acceso denominada

permitidos estaría compuesta por las direcciones IP incluidas en el fichero
/etc/squid/permitidos.
Reglas de Control de Acceso.
Estas definen si se permite o no el acceso hacia Squid. Se aplican a las Listas de

Control de Acceso. Deben colocarse en la sección de reglas de control de acceso
definidas por el administrador, es decir, a partir de donde se localiza la siguiente
leyenda:
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR
CLIENTS
#
La sintaxis básica es la siguiente:
http_access [deny o allow] [lista de control de acceso]
En el siguiente ejemplo consideramos una regla que establece acceso permitido a Squid
a la Lista de Control de Acceso denominada permitidos:
http_access allow permitidos
También pueden definirse reglas valiéndose de la expresión !, la cual significa no.

Pueden definirse, por ejemplo, dos listas de control de acceso, una denominada lista1 y
otra denominada lista2, en la misma regla de control de acceso, en donde se asigna una
expresión a una de estas. La siguiente establece que se permite el acceso a Squid a lo
que comprenda lista1 excepto aquello que comprenda lista2:
http_access allow lista1 !lista2
Este tipo de reglas son útiles cuando se tiene un gran grupo de IP dentro de un rango de
red al que se debe permitir acceso, y otro grupo dentro de la misma red al que se debe
denegar el acceso.
Aplicando Listas y Reglas de control de acceso.
Una vez comprendido el funcionamiento de la Listas y las Regla de Control de Acceso,

procederemos a determinar cuales utilizar para nuestra configuración.
Caso 1.
Considerando como ejemplo que se dispone de una red 192.168.1.0/255.255.255.0, si se

desea definir toda la red local, utilizaremos la siguiente línea en la sección de Listas de
Control de Acceso:
acl todalared src 192.168.1.0/255.255.255.0
Habiendo hecho lo anterior, la sección de listas de control de acceso debe quedar más o
menos del siguiente modo:
Listas de Control de Acceso: definición de una red local completa
#
# Recommended minimum configuration:
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 todalared src 192.168.1.0/255.255.255.0
A continuación procedemos a aplicar la regla de control de acceso:
http_access allow todalared
Habiendo hecho lo anterior, la zona de reglas de control de acceso debería quedar más o
menos de este modo:
Reglas de control de acceso: Acceso a una Lista de Control de Acceso.
#
CLIENTS
#
http_access allow localhost
http_access allow todalared
http_access deny all
La regla http_access allow todalared permite el acceso a Squid a la Lista de Control

de Acceso denominada todalared, la cual está conformada por
192.168.1.0/255.255.255.0. Esto significa que cualquier máquina desde 192.168.1.1
hasta 192.168.1.254 podrá acceder a Squid.
Caso 2.
Si solo se desea permitir el acceso a Squid a ciertas direcciones IP de la red local,

deberemos crear un fichero que contenga dicha lista. Genere el fichero
/etc/squid/listas/redlocal, dentro del cual se incluirán solo aquellas direcciones IP que
desea confirmen la Lista de Control de acceso. Ejemplo:
192.168.1.1
192.168.1.2
192.168.1.3
192.168.1.15
192.168.1.16
192.168.1.20
192.168.1.40
Denominaremos a esta lista de control de acceso como redlocal:
acl redlocal src "/etc/squid/listas/redlocal"
Habiendo hecho lo anterior, la sección de listas de control de acceso debe quedar más o
menos del siguiente modo:
Listas de Control de Acceso: definición de una red local completa
#
acl all src 0.0.0.0/0.0.0.0
acl redlocal src "/etc/squid/listas/redlocal"
A continuación procedemos a aplicar la regla de control de acceso:
http_access allow redlocal
menos de este modo:
Reglas de control de acceso: Acceso a una Lista de Control de Acceso.
#
CLIENTS
#
La regla http_access allow redlocal permite el acceso a Squid a la Lista de Control

de Acceso denominada redlocal, la cual está conformada por las direcciones IP
especificadas en el fichero /etc/squid/listas/redlocal. Esto significa que cualquier
máquina no incluida en /etc/squid/listas/redlocal no tendrá acceso a Squid.
Parámetro chache_mgr.
De modo predefinido, si algo ocurre con el caché, como por ejemplo que muera el
procesos, se enviará un mensaje de aviso a la cuenta webmaster del servidor. Puede
especificarse una distinta si acaso se considera conveniente.
cache_mgr joseperez@midominio.net
Parámetro cache_peer: caches padres y hermanos.
El parámetro cache_peer se utiliza para especificar otros Servidores Intermediarios

(Proxies) con caché en una jerarquía como padres o como hermanos. Es decir, definir
si hay un Servidor Intermediario (Proxy) adelante o en paralelo. La sintaxis básica es
la siguiente:
cache_peer servidor tipo http_port icp_port opciones
Ejemplo: Si su caché va a estar trabajando detrás de otro servidor cache, es decir un

caché padre, y considerando que el caché padre tiene una IP 192.168.1.1, escuchando
peticiones HTTP en el puerto 8080 y peticiones ICP en puerto 3130 (puerto utilizado
de modo predefinido por Squid) ,especificando que no se almacenen en caché los
objetos que ya están presentes en el caché del Servidor Intermediario (Proxy) padre,
utilice la siguiente línea:
cache_peer 192.168.1.1 parent 8080 3130 proxy-only
Cuando se trabaja en redes muy grandes donde existen varios Servidores Intermediarios
(Proxy) haciendo caché de contenido de Internet, es una buena idea hacer trabajar todos
los caché entre si. Configurar caches vecinos como sibling (hermanos) tiene como
beneficio el que se consultarán estos caches localizados en la red local antes de acceder
hacia Internet y consumir ancho de banda para acceder hacia un objeto que ya podría
estar presente en otro caché vecino.
Ejemplo: Si su caché va a estar trabajando en paralelo junto con otros caches, es decir
caches hermanos, y considerando los caches tienen IP 10.1.0.1, 10.2.0.1 y 10.3.0.1,
todos escuchando peticiones HTTP en el puerto 8080 y peticiones ICP en puerto 3130,
especificando que no se almacenen en caché los objetos que ya están presentes en los
caches hermanos, utilice las siguientes líneas:
cache_peer 10.1.0.1 sibling 8080 3130 proxy-only

Pueden hacerse combinaciones que de manera tal que se podrían tener caches padres y
hermanos trabajando en conjunto en una red local. Ejemplo:
cache_peer 10.0.0.1 parent 8080 3130 proxy-only

Caché con aceleración.
Cuando un usuario hace petición hacia un objeto en Internet, este es almacenado en el

caché de Squid. Si otro usuario hace petición hacia el mismo objeto, y este no ha
sufrido modificación alguna desde que lo accedió el usuario anterior, Squid mostrará el
que ya se encuentra en el caché en lugar de volver a descargarlo desde Internet.
Esta función permite navegar rápidamente cuando los objetos ya están en el caché de
Squid y además optimiza enormemente la utilización del ancho de banda.
La configuración de Squid como Servidor Intermediario (Proxy) Transparente solo

requiere complementarse utilizando una regla de iptables que se encargará de re-
direccionar peticiones haciéndolas pasar por el puerto 8080. La regla de iptables
necesaria se describe más adelante en este documento.
Proxy Acelerado: Opciones para Servidor Intermediario (Proxy) en

modo convencional.
En la sección HTTPD-ACCELERATOR OPTIONS deben habilitarse los siguientes

parámetros:
httpd_accel_host virtual
httpd_accel_port 0
httpd_accel_with_proxy on
Proxy Acelerado: Opciones para Servidor Intermediario (Proxy)

Transparente.
Si se trata de un Servidor Intermediario (Proxy) transparente, deben utilizarse las

siguientes opciones, considerando que se hará uso del caché de un servidor HTTP
(Apache) como auxiliar:
# Debe especificarse la IP de cualquier servidor HTTP en la

# red local o bien el valor virtual
httpd_accel_host 192.168.1.254
httpd_accel_port 80
httpd_accel_uses_host_header on
Proxy Acelerado: Opciones para Servidor Intermediario (Proxy)

Transparente para redes con Internet Exlorer 5.5 y versiones
anteriores.
Si va a utilizar Internet Explorer 5.5 y versiones anteriores con un Servidor

Intermediario (Proxy) transparente, es importante recuerde que dichas versiones tiene
un pésimo soporte con los Servidores Intermediarios (Proxies) transparentes
imposibilitando por completo la capacidad de refrescar contenido. Si se utiliza el
parámetro ie_refresh con valor on puede hacer que se verifique en los servidores de
origen para nuevo contenido para todas las peticiones IMS-REFRESH provenientes de
Internet Explorer 5.5 y versiones anteriores.
# Debe especificarse la IP de cualquier servidor HTTP en la

# red local
httpd_accel_host 192.168.1.254
httpd_accel_port 80
httpd_accel_uses_host_header on
ie_refresh on
Lo más conveniente es actualizar hacia Internet Explorer 6.x o definitivamente optar por
otras alternativas. Mozilla es en un conjunto de aplicaciones para Internet, o bien
Firefox, que es probablemente el mejor navegador que existe en el mercado. Firefox es
un navegador muy ligero y que cumple con los estándares, y está disponible para
Windows, Linux, Mac OS X y otros sistemas operativos.
Estableciendo el idioma de los mensajes mostrados por de

Squid hacia el usuario.
Squid incluye traducción a distintos idiomas de las distintas páginas de error e

informativas que son desplegadas en un momento dado durante su operación. Dichas
traducciones se pueden encontrar en /usr/share/squid/errors/. Para poder hacer uso de
las páginas de error traducidas al español, es necesario cambiar un enlace simbólico
localizado en /etc/squid/errors para que apunte hacia /usr/share/squid/errors/Spanish
en lugar de hacerlo hacia /usr/share/squid/errors/English.
Elimine primero el enlace simbólico actual:
rm -f /etc/squid/errors
Coloque un nuevo enlace simbólico apuntando hacia el directorio con los ficheros
correspondientes a los errores traducidos al español.
ln -s /usr/share/squid/errors/Spanish /etc/squid/errors
Nota: Este enlace simbólico debe verificarse, y regenerarse de ser necesario, cada
vez que se actualizado Squid ya sea a través de yum, up2date o manualmente con
el mandato rpm.
Iniciando, reiniciando y añadiendo el servicio al arranque del

sistema.
Una vez terminada la configuración, ejecute el siguiente mandato para iniciar por
primera vez Squid:
service squid start
Si necesita reiniciar para probar cambios hechos en la configuración, utilice lo

siguiente:
service squid restart
Si desea que Squid inicie de manera automática la próxima vez que inicie el sistema,
utilice lo siguiente:
chkconfig squid on
Lo anterior habilitará a Squid en todos los niveles de corrida.

Depuración de errores
Cualquier error al inicio de Squid solo significa que hubo errores de sintaxis, errores de
dedo o bien se están citando incorrectamente las rutas hacia los ficheros de las Listas de
Control de Acceso.
Puede realizar diagnóstico de problemas indicándole a Squid que vuelva a leer

configuración, lo cual devolverá los errores que existan en el fichero
/etc/squid/squid.conf.
service squid reload
Cuando se trata de errores graves que no permiten iniciar el servicio, puede examinarse
el contenido del fichero /var/log/squid/squid.out con el mandato less, more o cualquier
otro visor de texto:
less /var/log/squid/squid.out
Ajustes para el muro corta-fuegos.
Si se tiene poca experiencia con guiones de cortafuegos a través de iptables, sugerimos

utilizar Firestarter. éste permite configurar fácilmente tanto el enmascaramiento de IP
como el muro corta-fuegos. Si se tiene un poco más de experiencia, recomendamos
utilizar Shorewall para el mismo fin puesto que se trata de una herramienta más robusta
y completa.
• Firestarter: http://www.fs-security.com/
• Shorewall: http://www.shorewall.net/
Re-direccionamiento de peticiones a través de iptables y Firestarter.
En un momento dado se requerirá tener salida transparente hacia Internet para ciertos
servicios, pero al mismo tiempo se necesitará re-direccionar peticiones hacia servicio
HTTP para pasar a través del el puerto donde escucha peticiones Squid (8080), de
modo que no haya salida alguna hacia alguna hacia servidores HTTP en el exterior sin
que ésta pase antes por Squid. No se puede hacer Servidor Intermediario (Proxy)
Transparente para los protocolos HTTPS, FTP, GOPHER ni WAIS, por lo que dichos
protocolos tendrán que ser filtrados a través del NAT.
El re-direccionamiento lo hacemos a través de iptables. Considerando para este ejemplo

que la red local se accede a través de una interfaz eth0, el siguiente esquema ejemplifica
un re-direccionamiento:
/sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport

80 -j REDIRECT --to-port 8080
Lo anterior, que requiere un guión de cortafuegos funcional en un sistema con dos

interfaces de red, hace que cualquier petición hacia el puerto 80 (servicio HTTP) hecha
desde la red local hacia el exterior, se re-direccionará hacia el puerto 8080 del servidor.
Utilizando Firestarter, la regla anteriormente descrita se añade en el fichero
/etc/firestarter/user-post.
Re-direccionamiento de peticiones a través de la opción REDIRECT

en Shorewall.
La acción REDIRECT en Shorewall permite redirigir peticiones hacia protocolo

HTTP para hacerlas pasar a través de Squid. En el siguiente ejemplo las peticiones
hechas desde la zona que corresponde a la red local serán redirigidas hacia el puerto
8080 del cortafuegos, en donde está configurado Squid configurado como Servidores
Intermediario (Proxy) transparente.
#ACTION SOURCE DEST PROTO DEST

REDIRECT loc 8080 tcp 80
Cómo configurar Squid: Restricción de acceso a Sitio de Red.
Introducción.
Denegar el acceso a ciertos Sitios de Red permite hacer un uso más racional del ancho
de banda con el que se dispone. El funcionamiento es verdaderamente simple, y consiste
en denegar el acceso a nombres de dominio o direcciones Web que contengan patrones
en común.
Este manual considera que usted ya ha leído previamente, a detalle y en su totalidad el

manual "Como configurar Squid: Servidor Proxy" y que ha configurado exitosamente
Squid como servidor proxy.
Software requerido.
Para poder llevar la cabo los procedimientos descritos en este manual y documentos
relacionados, usted necesitará tener instalado al menos squid-2.5STABLE1.
Definiendo patrones comunes.
Lo primero será generar una lista la cual contendrá direcciones Web y palabras
usualmente utilizadas en nombres de ciertos dominios. Ejemplos:
www.sitioporno.com
www.otrositioporno.com
sitioindeseable.com
otrositioindeseable.com
napster
sex
porn
mp3
xxx
adult
warez
celebri
Esta lista, la cual deberá ser completada con todas las palabras (muchas de está son
palabras obscenas en distintos idiomas) y direcciones Web que el administrador
considere pertinentes, la guardaremos como /etc/squid/sitiosdenegados.
Parámetros en /etc/squid/squid.conf
Debemos definir una Lista de Control de Acceso que a su vez defina al fichero
/etc/squid/sitiosdenegados. Esta lista la denominaremos como "sitiosdenegados". De
modo tal, la línea correspondiente quedaría del siguiente modo:
acl sitiosdenegados url_regex "/etc/squid/sitiosdenegados"
Habiendo hecho lo anterior, deberemos tener en la sección de Listas de Control de

Acceso algo como lo siguiente:
#
acl all src 0.0.0.0/0.0.0.0
acl redlocal src 192.168.1.0/255.255.255.0
acl password proxy_auth REQUIRED
A continuación especificaremos modificaremos una Regla de Control de Acceso

existente agregando con un símbolo de ! que se denegará el acceso a la Lista de Control
de Acceso denominada sitiosdenegados:
http_access allow redlocal !sitiosdenegados
La regla anterior permite el acceso a la Lista de Control de Acceso denominada

redlocal, pero le niega el acceso a todo lo que coincida con lo especificado en la Lista
de Control de Acceso denominada sitiosdenegados.
Ejemplo aplicado a una Regla de Control de Acceso combinando el método de

autenticación explicado en el documento Cómo configurar Squid: Acceso por
Autenticación:
Reglas de control de acceso: denegación de sitios.

#
# INSERT YOUR OWN RULE(S) HERE TO allow ACCESS FROM YOUR
CLIENTS
#
http_access allow redlocal password !sitiosdenegados
Permitiendo acceso a sitios inocentes incidentalmente bloqueados.
Si por ejemplo el incluir una palabra en particular afecta el acceso a un sitio Web,
también puede generarse una lista de dominios o palabras que contengan un patrón pero
que consideraremos como apropiados.
Como ejemplo: vamos a suponer que dentro de la Lista de Control de Acceso de sitios
denegados está la palabra sex. esta denegaría el acceso a cualquier nombre de dominio
que incluya dicha cadena de caracteres, como extremesex.com. Sin embargo también
estaría bloqueando a sitios como sexualidadjovel.cl, el cual no tiene que ver en lo
absoluto con pornografía, sino orientación sexual para la juventud. Podemos añadir este
nombre de dominio en un ficheros que denominaremos /etc/squid/sitios-inocentes.
Este fichero será definido en una Lista de Control de Acceso del mismo modo en que se
hizo anteriormente con el fichero que contiene dominios y palabras denegadas.
acl inocentes url_regex "/etc/squid/sitios-inocentes"
Para hacer uso de el fichero, solo bastará utilizar la expresión ! en la misma línea
utilizada para la Regla de Control de Acceso establecida para denegar el mismo.
http_access allow all inocentes
La regla anterior especifica que se denegará el acceso a todo lo que comprenda la Lista
de Control de Acceso denominada denegados excepto lo que comprenda la Lista de
Control de Acceso denominada inocentes. es decir, se podrá acceder sin dificultad a
www.sexualidadjoven.cl manteniendo la restricción para la cadena de caracteres sex.
Finalizando procedimiento.
Finalmente, solo bastará reiniciar Squid para que tomen efecto los cambios y podamos
hacer pruebas.
Cómo configurar Squid: Restricción de acceso a contenido por

extensión.
Introducción.
Denegar el acceso a ciertos tipos de extensiones de fichero permite hacer un uso más
racional del ancho de banda con el que se dispone. El funcionamiento es
verdaderamente simple, y consiste en denegar el acceso a ciertos tipos de extensiones
que coincidan con lo establecido en una Lista de Control de Acceso.

Software requerido.
Definiendo elementos de la Lista de Control de Acceso.
Lo primero será generar una lista la cual contendrá direcciones Web y palabras
usualmente utilizadas en nombres de ciertos dominios. Ejemplos:
\.avi$
\.mp4$
\.mp3$
\.mp4$
\.mpg$
\.mpeg$
\.mov$
\.ra$
\.ram$
\.rm$
\.rpm$
\.vob$
\.wma$
\.wmv$
\.wav$
\.doc$
\.xls$
\.mbd$
\.ppt$
\.pps$
\.ace$
\.bat$
\.exe$
\.lnk$
\.pif$
\.scr$
\.sys$
\.zip$
\.rar$
Esta lista, la cual deberá ser completada con todas las extensiones de fichero que el
administrador considere pertinentes, la guardaremos como /etc/squid/listaextensiones.
Debemos definir una Lista de Control de Acceso que a su vez defina al fichero
/etc/squid/listaextensiones. Esta lista la denominaremos como "listaextensiones". De
modo tal, la línea correspondiente quedaría del siguiente modo:
acl listaextensiones urlpath_regex

"/etc/squid/listaextensiones"

#
acl all src 0.0.0.0/0.0.0.0

acl redlocal src 192.168.1.0/255.255.255.0

acl listaextensiones urlpath_regex
"/etc/squid/listaextensiones"
A continuación especificaremos modificaremos una Regla de Control de Acceso

existente agregando con un símbolo de ! que se denegará el acceso a la Lista de Control
de Acceso denominada listaextensiones:
http_access allow redlocal !listaextensiones
La regla anterior permite el acceso a la Lista de Control de Acceso denominada

redlocal, pero le niega el acceso a todo lo que coincida con lo especificado en la Lista
de Control de Acceso denominada listaextensiones.
Ejemplo aplicado a una Regla de Control de Acceso combinando el método de

autenticación explicado en el documento Cómo configurar Squid: Acceso por
Autenticación y el de denegación hacia Sitio de Red explicado en el documento Cómo
configurar Squid: Restricción de acceso a Sitio de Red:
Reglas de control de acceso: denegación de extensiones.

#
CLIENTS
#
http_access allow redlocal password !sitiosdenegados !

listaextensiones
hacer pruebas.
Cómo configurar Squid: Restricción de acceso por horarios
Denegar el acceso a ciertos en ciertos horarios permite hacer un uso más racional del
ancho de banda con el que se dispone. El funcionamiento es verdaderamente simple, y
consiste en denegar el acceso en horarios y días de la semana.
Software requerido.
Procedimientos
La sintaxis para crear Listas de control de acceso que definan horarios es la siguiente:
acl [nombre del horario] time [días de la semana] hh:mm-hh:mm
Los días de la semana se definen con letras, las cuales corresponden a la primera letra
del nombre en inglés, de modo que se utilizarán del siguiente modo:
• S - Domingo
• M - Lunes
• T - Mastes
• W - Miercoles
• H - Jueves
• F - Viernes
• A - Sábado
Ejemplo:
acl semana time MTWHF 09:00-21:00
Esta regla define a la lista semana, la cual comprende un horario de 09:00 a 21:00 horas
desde el Lunes hasta el Viernes.
Este tipo de listas se aplican en las Reglas de Control de Acceso con una mecánica
similar a la siguiente: se permite o deniega el acceso en el horario definido en la Lista
de Control de Acceso denominada X para las entidades definidas en la Lista de Control
de Acceso denominada Y. Lo anterior expresado en una Regla de Control de Acceso,
quedaís del siguiente modo:
http_access [allow | deny] [nombre del horario] [lista de

entidades]
Ejemplo: Se quiere establecer que los miembros de la Lista de Control de Acceso

denominada clasematutina tengan permitido acceder hacia Internet en un horario que
denominaremos como matutino, y que comprende de lunes a viernes de 09:00 a 15:00
horas.
La definción para le horario correspondería a:

acl clasematutina src 192.168.1.0/255.255.255.0
acl matutino time MTWHF 09:00-15:00
La definición de la Regla de Control de Acceso sería:
http_access allow matutino clasematutina
Lo anterior, en resumen, significa que quienes conformen clasematutina podrán acceder

a Internet de Lunes a Viernes de 09:00-15:00 horas.
Más ejemplos.
Restringiendo el tipo de contenido.
Como se explica en el documento "Cómo configurar Squid: Restricción de acceso a

contenido por extensión", es posible denegar acceso a cierto tipo de contenido de
acuerdo a su extensión. Igual que con otras funciones, se requiere una Lista de Control
de Acceso y una Regla de Control de Acceso
Si se necesita una lista denominada musica que defina a todos los ficheros con
extensión .mp3, utilizaríamos lo siguiente:

acl musica urlpath_regex \.mp3$
Si queremos denegar el acceso al todo contenido con extensión .mp3, la regla quedaría
del siguiente modo:
http_access allow clasematutina !musica
Combinando reglas de tiempo y contenido.
Si por ejemplo queremos restringir parcialmente el acceso a cierto tipo de contenido a

ciertos horarios, pueden combinarse distintos tipos de reglas.

acl matutino time MTWHF 09:00-15:00
acl musica urlpath_regex \.mp3$
http_access allow matutino clasematutina !musica
La Regla de Control de Acceso anterior especifica acceso permitido a en el horario

definido como matutino a quienes integran la Lista de Control de Acceso denominada
clasematutina a todo contenido [por omisión] excepto a los contenidos que coincidan
con los definidos en la Lista de Control de Acceso denominada musica.
hacer pruebas.
Cómo incluir supervisión contra virus en Squid con SquidClamAV

Redirector
Una útil funcionalidad que querrá aplicar cualquier administrador de sistemas con un
Servidor Intermediario (Proxy) con Squid.
Acerca de Squid.
Squid es un Servidor Intermediario (Proxy) de alto desempeño que se ha venido

desarrollando desde hace varios años y es hoy en día un muy popular y ampliamente
utilizado entre los sistemas operativos como GNU/Linux y derivados de Unix®. Es muy
confiable, robusto y versátil y se distribuye bajo los términos de la Licencia Pública
General GNU (GNU/GPL). Siendo programática libre, está disponible el código fuente
para quien así lo requiera.
Entre otras cosas, 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, WWCP, aceleración HTTP, caché de consultas
DNS y otras muchas más como filtración de contenido y control de acceso por IP y por
usuario.
URL: http://www.squid-cache.org/
Acerca de ClamAV.
ClamAV tiene las siguiente características:
• Distribuido bajo los términos de la Licencia Publica General GNU

versión 2.
• Cumple con las especificaciones de familia de estándares POSIX
(Portable Operating System Interface for UNIX o interfaz portable de
sistema operativo para Unix).
• Exploración rápida.
• Detecta más de 44 mil virus, gusanos y troyanos, incluyendo virus para
MS Office.
• Capacidad para examinar contenido de ficheros ZIP, RAR, Tar, Gzip,
Bzip2, MS OLE2, MS Cabinet, MS CHM y MS SZDD.
• Soporte para explorar ficheros comprimidos con UPX, FSG y Petite.
• Avanzada herramienta de actualización con soporte para firmas digitales
y consultas basadas sobre DNS.
URL: http://www.clamav.net/
Acerca de SquidClamAV Redirector.
El re-director de ClamAV para Squid es un guión auxiliar para Squid para examinar
contenido en busca de Virus para una lista de extensiones definidas. El guión se encarga
de la petición tal y como es solicitada hacia Squid, examinando ésta en busca de virus.
Reescribe el URL desde Squid hacia una página de información en caso de encontrarse
un virus.
URL: http://www.jackal-net.at/tiki-read_article.php?articleId=1
Procedimientos.
Instalación del equipamiento lógico (Software) requerido.
Si dispone de un sistema con Red Hat™ Enterprise Linux 4, CentOS 4 o White Box
Enterprise Linux 4, puede utilizar el siguiente depósito yum:
[mailscanner-lpt]
name=MailScanner Linux Para Todos para Enterprise Linux 4.0
baseurl=http://www.linuxparatodos.net/lpt/whitebox/4.0/mailscanner/
gpgkey=http://www.linuxparatodos.net/lpt/LPT-RPM-KEY
Una vez configurado lo anterior, solo bastará utilizar:
yum -y install squidclamav_redirector
Lo anterior instalará squidclamav_redirector y clamav junto con todas las dependencias

que seas necesarias.
Configuración de Squid.
Utilice el editor de texto de su predilección y disponga a modificar

/etc/squid/squid.conf con la finalidad de configurar los siguiente parámetros:
redirect_program /usr/bin/SquidClamAV_Redirector.py -c
/etc/squid/SquidClamAV_Redirector.conf
redirect_children 5
Deben agregarse además las siguientes reglas de control de acceso en cualquier parte de
/etc/squid/squid.conf, justo después de donde se localizan acl all src 0.0.0.0/0.0.0.0 y
acl localhost src 127.0.0.1/255.255.255.255:
redirector_access deny localhost

http_reply_access allow all
Configuración de squidclamav_redirector.
Hay dos ficheros a personalizar: /etc/squid/SquidClamAV_Redirector.conf y

/var/www/squidclamav_redirector/information.php.
El fichero /etc/squid/SquidClamAV_Redirector.conf está configurado de modo que
se utilice como página de información un URL externo. Puede reemplazarse por
http://nombre.servidor.squid/redirector/information.php y personalizar el contenido
de /var/www/squidclamav_redirector/information.php a fin de contar con una
página informativa que se mostrará cada vez que se detecte un virus u otro
equipamiento lógico maligno (virus, gusanos, troyanos, etc.).
Iniciando o reiniciando el servicio.
Una vez terminada la configuración, ejecute el siguiente mandato para iniciar por
primera vez Squid:
service squid start
Si necesita reiniciar para probar cambios hechos en la configuración, utilice lo

siguiente:
Depuración de errores
Cualquier error al inicio de Squid solo significa que hubo errores de sintaxis, errores de
dedo o bien se están citando incorrectamente las rutas hacia los ficheros de las Listas de
Control de Acceso.
Puede realizar diagnóstico de problemas indicándole a Squid que vuelva a leer

configuración, lo cual devolverá los errores que existan en el fichero
/etc/squid/squid.conf.
service squid reload
Cuando se trata de errores graves que no permiten iniciar el servicio, puede examinarse
el contenido de el fichero /var/log/squid/squid.out con el mandato less, more o
cualquier otro visor de texto:
less /var/log/squid/squid.out
Cómo configurar Squid: Acceso por Autenticación.
Es muy útil el poder establecer un sistema de autenticación para poder acceder hacia
Internet, pues esto permite controlar quienes si y quienes no accederán a Internet sin
importar desde que máquina de la red local lo hagan. Sera de modo tal que tendremos
un doble control, primero por dirección IP y segundo por nombre de usuario y clave de
acceso.

Software requerido.
• squid-2.5.STABLE3
• httpd-2.0.x (Apache) (opcional)
• openldap-servers-2.2.x (opcional)
Eligiendo el módulo de autenticación.
Este manual considera poder autenticar a través de un fichero de texto simple con claves
de acceso creadas con htpasswd o bien a través de un servidor LDAP, lo cual constituye
una solución más robusta.
Autenticación a través del módulo LDAP.
Considerando que se ha configurado exitosamente OpenLDAP como servidor de

autenticación, solo basta definir el directorio (o subdirectorio) y el servidor LDAP a
utilizar.
La sintaxis utilizada para squid_ldap_auth es la siguiente:
squid_ldap_auth -b "Directorio-o-DN-a-utilizar" servidor-

ldap-a-utilizar
Ejemplo:
squid_ldap_auth -b "cn=people,dc=su-dominio,dc=com" 127.0.0.1
Se debe editar el fichero /etc/squid.conf y se especificar el programa de autenticación se

utilizará. Localice la sección que corresponde a la etiqueta auth_param basic program.
Por defecto no está especificado programa alguno. Considerando que squid_ldap_auth
se localiza en /usr/lib/squid/ncsa_auth, procederemos a añadir el siguiente parámetro:
auth_param basic program /usr/lib/squid/squid_ldap_auth -b

"cn=people,dc=su-dominio,dc=com" 127.0.0.1
Lo anterior conecta al directorio dc=su-red-local,dc=com en el servidor LDAP en

127.0.0.1.
Autenticación a través del módulo NCSA
Squid puede utilizar el módulo ncsa_auth, de la NCSA (National Center for

Supercomputing Applications), y que ya viene incluido como parte del paquete
principal de Squid en la mayoría de las distribuciones actuales. Este módulo provee una
autenticación muy sencilla a través de un fichero de texto simple cuyas claves de acceso
fueron creadas con htpasswd.
Creación del fichero de claves de acceso.
Se requerirá la creación previa de un fichero que contendrá los nombres de usuarios y

sus correspondientes claves de acceso (cifradas). El fichero puede localizarse en
cualquier lugar del sistema, con la única condición que sea asequible para el usuario
squid.
Debe procederse a crear un fichero /etc/squid/claves:
touch /etc/squid/claves
Salvo que vaya a utilizarse un guión a través del servidor web para administrar las
claves de acceso, como medida de seguridad, este fichero debe hacerse leíble y
escribible solo para el usuario squid:
chmod 600 /etc/squid/claves

chown squid:squid /etc/squid/claves
A continuación deberemos dar de alta las cuentas que sean necesarias, utilizando el
mandato htpasswd -mismo que viene incluido en el paquete httpd-2.0.x-. Ejemplo:
htpasswd /etc/squid/claves joseperez
Lo anterior solicitará teclear una nueva clave de acceso para el usuario joseperez y
confirmar tecleando ésta de nuevo. Repita con el resto de las cuentas que requiera dar de
alta.
Todas las cuentas que se den de alta de este modo son independientes a las ya existentes
en el sistema. Al dar de alta una cuenta o cambiar una clave de acceso lo estará
haciendo EXCLUSIVAMENTE para el acceso al servidor Proxy. Las cuentas son
independientes a las que se tengan existentes en el sistema como serían shell, correo y
Samba.
Lo siguiente será especificar que programa de autenticación se utilizará. Localice la

sección que corresponde a la etiqueta auth_param basic program. Por defecto no está
especificado programa alguno. Considerando que ncsa_auth se localiza en
/usr/lib/squid/ncsa_auth, procederemos a añadir el siguiente parámetro:
auth_param basic program /usr/lib/squid/ncsa_auth

/etc/squid/claves
/usr/lib/squid/ncsa_auth corresponde a la localización de el programa para autenticar y

/etc/squid/claves al fichero que contiene las cuentas y sus claves de acceso.
Listas y reglas de control de acceso.
El siguiente paso corresponde a la definición de una Lista de Control de Acceso.

Especificaremos una denominada passwd la cual se configurará para utilizar
obligatoriamente la autenticación para poder acceder a Squid. Debe localizarse la
sección de Listas de Control de Acceso y añadirse la siguiente línea:

Listas de Control de Accesos: autenticación.

#
acl all src 0.0.0.0/0.0.0.0
acl redlocal src 192.168.1.0/255.255.255.0

Procedemos entonces a modificar la regla de control de accesos que ya teníamos para

permitir el acceso a Internet. Donde antes teníamos lo siguiente:
Le añadimos passwd, la definición de la Lista de Control de Acceso que requiere utilizar

clave de acceso, a nuestra regla actual, de modo que quede como mostramos a
continuación:
http_access allow redlocal password
menos de este modo:
Reglas de control de acceso: Acceso por clave de acceso.

#
CLIENTS
#
http_access allow redlocal password

hacer pruebas.
Cómo configurar Squid: Como configurar el administrador de cache.
Squid incluye una herramienta que permite monitorizar toda la actividad y tráfico que
pasa a través del cache. Dentro de /usr/lib/squid se localiza un guión CGI el cual, si
utilizo un paquete RPM para instalar Squid, se copió automáticamente dentro del
directorio /var/www/cgi-bin/ al momento de instalarse Squid.
Software requerido
• squid-2.5STABLE1
• httpd-2.0.x (Apache)
• mod_perl
Si acaso instaló squid desde código fuente, copie cachemgr.cgi dentro de

/var/www/cgi-bin/ y ejecute chmod 755 /var/www/cgi-bin/cachemgr.cgi a fin de
establecer los permisos de ejecución necesarios.
Procedimientos
Edite /etc/squid/squid.conf y añada un Lista de Control de Acceso denominada

administrador para definir una única estación de trabajo desde la cual se permitirá
acceder al administrador del cache de Squid. Por seguridad nunca defina a toda la red
local y solo defina IPs en red inválida para acceder al administrador del cache. En el
siguiente ejemplo se considera que la IP de la estación de trabajo desde la cual se
permitirá acceder al administrador del cache está es 192.168.1.25.
acl administrador src 192.168.1.25
Añada una regla que permita el acceso a la Lista de Control de Acceso denominada
administrador:
http_access allow manager administrador
Añada una línea para definir una clave de acceso para el administrador del cache. No
utilice la clave de acceso de root ni ninguna otra clave de acceso importante, esto
debido a que la clave de acceso del administrador del cache se almacena en texto
simple. Sin embargo, procure que está sea tan complicada como sea posible (mínimo 8
caracteres combinando mayúsculas, minúsculas, números y símbolos).
cachemgr_passwd clave_de_acceso_que_sea all
hacer pruebas.
Inicie Apache (si aún no lo ha hecho todavía) y desde la estación de trabajo definida en
la Lista de Control de Acceso denominada administrador (ejemplo: 192.168.1.25),
suponiendo que su cache tiene IP 192.168.1.1, intente acceder con su navegador hacia
http://192.168.1.1/cgi-bin/cachemgr.cgi.
Apéndice: Listas y reglas de control de acceso para Squid.
Opciones que habilitan función de autenticación en squid-2.5.STABLEx (Red Hat

Linux 9)
auth_param basic children 5

auth_param basic realm Servidor Proxy-Cache Squid
auth_param basic credentialsttl 2 hours
# anteriores ya están descomentadas.
auth_param basic program /usr/lib/squid/ncsa_auth
/etc/squid/squidpasswords
NOTA: Red Hat Linux 8.0 y 7.x utilizan 'authenticate_program' en lugar de

'auth_param basic program'
Para generar el fichero de contraseñas correspondiente, se debe utilizar el siguiente

mandato:
htpasswd -c /etc/squid/squidpasswords nombre_usuario
Para modificar las contraseñas del fichero de contraseñas, se debe utilizar el siguiente
mandato:
htpasswd /etc/squid/squidpasswords nombre_usuario
El fichero /etc/squid/squidpasswords debe ser leíble para el usuario squid:
chown squid:squid /etc/squid/squidpasswords

Reglas aplicadas
# Lista que define método de autenticación:
# Listas de control de acceso por defecto:

acl all src 0.0.0.0/0.0.0.0
# Listas que definen conjuntos de maquinas

acl redlocal src "/etc/squid/redlocal"
acl privilegiados src "/etc/squid/privilegiados"
acl restringidos src "/etc/squid/restringidos"
acl administrador src 192.168.1.254
# Listas que definen palabras contenidas en un URL

acl porno url_regex "/etc/squid/porno"
# Contenido:
#
# sex
# porn
# girl
# celebrit
# extasis
# drug
# playboy
# hustler
# Lista de sitios inocentes que accidentealmente sean bloqueados

acl noporno url_regex "/etc/squid/noporno"
# Contenido:
#
# missingheart
# wirelessexcite
# msexchange
# msexcel
# freetown
# geek-girls
# adulteducation
# Listas que definen tipos de extensiones
# Define uan lista estricta de extensiones prohibidas

acl multimedia urlpath_regex "/etc/squid/multimedia"
# Contenido:
#
# \.mp3$
# \.avi$
# \.mov$
# \.mpg$
# \.bat$
# \.pif$
# \.sys$
# \.lnk$
# \.scr$
# \.exe$
# Define una lista moderada de extensiones prohibidas

acl peligrosos urlpath_regex "/etc/squid/peligrosos"
# Contenido:
#
# \.bat$
# \.pif$
# \.sys$
# \.lnk$
# \.scr$
# \.exe$
# Define una sola extensión

acl realmedia urlpath_regex \.rm$
# Reglas de control de acceso
# Regla por defecto:

# Ejemplos de reglas de control de acceso

http_access allow restringidos password !porno !multimedia
http_access allow redlocal password !porno !peligrosos
http_access allow privilegiados password !peligrosos
http_access allow administrador
http_access allow noporno all
# Regla por defecto:

FUENTES:
WIKIPEDIA
www.linuxparatodos.net

Proxy Squid

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Proxy Squid

Cargado por

Copyright:

Formatos disponibles

Proxy

La palabra proxy se usa en muchas situaciones en donde tiene sentido un intermediario:

• El uso más común es el de servidor proxy, que es un ordenador que intercepta

En general (no sólo en informática), el uso de un intermediario puede provocar:

• Abuso. Al estar dispuesto a recibir peticiones de muchos usuarios y

A continuación se hablará del servidor proxy de web, el más común.

Proxy de web / Proxy cache de web

1. El cliente realiza una petición (p.e. mediante un navegador web) de un recurso

El caché utiliza normalmente un algoritmo para determinar cuándo un documento está

• Ahorro de Tráfico: Las peticiones de páginas Web se hacen al servidor Proxy y

Las páginas mostradas pueden no estar actualizadas si éstas han sido

Un diseñador de páginas web puede indicar en el contenido de su web que los

• El hecho de acceder a Internet a través de un Proxy, en vez de mediante

Muchas organizaciones (incluyendo empresas, colegios y familias) usan los proxies

Un reverse proxy es un servidor proxy instalado en el domicilio de uno o más servidores

• Seguridad: el servidor proxy es una capa adicional de defensa y por lo tanto

Otro mecanismo para hacer de intermediario en una red es el NAT.

La traducción de direcciones de red (NAT, Network Address Translation) también es

En esta configuración el proxy ejecutará cualquier petición de cualquier ordenador que

Debido a lo anterior, muchos servidores, como los de IRC, o correo electrónicos,

Squid es un Servidor Intermediario (Proxy) de alto desempeño que se ha venido

Squid consiste de un programa principal como servidor, un programa para búsqueda en

NOTA ESPECIAL: Squid no debe ser utilizado como Servidor Intermediario

Algoritmos de caché utilizados por Squid.

A través de un parámetro (cache_replacement_policy) Squid incluye soporte para los

• LRU Acrónimo de Least Recently Used, que traduce como Menos

• LFUDA Acrónimo de Least Frequently Used with Dynamic Aging,

• GDSF Acrónimo de GreedyDual Size Frequency, que se traduce

Sustento lógico necesario.

Squid no se instala de manera predeterminada a menos que especifique lo contrario

Instalación a través de yum.

yum -y install squid httpd

Instalación a través de up2date.

Otros componentes necesarios.

yum -y update kernel iptables

up2date -u kernel iptables

Evite dejar espacios vacíos en lugares indebidos. El siguiente es un ejemplo de como

El siguiente es un ejemplo de como si se debe habilitar un parámetro.

Squid utiliza el fichero de configuración localizado en /etc/squid/squid.conf, y podrá

Parámetro http_port: ¿Que puerto utilizar para Squid?

En el caso de un Servidor Intermediario (Proxy) Transparente, regularmente se

El parámetro cache_mem establece la cantidad ideal de memoria para lo siguiente:

Los datos de estos objetos se almacenan en bloques de 4 Kb. El parámetro cache_mem

Si se posee un servidor con al menos 128 MB de RAM, establezca 16 MB como valor

Parámetro cache_dir: ¿Cuanto desea almacenar de Internet en el

cache_dir ufs /var/spool/squid 100 16 256

Se puede incrementar el tamaño del caché hasta donde lo desee el administrador.

Es muy importante considerar que si se especifica un determinado tamaño de caché y

Al acceder a un servidor FTP de manera anónima, de modo predefinido Squid enviará

Listas de control de acceso.

Regularmente una lista de control de acceso se establece con la siguiente sintaxis:

acl [nombre de la lista] src [lo que compone a la lista]

acl miredlocal src 192.168.1.0/255.255.255.0

También puede definirse una Lista de Control de Acceso especificando un fichero

acl permitidos src "/etc/squid/permitidos"

El fichero /etc/squid/permitidos contendría algo como siguiente:

Lo anterior estaría definiendo que la Lista de Control de Acceso denominada

Reglas de Control de Acceso.

Estas definen si se permite o no el acceso hacia Squid. Se aplican a las Listas de

La sintaxis básica es la siguiente:

http_access [deny o allow] [lista de control de acceso]

http_access allow permitidos

También pueden definirse reglas valiéndose de la expresión !, la cual significa no.