UD 7 Servidores proxy

UD 7 Servidores proxy

En esta unidad aprenderás a:

Conocer las ventajas e inconvenientes de utilizar un servidor proxy-caché.

Detectar la necesidad de utilizar el proxy-caché como herramienta que permite ocultar una red local detrás de una
máquina pública compartiendo su conexión a Internet.
Acelerar los accesos a contenidos web haciendo uso de la caché del servidor proxy-caché.
Describir los mecanismos utilizados por el servidor proxy-caché para proporcionar contenidos actualizados de sus
páginas almacenadas.
Instalar y configurar uno de los proxy-caché más conocido y utilizado en ambientes GNU/Linux como es SQUID.
Preparar configuraciones básicas del servidor SQUID para diferentes requerimientos.

1 de 41
 UD 7 Servidores proxy

Introducción

Objetivos
Los objetivos de esta unidad van encaminados a que el alumnado adquiera los conocimientos y destrezas
necesarias para:

La instalación, configuración y prueba de servidores «proxy» como herramientas básicas de

protección perimetral.

Contenidos

1. ¿Qué es un proxy?
2. Instalación de un servidor proxy
3. Instalación y configuración de un cliente proxy
4. Configuración del almacenamiento de la caché de un proxy
5. Configuración de filtros
6. Ejemplos
7. Métodos de autenticación en un proxy
8. Proxy transparente
9. Proxy inverso
10. Monitorización
11. Archivo de autoconfiguración
12. Herramientas de análisis de registros

Enlaces
Conceptos
Videotutoriales externos

2 de 41
 UD 7 Servidores proxy

¿Qué es un proxy?

Definición
Servidor cuyo objetivo es la centralización del tráfico entre Internet y una red local,
y, de esa forma, cada uno de los ordenadores de la red local no tiene necesidad de
disponer de una conexión directa a Internet.

El servidor proxy también se utiliza para controlar los accesos no permitidos desde Internet hacia la
red local y viceversa.

El proxy hace una transformación de las direcciones de entrada y salida. Cuando un ordenador de la red
local hace una solicitud o petición web, el proxy la intercepta y la procesa. De esa forma oculta la dirección
IP del ordenador real que hace la solicitud y en la petición aparece la IP del proxy.

Lo usual es que el ordenador que hace de servidor proxy tenga al menos dos interfaces de red: una
conectada a la red local y la otra conectada a Internet a través de un dispositivo de electrónica de red
adecuado. Todos los paquetes con origen en la red local llegan al servidor a través de la interfaz que
atiende a la red local y son analizados antes de ser reenviados al exterior a través de la otra interfaz de red.

¿Qué es un proxy-caché?
Servidor situado entre la máquina del usuario y otra red, que normalmente sera
Internet, que actúa como barrera de protección para separar las dos redes y como
zona caché para acelerar el acceso a páginas web o poder restringir el acceso a
contenidos.

3 de 41
 UD 7 Servidores proxy

Características y funciones
Todo proxy consta de:

Elementos destino: identifican los servidores remotos.

Elementos clientes: identifican las aplicaciones cliente utilizadas para acceder a servidores remotos.
Reglas de acceso: establecen las condiciones para que los clientes accedan a los servidores remotos.

La captura anterior muestra el acceso a la configuración de Red en el navegador web Firefox. Para llegar a
ella ir a las Preferencias del menú de configuración del navegador.

Preferencias > General > Configuración de la conexión

La siguiente captura muestra las opciones de configuración del servidor proxy:

El esquema siguiente muestra el funcionamiento de un proxy 'normal'. Vemos la máquina que contiene el
proxy entre dos redes, una interna y otra externa. Para comunicarse con cada red necesita una interfaz de
red. Las peticiones de los clientes antes de llegar a los servidores remotos 'pasan' por el proxy que aplica
sobre estas peticiones sus filtros. En el proxy se decide si la petición 'pasa o no pasa' en función de las reglas
establecidas en el proxy.

4 de 41
 UD 7 Servidores proxy

En general, los proxy pueden ser:

Proxy NAT
Proxy anónimo
Proxy web
Proxy inverso
Proxy transparente

Elegir uno u otro dependerá de lo que se necesite en cada momento en el sistema.

¿Qué hace un proxy NAT?

Enmascara las direcciones IP entre el cliente y el destino.

Este tipo de proxy es muy útil cuando se pretende compartir una misma dirección IP para acceder a Internet.
Un ejemplo típico es el de un aula que esta detrás de un proxy y todos los equipos del aula salen a Internet a
través del servidor proxy.

¿Qué hace un proxy anónimo?

Permite ocultar la IP y navegar por la web de forma anónima.

En este caso los servidores remotos (destino) desconocen totalmente a los clientes.

Se utilizan en muchos casos para poder saltar un cortafuegos, o medidas de seguridad impuestas por el
administrador del sistema para evitar que los usuarios se conecten a sitios no permitidos en esa red. Por
ejemplo, prohibir que estudiantes o trabajadores se conecten a redes sociales en horario de clase o laboral.

En ocasiones es interesante poder navegar de forma anónima si nos vamos a conectar a páginas de dudosa
fiabilidad o queremos tener la seguridad de que no estamos siendo 'espiados'.

Son proxys anónimos:

Anonymizer
Ultrasurf
FirewallBlocker
ProtectedBrowser
Anonymous-Browsing

¿Qué hace un proxy web o caché?

Almacena las páginas web de los servidores remotos en memorias intermedias para poder servirlas a
los clientes bajo demanda.

El uso de un proxy web no introduce retardos en la obtención de la información, ya que si la página solicitada
no está en la caché del proxy, se iniciará la búsqueda normal rápidamente, y si la página se encuentra en la
memoria caché, la página se sirve con la velocidad de conexión de la red local, que siempre es superior a la
de Internet.

¿Qué hace un proxy inverso?

Se suele utilizar entre Internet y los servidores web.

Un proxy inverso es un servidor proxy-caché "al revés". En lugar de permitir el acceso a Internet a
usuarios internos, permite a usuarios de Internet acceder a determinados servidores internos.

Este tipo de proxy se utiliza para mejorar la seguridad y distribuir la carga sobre los servidores. Es el proxy el
que soporta todas las peticiones y las reenvía a los servidores web.

En este caso son los clientes remotos los que hacen peticiones a nuestros servidores locales.

¿Qué hace un proxy transparente?

Es una combinación de un proxy con NAT para que las conexiones se enruten dentro del proxy y el
cliente no tenga que hacer ninguna configuración.
El objetivo es que el propio usuario desconozca que se esté utilizando un proxy.

5 de 41
 UD 7 Servidores proxy

Los administradores suelen utilizarlos como medida de seguridad o para agilizar la conexión.

En general, se podría decir que los proxys actúan de manera similar a las pasarelas o gateways comunicando dos redes
diferentes, pero con una diferencia de que los proxys son capaces de trabajar con protocolos de nivel aplicación.

Funciones
En general un proxy puede realizar las siguientes funciones:

Filtro de contenidos

Un proxy actúa como filtro de contenidos cuando el proxy puede seleccionar el tipo de contenidos accedidos
por las estaciones de trabajo.

Memoria caché de páginas web

Un proxy es capaz de almacenar las páginas consultadas por los clientes en una memoria caché, con esto
acelera las conexiones sucesivas y es capaz de servir dichas páginas si se pierde la conexión a Internet de
manera momentánea.

Servidor de direcciones IP

Un proxy es capaz de asignar direcciones IP a las estaciones de trabajo utilizando un servidor DHCP.

Cortafuegos

Si el proxy es un intermediario que recoge conexiones y es capaz de interrumpirlas o continuarlas, es porque

está funcionando como un cortafuegos del sistema.

Otras funciones importantes de los proxy son:

Permiten el acceso web a máquinas privadas (con una dirección IP privada) que no están conectadas directamente
a Internet y que de esta forma sí pueden acceder a Internet.
Controlan el acceso web aplicando reglas o normas. Por ejemplo, dependiendo de la máquina, la página solicitada,
el día y/o hora de la solicitud, etc.
Registran el tráfico web desde la red local hacia el exterior.
Controlan el contenido web visitado y descargado para detectar la presencia de posibles ataques a través de virus,
gusanos, troyanos, conejos, etc.
Controlan la seguridad de la red local ante posibles ataques, intrusiones en el sistema, etc.

Además de la función de intermediario entre una red local e Internet y agilizar las conexiones mediante la caché, los
proxy disponen de otras funcionalidades directamente relacionadas con temas de seguridad.

Entre ellas:

Autenticación de usuarios.

Los proxy funcionan en la capa de aplicación del modelo TCP/IP y ya son capaces de gestionar sesiones de
usuario, lo que les da un valor añadido en cuanto a seguridad se refiere.

Filtrado del tráfico.

Como cortafuegos de nivel de aplicación, el proxy es capaz de realizar un filtrado del tráfico de paquetes pero
a un nivel superior, pudiendo trabajar ya con dominios.

Creación de ficheros log.

Al igual que los cortafuegos de nivel 3 y 4, los proxy permiten la creación y gestión de los logs generados por
la herramienta utilizada como proxy.

6 de 41
 UD 7 Servidores proxy

Funcionamiento del proxy-caché

Procedimiento

Se supone que el cliente está configurado para acceder a Internet a través de un servidor proxy-caché. El funcionamiento
del servidor proxy-caché es el siguiente:

El navegador web solicita una página html (por ejemplo) a un servidor web o solicita un archivo de un servidor FTP.
Como el navegador web está configurado para acceder a Internet a través de proxy, en realidad la petición la está
haciendo al servidor proxy-caché.
El proxy-caché recibe la petición y busca en la caché (disco duro del servidor proxy) si está almacenada la página
solicitada.
Si es la primera vez que se accede a esa página html el servidor proxy-caché no la tiene almacenada. El servidor
proxy reenvía la petición al servidor web el cual le devolverá la página solicitada. La guarda en caché y la envía al
navegador web que hizo la petición.
Si el servidor proxy-caché tiene ya almacenada la página html entonces solicita al servidor web (que contiene la
página pedida) que le envíe la cabecera de la página html. En la cabecera viene la fecha de creación de la página y
la fecha de última modificación. Las compara con las fechas de la copia de la página html almacenada en caché y:
Si la página html no ha experimentado ninguna modificación no se pide al servidor y se envía al navegador
web la página en caché.
Si la página html ha experimentado alguna modificación el proxy-caché solicita al servidor web la nueva
versión de la página html, sustituye la antigua por ésta y la envía al navegador web.

En general, los servidores web y los servidores proxy-caché controlan el estado de un recurso consultando en la
cabecera los campos 'last modified' (fecha última modificación) o 'expires' (fecha de expiración).

Los requerimientos hardware de un servidor proxy-caché son los siguientes:

El servidor proxy-caché necesita bastante espacio en disco y un tipo de disco duro cuyo acceso sea rápido.
Lógicamente, cuanto más disco duro más páginas podrá almacenar.
Pero no tiene sentido dedicar a caché una gran cantidad de espacio en disco si luego la velocidad de respuesta no
es la adecuada. Para evitar este cuello de botella hay que dedicar gran cantidad de memoria RAM a la gestión de
la caché. Cuanta más memoria RAM más objetos podrá almacenar en ella y más rápidamente los servirá. Como
norma orientativa se toma que por cada 100MB de disco para caché se debe disponer de un 1MB de RAM. Por
lo tanto si se dedican 1GB de disco a caché se necesitan 10MB de RAM.
Los requerimientos de procesador son normales.

7 de 41
 UD 7 Servidores proxy

Instalación de un servidor proxy: Squid

El servidor proxy de libre distribución más usado es Squid,
basado en software libre GNU/Linux. Esta distribución está
disponible en varias plataformas.

La web oficial del proxy Squid es http://www.squid-cache.org/.

Aunque la unidad se centra en la instalación, configuración y uso de Squid bajo Ubuntu, en http://wiki.squid-cache.org
/SquidFaq/BinaryPackages está disponible una versión de Squid para Windows.

El primer paso es instalar el paquete mediante el comando:

# apt install squid

Al instalar la herramienta se generan una serie de archivos y directorios:

Archivo/directorio Descripción

/usr/sbin/ Contiene archivos ejecutables

/var/run/squid.pid Archivo que contiene el PID (Process

Identificator) del proceso squid.

/var/log/squid/ Directorio que almacena los archivos de

logs de Squid.

/var/spool/squid/ Directorio que contiene la caché

propiamente.

/etc/squid/squid.conf Archivo de configuración de Squid.

/usr/lib/squid/ Complementos, autenticación,..

/usr/share/doc/squid/ Documentación de la herramienta

Squid.

El archivo de configuración de Squid es /etc/squid/squid.conf.

Una configuración básica debe de incluir, al menos, los siguientes parámetros:

cache_effective_user / group

Establece el usuario y grupo para Squid. Por problemas de seguridad es preferible que Squid y sus procesos asociados
se ejecuten como usuario y grupo proxy. Este usuario y grupo proxy tienen unas características especiales que no tienen
ni el administrador (root) ni otros usuarios.

En concreto proxy es un usuario que no tiene shell (no se puede conectar al sistema), tiene unos permisos limitados a su
área de acción y debe ser el propietario del directorio caché y del directorio de logs.

cache_effective_user proxy

cache_effective_group proxy

http_port

Establece el puerto de escucha para Squid. Por defecto Squid atiende las peticiones de los clientes por el puerto 3128.
Pero también se podría utilizar, por ejemplo, el puerto 8080. Se puede cambiar el puerto pero es importante tener en
cuenta que éste no debe ser utilizado por ningún otro servicio.

#default: http_port 3128

http_port 3128

Es posible asociar el servicio Squid a una determinada IP, que sería la que conecta con la red local. En ese caso la
sintaxis es:

http_port 192.168.112.1:3128

siendo 192.168.1.1 la IP de la tj de red por donde escucha el servidor proxy.

8 de 41
 UD 7 Servidores proxy

cache_mem

Establece la cantidad de memoria RAM dedicada al almacenamiento de los bloques de la caché más solicitados. En la
medida que se aumenta la cantidad de memoria física de la máquina, aumentará el rendimiento de Squid.

La cantidad de RAM también depende de la cantidad de espacio en disco dedicado a la caché.

cache_mem 500 MB

cache_dir

Establece la localización y el tamaño de la caché en disco duro. Por defecto son 100MB. Se puede especificar el nº de
subdirectorios y el nº de niveles posibles dentro de cada subdirectorio.

cache_dir ufs /var/spool/squid/ 500 16 256

El ejemplo indica una caché en disco de 500MB, con 16 subdirectorios, cada uno de ellos con 256 niveles.

UFS (Unix File System) es un sistema de archivos utilizado por muchos sistemas operativos Unix y es el formato original
de Squid.

visible_hostname

Establece el nombre del servidor.

Podemos saber cuál es mediante el comando hostname. Si no especificamos el hostname de nuestra máquina puede
que Squid no sea capaz de determinarlo automáticamente, causando así que el programa falle.
Por ejemplo:
visible_hostname servidor

acl Lista de control del acceso

El parámetro ACL permite:

Proteger al servidor proxy-caché de conexiones externas, evitando, de esa forma, que se conecten clientes
desconocidos que podrían saturar la conexión con el exterior.
Proteger a los clientes de accesos a puertos peligrosos actuando como cortafuegos contra posibles ataques desde
la web.
Establecer una jerarquía de cachés.
Establecer la red como conjunto de trabajo o, por el contrario, como máquinas individuales.

A continuación, a cada ACL creada se le hace corresponder una Regla de Control de Acceso (http_access) que es la que
permite o deniega las acciones definidas en la ACL.

La sintaxis es variable. Estos son algunos de los formatos más utilizados:

acl [nombre_lista] src [componentes_lista]

acl [nombre_lista] time marco_horario

acl [nombre_lista] srcdomain/dstdomain domain

acl [nombre_lista] url_regex patron

acl [nombre_lista] srcdom_regex/dstdom_regex google\..*

acl [nombre_lista] referer_regex https://wwww.google.*

acl [nombre_lista] maxconn limite

donde:

nombre_lista: es el nombre que se le asigna a la ACL.

src: hace referencia al origen, es decir, la dirección IP de un cliente.
[componentes_lista]: puede indicar direcciones IP de redes con la máscara de red, o archivos cuyo
contenido sean las direcciones IP.
time: permite/deniega las conexiones dentro de una franja horaria, donde marco_horario sigue unas
reglas de construcción que se verán más adelante.
srcdomain/dstdomain: establece permisos sobre dominios web origen y destino.
url_regex: permite definir ACLs que identifican sitios web dependiendo de que la URL contenga ciertos
caracteres o palabras. Es decir, identifica una url (desde el https:// inicial) que cumple una expresión
regular o patrón. Con la opción -i ignora la diferencia entre mayúscula y minúscula (ignorecase).
referer_regex define una acl que se comprueba con el enlace que se ha pulsado para acceder a una
determinada página. Cada petición de una página web incluye la dirección donde se ha pulsado para
acceder. Si escribimos la dirección en el navegador entonces estaremos haciendo una petición directa.

9 de 41
 UD 7 Servidores proxy

En el ejemplo establecemos una acl para todas las páginas a las que se haya accedido pulsando en una
ventana de búsqueda de google.

maxconn: establece un nº máximo de conexiones por IP.

http_access Regla de control de acceso

La regla de control de acceso indica si se permite o deniega el acceso a Squid para hacer peticiones HTTP.

Actúa siempre sobre una lista de control de acceso permitiendo o denegando la situación definida en ella.

La sintaxis es:

http_access [ deny / allow ] [ lista_control_acceso ...]

Logs Registro de logs

Squid utiliza diferentes archivos para realizar el registro de actividad:

access_log /var/log/squid/access.log squid
cache_log /var/log/squid/cache.log
access.log: almacena peticiones hechas al proxy. Del análisis de su contenido se pueden obtener estadísticas.
cache.log: almacena información general de funcionamiento de la caché, errores, etc.

Arranque y parada de Squid

Al instalar squid queda ejecutandose.

Ahora se ha crear la estructura necesaria para la cache del servicio. Esto hay que hacerlo a squid
parado.

Por otra parte hay que activar en el archivo de configuración la directiva que especifica donde esta ubicada
la cache y su tamaño.

Para crear la cache ejecutar el siguiente comando sólo la primera vez:

# /usr/sbin/squid -z

La opción -z crea los directorios de la caché.

Siempre que se hagan modificaciones en el archivo de configuración debemos ejecutar la siguiente orden
para validar la configuración de Squid, no debe dar ningún error al ejecutar la orden:

# squid -k parse

Si no se ejecuta correctamente hay que comprobar los permisos de todos los directorios de caché y de logs
dados en el archivo de configuración.

A continuación arrancar el servicio utilizando la orden siguiente:

# service squid start

# systemctl start squid

Si se necesita reiniciar para probar cambios hechos en la configuración, ejecutar:

# service squid restart

# systemctl restart squid

Asimismo podemos comprobar si el servicio está iniciado o detenido con la orden:

# service squid status

Si se necesita verificar el estado del proceso Squid se pueden utilizar las órdenes top y ps. Por ejemplo:
# top

# ps aux | grep squid

Podemos comprobar que squid se esta ejecutando y escuchando peticiones en el puerto 3128 con la orden:

10 de 41
 UD 7 Servidores proxy

# netstat -atunp | grep squid

Importante 1
Antes de editar y manipular cualquier archivo de configuración de cualquier herramienta o servicio hay que
hacer una copia de seguridad del mismo.

Se puede copiar con el mismo nombre y añadir al final el texto 'origen'. Por ejemplo:

# cp /etc/squid/squid.conf /etc/squid/squid.conf.original

Ahora ya podemos copiar el archivo de configuración de squid básico y trabajar con el.

Recordar que para copiar como usuario normal un archivo de root desde el entorno gráfico hay que
hacerlo desde una instancia de Nautilus ejecutada en una terminal con sudo.

11 de 41
 UD 7 Servidores proxy

Instalación y configuración de un cliente proxy

Los clientes proxy se pueden configurar en cualquier navegador web especificando la dirección del servidor proxy que se
quiere utilizar.

En Firefox vamos a las Preferencias > General > Configuración de la conexión especificamos si solo queremos aplicar el
proxy para protocolo HTTP o si queremos aplicar también para protocolos como SSL (puerto 443) y otros.

Para comprobar el funcionamiento de Squid creamos una máquina virtual “cliente” que se conectará a Internet a través
del servidor proxy. Para ello tenemos que configurar un navegador como cliente para que se conecte a través del proxy.

Firefox: ir a Preferencias > General > Configuración de la conexión y seleccionamos la opción Configuración
manual del proxy. En Proxy HTTP incluimos la IP de nuestro servidor de Squid y el puerto 3128.

También podemos marcar la casilla Usar el mismo proxy para todo.

Internet Explorer: ir a Menú Herramientas > Opciones de Internet > Conexiones > Configuración de LAN

Aquí se marca la casilla de "Usar servidor proxy", y se indica la dirección IP del proxy y puerto el 3128 (que es el que
se ha indicado a Squid).

Para comprobar que el proxy funciona, en el servidor de Squid abrir una terminal y observar con la siguiente orden cómo
el log de Squid se va llenando mientras se navega por Internet:

$ sudo tail -f /var/log/squid/access.log

OJO: el directorio es /var/log/squid/

12 de 41
 UD 7 Servidores proxy

Configuración del almacenamiento de la caché de un

proxy

En un servidor proxy se pueden cambiar las características de la memoria caché:

Especificando un alojamiento de memoria caché diferente.

Cambiando el tiempo que deben permanecer los archivos en memoria.
Cambiando el espacio que se liberará cuando se quiten los archivos más antiguos.
Cambiando los tiempos tras los que se guarda la información.

En el servidor Squid, estas características se gestionan mediante parámetros en el archivo de

configuración /etc/squid3/squid.conf. Algunas de estas directivas ya se han introducido en
apartados anteriores.

cache_dir ufs /var/spool/squid 500 16 256

Especifica el tamaño que necesita Squid para el almacenamiento de la caché en el disco duro y el
directorio utilizado. En este caso se utilizarán 500 MB, en 16 directorios y 256 niveles cada uno.
cache_mem 500 MB

Especifica el tamaño de la memoria RAM dedicada al almacenamiento de los bloques de la caché

más solicitados. Se establecen 500 MB, si el servidor tiene mucha memoria se puede aumentar
este valor, aunque debería ser suficiente.
maximum_object_size 4096 KB

Define el tamaño máximo de los objetos almacenados en caché. Si se supera este tamaño, los
objetos no se almacenarán, cuanto menor sea el tamaño mayor será la velocidad de trabajo.
reference_age 1 month

Acota el tiempo que deben permanecer los objetos en la caché. En este caso 1 mes, la elección
dependerá de cada caso particular, un tiempo demasiado bajo puede desaprovechar las
prestaciones y demasiado alto puede saturar la memoria.

13 de 41
 UD 7 Servidores proxy

Configuración de filtros
Una de las ventajas de utilizar un proxy es la posibilidad de utilizar filtros de contenidos para poder discriminar los sitios a
los que tienen acceso los clientes del servidor.

Los filtros se pueden crear mediante listas de control de acceso al proxy, permitiendo el paso por el proxy a las peticiones
de conexión aceptadas por la política de seguridad y denegando las demás.

En el servidor Squid una lista de control de acceso tiene la sintaxis:

acl nombre_lista tipo_de_filtrado parámetros

1. ACL

El tipo de filtrado que puede realizar una acl se puede especificar con parámetros:

Para especificar la red local:

acl redlocal src 192.168.112.0/24
La lista denominada redlocal incluye a todos los equipos que están en la red de tipo C 192.168.112.0

Para especificar una red destino:

acl destino dst 192.168.0.0/24
La lista destino es la que tiene como equipos en la red 192.168.0.0

Para especificar una franja horaria:

acl horario time MWF 8:00-14:00
La lista horario especifica una franja horaria entre las 8 y las 14 de los días lunes, miércoles y viernes.

La sintaxis utilizada para los días de la semana es:

S Domingo

M Lunes

T Martes

W Miércoles

H Jueves

F Viernes

A Sábado

Comprobar el nombre del dominio:

acl prohibidas dstdomain google.com

La lista prohibidas comprueba el dominio google.com

Ejemplos de reglas de este tipo son:

Especificar todos los equipos de la red:

acl todos src 0.0.0.0/0.0.0.0

0.0.0.0/0.0.0.0 indica cualquier red y en esta versión de Squid se sustituye por 'all' quedando:

acl todos src all

Especificar a nuestro equipo como origen de las conexiones:

acl localhost src 127.0.0.1

Especificar a nuestro equipo como destino de las conexiones:

acl localhost_destino dst 127.0.0.1

Especificar un puerto o lista de puertos usados en la petición HTTP:

acl puertos_seguros port 80 21 443 563 70 210 1025-65535

acl puerto_ssl port 443

14 de 41
 UD 7 Servidores proxy

Para crear una acl basada en el tipo mime utilizamos el filtro req_mime_type. Esta en concreto se utiliza para
comprobar el tipo de petición mime que realiza un cliente, y se puede utilizar para detectar ciertas descargas de
ficheros o ciertas peticiones en túneles HTTP.

Por ejemplo para identificar contenido flash que tiene el tipo mime application/x-schockwave-flash, escribimos:

acl flash req_mime_type -i ^application/x-shockwave-flash$

Para crear una ACL basada en la URL completa:

acl urls_permitidos url_regex ^http://www.squid-cache.org/Doc/FAQ/$

El tipo url_regex también se puede usar para crear controles de acceso basados en palabras dentro del URL:

acl urls_descargas url_regex -i rapidshare megaupload

El tipo de ACL urlpath_regex esta basado en la ruta de la URL solicitada, es decir, quita la parte del protocolo y el
hostname. Por ejemplo, si el cliente solicita la URL

http://www.example.com/downloads/music/featured.mp3

la coincidencia afectaría solo a la parte de

/downloads/music/featured.mp3.

Para crear un ACL para extensiones de archivos multimedia use el ACL:

acl archivos_multimedia urlpath_regex -i \.mp3$ \.mp4$ \.wma$ \.avi$ \.wmv$ \.mov$

\.mpg$ \.mpeg$ \.ram$ \.vob$

Se puede indicar la lista en un archivo:

acl archivos_multimedia urlpath_regex -i "/etc/squid/archivos_multimedia.acl"

2. HTTP_ACCESS

Una vez definida la lista de control es necesario activarla y para ello se emplea el parámetro http_access.

Sintaxis:

http_access allow/deny nombre_lista ...

Si se utiliza el modificador ! delante del nombre de la lista indica lo opuesto a lo dado en la lista de control de acceso.

http_access allow !horario

http_access deny horario

La primera regla permite el acceso fuera de las condiciones de la lista horario.

La segunda regla deniega el acceso en las condiciones de la lista horario.

Se puede usar el método CONNECT para realizar un túnel hacía un puerto TCP, por ejemplo para realizar un tunel y
conectarse a un sitio seguro vía HTTPS (TCP/443). Hay que tener en cuenta que debe existir definida una acl llamada
CONNECT (mirar en Ejemplos).

http_access deny !puertos_seguros

http_access deny CONNECT !puerto_ssl

Podemos indicar que a la red local no le permitimos ciertas descargas. En este caso referenciamos a varias acls que se
complementan:

http_access allow redlocal !urls_descargas !archivos_multimedia

Para el caso del contenido flash podemos utilizar la directiva http_reply_access que afecta a la respuesta del
servidor:

http_reply_access deny flash

Por último:

http_access deny all

Indica que por defecto cualquier paquete que no cumpla ninguna de las condiciones anteriores será denegada por
defecto.

15 de 41
 UD 7 Servidores proxy

Importante
Al igual que en iptables con el comando -A se encadenaban las reglas que se iban creando y por lo tanto el
orden en que se ejecutaban importaba, ahora en el proxy el orden en que se establezcan las directivas
http_access es determinante.

No tiene sentido, por ejemplo, hacer allow de toda la red local y mas adelante hacer un deny sobre alguna
acl que afecta a la red local. En ese caso la petición ya habrá pasado y salido del cortafuegos y el deny no
hará nada.

16 de 41
 UD 7 Servidores proxy

Ejemplos

IMPORTANTE
Antes de comenzar, hay que configurar el Firefox para poder obtener los resultados que buscamos. Ir a las
Preferencias del navegador.

Activar la opción de Configuración manual del proxy poniendo como IP la de la propia máquina real y puerto
3128.

Para hacer las pruebas hay que adaptar el archivo de configuración a las IP utilizadas por el alumnado.

Ejemplos (independientes)
1. Definición de la ACL con direcciones IP correspondientes a la red local:

acl redlocal src 192.168.112.0/255.255.255.0

2. Definición de la ACL con las direcciones IP de los equipos de la red local almacenadas en el archivo
/etc/squid/redlocal (una IP por línea):

acl redlocal src "/etc/squid/redlocal"

3.Definición de la ACL que deniega el acceso a google:

acl denegadas dstdomain www.google.com

4. Ejemplos de utilización de time:

Define un marco horario de lunes a viernes de 9 a 17h:

acl horario time MTWHF 9:00-17:00

Define un marco horario de 9 a 14h para cualquier día de la semana:

acl mañana time 9:00-14:00

5. Ejemplos de utilización de url_regex:

Define un patrón que identifica URLs que contienen la cadena gva

acl generalidad url_regex gva

Define un patrón que identifica URLs que contienen el carácter (?). El patrón establecido lleva el
carácter '\' delante ya que, al ser '?' un carácter comodín del shell si se le quiere eliminar este
significado debe ir con escape '\'.

acl interrogante url_regex \?

6. Permitir el acceso a Squid a los equipos incluidos en la ACL llamada redlocal.

http_access allow redlocal

7.Si dentro de redlocal hay equipos a los que no se quiere dar acceso se utiliza el carácter (!) para
excluirlos. Se crea otra ACL con las máquinas no permitidas (archivo 'no_permitidos') y se escribe:

http_access allow redlocal !no_permitidos

Cuando denegamos una condición particular dentro de la red local la correspondiente línea http_access se
debe colocar antes de la línea que permite todo a la red local.

8. Bloqueo de páginas HTTPs: Squid da opción a seleccionar el puerto 443 (o el 80) para luego aceptar o
denegar conexiones a ellos.

acl CONNECT method CONNECT

17 de 41
 UD 7 Servidores proxy

acl puerto443 port 443

acl itaca dstdomain itaca.edu.gva.es

Con http_access podemos luego:

http_access deny itaca

http_access deny CONNECT puerto443 itaca

http_access allow redlocal

Donde lista_blanca será una acl que indicará sitios web a los que se quiere permitir acceder a través de los
puertos 80 y/o 443.

CONNECT es el método utilizado para la creación de túneles cifrados. Para utilizar esta restricción debe
existir siempre una acl que defina ese método tal y como se indica arriba.

Configuración básica de Squid

Vamos a definir las ACLs y las reglas de control de acceso correspondientes para una configuración mínima
del proxy en un servidor que tiene dos interfaces de red. Una de ellas atiende a la red local 192.168.1.0/24 y
la otra da acceso a Internet.

A. Creación de las ACL básicas para una configuración mínima:

acl todo src all

acl manager proto cache_object

acl localhost src 127.0.0.1

acl redlocal src 192.168.112.0/255.255.255.0

Explicación de cada una de ellas:

1. La primera ACL, llamada todo, comprende todas las redes. Una configuración mínima debe incluirla
siempre. De esa forma, una vez permitidos los accesos a Squid que interesan, se puede con esta ACL
denegar los que procedan de cualquier otra red.

2. La segunda ACL, llamada manager, es muy importante. En ella se establece que la comunicación
entre el administrador de la caché y Squid se hace mediante el protocolo cache_object. Una
configuración mínima debe incluirla siempre.

3. La tercera ACL, llamada localhost, identifica la propia máquina.

4. La cuarta ACL llamada redlocal, identifica la red local del aula.

B. Creación de las reglas de control de acceso correspondientes a las ACL generadas:

http_access allow localhost

http_access deny manager !localhost
http_access allow redlocal
http_access deny todo

Explicación de cada una de ellas:

1. La regla http_access aplicada sobre la ACL llamada localhost indica que está permitido el acceso a
Squid para todas las peticiones HTTP originadas desde la IP 127.0.0.1.

2. La regla http_access aplicada sobre las ACL llamadas manager y localhost bloquea el protocolo
específico ‘cache_object’. Este protocolo, propio de Squid, devuelve información de cómo está
configurada la caché. Por ello se deniega cualquier petición que intente utilizar ese protocolo menos a
localhost (por eso lleva el carácter '!').

3. La regla http_access aplicada sobre la ACL llamada redlocal indica que está permitido el acceso a
Squid para todas las peticiones HTTP cuyo origen sea la red 192.168.1.0/24.

4. La regla http_access aplicada sobre la ACL llamada todo indica que no está permitido el acceso a
Squid desde cualquier IP que no sea de las dadas en las líneas anteriores. Si esta línea estuviera la

18 de 41
 UD 7 Servidores proxy

primera dejaría sin efecto a las restantes.

A continuación incluimos un ejemplo de configuración básica de squid.conf:

#Configuracion básica SQUID

#Parametros administrativos

visible_hostname pc11

http_port 3128

cache_dir ufs /var/spool/squid/ 1000 16 256

access_log /var/log/squid/access.log squid

cachemgr_passwd password all

cache_effective_user proxy

dns_nameservers 8.8.8.8 8.8.4.4

hosts_file /etc/hosts

#Configuración personal

acl all src all

acl manager proto cache_object

acl localhost src 127.0.0.1

acl redlocal src 192.168.112.0/24

http_access allow localhost redlocal

http_access deny manager !localhost

http_access deny all

19 de 41
 UD 7 Servidores proxy

Métodos de autenticación en un proxy

Autenticación
El protocolo HTTP soporta cuatro métodos de autenticación:

1. Básica: autenticación de acceso básica. Es un método diseñado para permitir a un navegador web, u
otro programa cliente, proveer credenciales en la forma de usuario y contraseña cuando se le solicita
una página al servidor. Las contraseñas viajan del cliente al proxy en texto plano, por lo que es un
método de autenticación muy inseguro.
2. NTLM: NT LAN Manager, un protocolo de seguridad de Microsoft.
3. Digest: uno de los métodos que los servidores usan para negociar credenciales con el navegador de
un usuario. Es un método algo más seguro que la autenticación básica: en lugar de enviar
contraseñas en texto claro, se les aplica un algoritmo de codificación hash antes de enviarlas a la red.
4. Negotiate: otro protocolo de autenticación de Microsoft.

A partir de la versión 2.6 Squid soporta los cuatro métodos de autenticación mencionados.

Autenticación básica
Un proxy puede exigir que un usuario se autentique antes de poder permitir el acceso. Esta opción permite
controlar a los usuarios que hacen uso del proxy, mejorando la seguridad.

Existen varios mecanismos de autenticación. De ellos solo se verá el 'básico'.

Autenticación de acceso básica

Es un método diseñado para permitir a un navegador web, u otro programa cliente, proveer credenciales en
la forma de usuario y contraseña cuando se le solicita una página al servidor. Las contraseñas viajan del
cliente al proxy en texto plano, por lo que es un método de autenticación muy inseguro.

Para utilizar la autenticación básica seguiremos los siguientes pasos:

1. Abrir con un editor de texto el archivo de configuración de Squid (/etc/squid/squid.conf) y buscar la línea
que comienza por auth_param basic program.

Tenemos que descomentar la línea y completarla con la siguiente estructura:

auth_param basic program rutaDelPrograma rutaFicheroPasswords

En nuestro caso la línea quedará así:

auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd

Este parámetro indica el módulo de software utilizado en la autenticación y la ruta que lo contiene, así
como la ruta del archivo que contendrá las contraseñas de los usuarios.

2. El fichero /etc/squid/passwd no existe. Hay que crearlo y añadirle dos usuarios con la orden
htpasswd de la siguiente forma:

$ sudo htpasswd -c /etc/squid/passwd antonio

Sólo es necesario el parámetro -c al crear el primer usuario, de modo que el segundo lo añadiremos
con la orden:

$ sudo htpasswd /etc/squid/passwd maria

3. Descomentar las siguientes líneas también, y en la línea que comienza con auth_param basic realm
modificar el mensaje que aparecerá cuando al usuario se le solicite su contraseña:

auth_param basic children 5

auth_param basic realm SERVIDOR PROXY SQUID

20 de 41
 UD 7 Servidores proxy

auth_param basic credentialsttl 2 hours

auth_param basic casesensitive off

El primer parámetro indica el número de procesos de autenticación que se van a producir.

El segundo parámetro indica cuál será el mensaje que aparecerá cuando se requiera el
usuario y la contraseña.
El tercer parámetro especifica el tiempo que tardará el proxy en especificar de nuevo la
clave a los usuarios.
La última línea crea una lista de control con la que se activa la solicitud de autenticación de
los usuarios.

4. Buscar la sección de ACLs del archivo de configuración de Squid, crear una ACL para autenticar a los
usuarios y la aplicamos:

acl ncsa_users proxy_auth REQUIRED

http_access allow ncsa_users

5. Guardar los cambios en el archivo de configuración y reiniciar el servicio Squid.

En caso de que no esté instalada la utilidad htpasswd se necesitará instalar el paquete apache2-
utils, que es donde se encuentra.

Al abrir el navegador el servidor solicita un nombre de usuario y contraseña. Comprobar.

Al revisar el log de Squid, además ahora se puede ver el nombre de usuario para cada petición.
Comprobar.

21 de 41
 UD 7 Servidores proxy

Proxy transparente

Configuración de Squid
Squid configurado como proxy transparente enruta las conexiones al proxy sin hacer ninguna configuración
en los clientes para que tengan salida a Internet. Las máquinas de la red interna utilizan como puerta de
enlace la máquina que actúa como proxy.

Se trata de un proxy externo ya que el que quiere controlar es una entidad externa.

Este tipo de configuración depende de reglas del cortafuegos.

Parámetro http_port

Solamente habrá que configurar este parámetro para que se un proxy transparente. Se le debe indicar la IP
del servidor squid, puerto de escucha y la palabra transparent.

http_port 3128

por

http_port 192.168.112.1:3128 transparent

Reglas del cortafuegos

Para poder configurar el proxy transparente hay que configurar reglas de cortafuegos. En nuestro caso
serán reglas de IPtables.

La regla en concreto que habrá que añadir en nuestro script iptables es la siguiente:

iptables -t nat -A PREROUTING -i eth1 -p tcp –dport 80 -j REDIRECT --to-port

3128

Con esto estamos desviando el trafico que venga por la LAN hacia el puerto 80 que vaya al puerto 3128.

Con esto ya hicimos transparente nuestro proxy pero no se pueden desplegar las paginas seguras, para
eso necesitamos aplicar otras reglas en iptables liberando el puerto 443, y lo hacemos de la siguiente
manera:

iptables -t nat -A PREROUTING -i eth1 -p tcp –dport 443 -j REDIRECT --to-port

3128

Esta última regla enmascara la red del aula:

iptables -t nat -A POSTROUTING -s 192.168.112.0/24 -o eth0 -j MASQUERADE

Es importante confirmar que el script iptables contienen la orden que habilita el reenvío de paquetes dentro
de la red. Poner a 1 el contenido del archivo:

# gedit /proc/sys/net/ipv4/ip_forward

22 de 41
 UD 7 Servidores proxy

Proxy inverso
Nos planteamos ahora cómo podemos controlar a los usuarios que acceden desde el exterior a nuestro servidor. Esto
se consigue utilizando los proxys inversos.

El proxy inverso también se denomina Web Server Accelerator, porque agiliza la conexión a servidores web. La utilización
de proxies inversos es útil en situaciones en las que se encuentren varios servidores en la red interna y exista una única
conexión a Internet, y se desee acceder a estos servidores web desde Internet.

Para configurar un proxy como inverso debe escuchar en el puerto 80, tiene que realizar tareas de host virtual, hay que
proporcionarle permisos de acceso a la red interna y ordenarle que se conecte en forma directa.

Para ello se modifica el archivo de configuración /etc/squid/squid.conf indicando la dirección IP pública y el

puerto 80 y que va a ser un host virtual.

http_port A.B.C.D:80 vhost vport

Una medida de seguridad es obligar al proxy a que resuelva solamente las direcciones URL que se especifiquen, para
ello se añade una lista de control del tipo siguiente indicando las webs permitidas en un archivo, una por línea:

acl internas dstdomain "/etc/squid/webpermitidas.txt"

http_access allow internas

Por último se le especifica que se conecte de forma directa hacia la red interna:

acl conex-directa dst 192.168.112.0/24

always_direct allow conex-directa

En el curso solo se nombra este tipo de proxy a efectos de información per no se va a trabajar con ellos en los casos
prácticos.

23 de 41
 UD 7 Servidores proxy

Monitorización
Existen varios mecanismos para hacer un seguimiento de la actividad de Squid. En primer lugar se comentan los
propios archivos de log de que dispone la herramienta y, a continuación se detalla una herramientas que, haciendo uso
de la información almacenada en estos archivos, generan informes completos de actividad.

Para ello hay que configurar el proxy para que cree archivos de log.

Las pruebas de funcionamiento de un proxy necesitan de un cliente y un servidor proxy configurados adecuadamente. Es
necesario configurar el navegador de cliente de manera que todas las conexiones del mismo pasen a través del proxy,
especificando la dirección IP del proxy y el puerto por donde escucha.

Archivo /var/log/squid/cache.log

Para saber si Squid está funcionando correctamente es suficiente visualizar las últimas entradas del archivo /var/log/squid
/cache.log, ya que en él se reflejan todas las incidencias en el arranque del servicio, problemas de funcionamiento e
incidencias en la parada del servicio.

Para visualizar las últimas entradas del archivo se utiliza la orden tail:

# tail /var/log/squid/cache.log

que muestra las últimas incidencias. Si aparece alguna línea con errores explica por qué y una indicación de lo que se
debe hacer. Admite la opción -f para hacer un seguimiento por pantalla del funcionamiento de Squid.

# tail - f /var/log/squid/cache.log

Archivo /var/log/squid/access.log

Este archivo contiene todas las peticiones servidas por el proxy a los navegadores web (clientes). Si se detectan
problemas de acceso por parte de alguno de los clientes se puede consultar el archivo access.log de la forma siguiente:

# more access.log | grep DENIED

Son ejemplos de líneas de este archivo access.log las siguientes:

..............................
1121261951.828 176 192.168.1.2 TCP_MISS/302 1114 GET http://mail.google.com/mail/
- DIRECT/64.233.171.83 text/html

1121260798.368 143 192.168.1.2 TCP_HIT/200 2127 GET http://www.ono.com/Cinerama

/Scripts/cookies.js - NONE/- application/x-javascript

................................

Las líneas de este archivo de log contienen una serie de códigos que empiezan por TCP_ indicando que son peticiones
HTTP.

TCP_ HIT: esta petición se atenderá desde al caché porque hay una copia disponible.

TCP_MISS: se realizará una búsqueda nueva porque no hay copia en la caché.

TCP_REFRESH_HIT: se va a buscar de nuevo el objeto porque el que estaba almacenado en la caché es muy
antiguo.
TCP_REF_FAIL_HIT: el objeto de la caché era antiguo, se buscó uno nuevo y falló la búsqueda.
TCP_CLIENT_REFRESH: este mensaje nos indica que el cliente abre una página que tiene orden de obtener
siempre un archivo nuevo.
TCP_CLIENT_REFRESH_MISS: el cliente solicita el refresco de una web.
TCP_IMS_HIT: el cliente ha solicitado una nueva versión de un objeto que estaba cacheado, pero se encuentra que
el objeto de la caché aún no estaba caducado, es decir, que ya era lo más nuevo posible.
TCP_IMS_MISS: el cliente solicita nueva copia acerca de un objeto viejo.
TCP_SWAPFAIL: se cree que el objeto se encuentra en la caché, pero por alguna razón no se puede acceder.
TCP_DENIED: se deniega el acceso a la petición.
TCP_DENIED/400: por mala sintaxis.
TCP_DENIED/401: por no estar autorizado.
TCP_DENIED/403: por ser un sitio bloqueado por una acl.

Los códigos de resultado de las peticiones más importantes son DIRECT cuando la página web solicitada se trae
directamente del servidor remoto y NONE cuando la página web solicitada está en la caché.

24 de 41
 UD 7 Servidores proxy

Herramientas de análisis de registros

Sarg
Introducción

Existen múltiples herramientas que permiten analizar los registros (logs) de Squid, como Lightsquid, Sarg,
sqstat o squid-graph.

Se ha elegido Sarg, una herramienta que genera informes de Squid que permite ver fácilmente qué usuarios
han accedido a qué sitios, a qué horas, cuántos bytes han sido descargados, relación de sitios denegados,
fallos de autenticación, etc.

Características

Mediante los informes de Sarg podemos obtener de forma clara y organizada toda esta información:

Top 100 de páginas web más visitadas.

Informes diarios, semanales, mensuales...Gráficas que muestran el consumo por usuario/host.
Detalles de todas las páginas web que ha visitado un usuario.
Errores de autenticación.
Descargas.

Instalación y configuración

Sarg se encuentra en los repositorios de Ubuntu, por lo que puede ser instalado a través del Software de
Ubuntu o apt install.

$ sudo apt install sarg

Si queremos que se pueda acceder a los informes de Sarg en el navegador debemos instalar también el
servidor Apache2, que también está en los repositorios:

$ sudo apt install apache2

Para que el programa funcione tenemos que editar el archivo de configuración, que se encuentra en
/etc/sarg/sarg.conf.

La configuración básica es la siguiente:

access_log /var/log/squid/access.log

title “Informes de acceso de Squid”

output_dir /var/www/html/squid-reports

resolve_ip yes

date_format e

lastlog 10

access_log: ruta del fichero de log donde Squid registra los accesos por defecto.
title: título que mostrará Sarg cuando se acceda por la web. Hemos puesto 'Informes de SQUID'.
output_dir: salida donde se van a mostrar los informes de Sarg.
resolve_ip: si en los registros aparece la IP o si se intenta resolver el dominio.
date_format: para elegir el formato de la fecha y la hora (en nuestro caso europeo: dd/mm/aaaa).
lastlog 10: indica el nº de informes que almacenará

Algunas opciones importantes:

Opción Descripción

-h Muestra un resumen de las opciones disponibles

-a Limita el informe a los registros generados por una determinada

IP. La sintaxis es:

sarg -a [nombre_máquina | dirección IP]

25 de 41
 UD 7 Servidores proxy

Opción Descripción

-l Indica el archivo de log que tiene que utilizar la orden sarg como
entrada. La sintaxis es:

# sarg -l archivo

-d Indica la fecha o intervalo de fechas para la elaboración del

informe, según el formato siguiente dd/mm/yyyy-dd/mm/yyyy.
Ejemplo:

# sarg -d 1/12/2014-31/12/2015
-o Indica el directorio donde se quiere dejar el informe generado. La
sintaxis es:

# sarg -o directorio
-u Limita el informe a la actividad de los usuarios. La sintaxis es:

# sarg -u nombre_usuario

Generación de informes

Para generar informes con Sarg de forma manual podemos empezar por generar un informe de los accesos
en fechas determinadas. Para ello utilizaremos la orden: sarg -d intervalo-fechas.

$ sudo sarg -d 18/01/2015-21/01/2015

Esta orden genera un informe con todos los accesos producidos en el intervalo de fechas especificado.

Comprobar que sale un mensaje indicando que falta un tipo de letra. Es importante instalar dicho fuente ya
que de lo contrario no veremos el informe. Para ello ejecutar:

$ sudo apt install ttf-dejavu-core

Podemos ver la lista de todos los informes que hayamos generado yendo a http://localhost/squid-
reports, o bien desde un cliente yendo a http://squid-server/squid-reports.

Si hacemos clic en un informe podemos ver las estadísticas organizadas por usuario, con información sobre
el número de conexiones, datos descargados, tiempo transcurrido, uso de la caché, etc.

Al hacer clic en un usuario podemos ver en detalle qué páginas ha visitado, la cantidad de datos
descargada, etc.

En cada informe Sarg también nos permite ver la lista de las 100 páginas más visitadas (topsites).

Proporciona una lista de páginas web visitadas y qué usuarios han sido los que han accedido a ellas (sites
& users).

26 de 41
 UD 7 Servidores proxy

Sarg también puede mostrar el informe de todos los errores de autenticación que se hayan registrado.

Se pueden crear informes más específicos. Podemos generar un informe de un usuario determinado con la
orden:

$ sudo sarg -u usuario

Otra opción muy útil es generar informes por URL. Podemos incluir varias separadas por comas:

$ sudo sarg -s url1,url2

Webmin-Sarg

También es posible utilizar Sarg desde Webmin. Para ello hay que instalar el módulo de webmin llamado
sarg desde la propia herramienta en la Configuracion de módulos.

Una vez instalado el módulo, desde el navegador web abrir Webmin desde la URL https://localhost:10000/.
Y, desde allí, para acceder a Sarg ir a:

Servidores > Squid Analysis Report Generator

y proceder a realizar la configuración de Sarg en entorno gráfico si se prefiere.

NOTA

Para comprobar estos informes hay que instalar la herramienta Webmin disponible desde
http://www.webmin.com/download.html. Comprobar como con esta herramienta gráfica se puede
también llevar a cabo la configuración del propio Squid así como de otros servicios de red.

Calamaris: visor de logs

Introducción

Calamaris es una aplicación escrita en lenguaje Perl que genera informes de actividad de la caché (en
formatos HTML y ASCII) a partir de los archivos de log de Squid.

Para instalar la aplicación ejecutar la orden siguiente:

# apt install calamaris

El archivo de configuración de Calamaris es /etc/calamaris.conf y en él se puede establecer el tipo de
periodicidad con que se quieren obtener los informes: diario, semanal o mensual (uno de ellos). Por defecto
es diario.

Una vez instalada la aplicación, desde el navegador web acceder a Webmin desde la URL
https://localhost:10000/. Y, desde allí, para acceder a Calamaris ir a:

Servidores > Servidor Proxy Squid > Análisis de historial de calamaris

Se muestra un informe completo de actividad del servidor Squid, indicando porcentajes de peticiones
servidas por el proxy-caché y las condiciones bajo las que se llevaron a cabo. Es decir, si la página web
solicitada estaba en caché o se ha tenido que solicitar al servidor, etc., según los códigos vistos en el punto
anterior.

La captura siguiente muestra un informe de actividad elaborado por Calamaris.

27 de 41
 UD 7 Servidores proxy

28 de 41
 UD 7 Servidores proxy

Casos prácticos

Sugerencias
Para la realización de los casos prácticos es suficiente instalar el servidor proxy Squid en la maquina que
hará tambien de cliente, ajustando las Preferencias del navegador a la situación.

Tambien se pueden realizar entre máquina virtual y anfitriona o entre dos maquinas virtuales,

Se deja al criterio del alumno utilizar un modelo u otro.

Hay que tener en cuenta el tema de la caché de Squid y la cache del navegador. Limpiar regularmente la
cache del navegador para no interferir en el funcionamiento del proxy.

Recordar que cuando realmente esta actuando nuestro servidor proxy deberá mostrar el mensaje standar
de Squid con su logo correspondiente. Cualquier otro mensaje del navegador web de denegación de la
conexión puede ser debido a otras causas y se deberá revisar la configuración tanto del proxy como del
navegador. Las capturas con este tipo de mensajes no serán válidas.

29 de 41
 UD 7 Servidores proxy

CP -1- Filtrado de descargas

Filtrado de descargas (música, vídeos,

ejecutables...)
Introducción

Se quiere bloquear la descarga de determinados tipos de archivo por diversas razones: seguridad, evitar
excesivo consumo de ancho de banda, evitar virus, etc.

Esto se puede conseguir mediante las listas de control de acceso.

Si queremos bloquear la descarga de vídeos, música y ejecutables podemos filtrar, por ejemplo, los
siguientes tipos de archivo:

mp3
mpeg
mpg
avi
exe
flv

Para ello tenemos que seguir los siguientes pasos:

1. Abrir con un editor el archivo de configuración de Squid (/etc/squid/squid.conf) y buscar la sección

del archivo donde se encuentran las ACLs. Se puede utilizar el archivo básico de configuración disponible
en la carpeta de archivos de la unidad.

Tenemos creada la acl que identifica la red local:

acl redlocal src 192.168.112.0/24

Crear una nueva ACL llamada 'nodescargas' que bloquee la descarga de lo especificado en el fichero de
texto /etc/squid/reglas/nodescargas.acl:

acl nodescargas urlpath_regex -i "/etc/squid/reglas/nodescargas.acl"

2. Creamos el fichero de texto /etc/squid/reglas/nodescargas.acl con un editor y añadimos el

siguiente contenido (no copiar y pegar desde el pdf):

\.exe$

\.avi$

\.flv$

\.mpeg$

\.mpg$

\.mp3$

3. Añadimos la regla que bloquea el acceso a las descargas:

http_access deny redlocal nodescargas

Se puede utilizar la directiva http_reply_access si se quiere bloquear la respuesta desde el servidor.

4. Guardamos los cambios en el archivo de configuración y reiniciamos el servicio Squid. Comprobar que,
cuando se quiere descargar un tipo de archivo prohibido (por ejemplo .flv), Squid no lo permite.

5. Se puede comprobar en el log de Squid cómo se ha rechazado la conexión (TCP_DENIED).

Tarea:

1. Seguir los pasos indicados y comprobar que los filtros funcionan accediendo a diferentes páginas para
descargar archivos de los tipos indicados.

2. Crear al menos cuatro capturas para algunos de los tipos de archivos indicados .

30 de 41
 UD 7 Servidores proxy

3. Hacer una captura que muestre algún log de denegación.

31 de 41
 UD 7 Servidores proxy

CP -2- Filtrado de páginas web HTTP

Caso práctico -2- Filtrado web

Introducción:

Vamos a configurar Squid para impedir la conexión a ciertas páginas http aplicando algunas restricciones
adicionales.

1. Crear un filtro para las siguientes páginas web: aemet.es, cadenaser.com, fdmvalencia.es
(federación deportiva municipal). En concreto a la página deportiva no se permite la conexión de lunes a
jueves de 10 a 14h.

En el archivo de configuración de Squid /etc/squid/squid.conf (se puede utilizar el archivo básico de

configuración disponible en la carpeta de archivos de la unidad) añadir las acls:

acl bloquear dstdomain aemet.es

acl bloquear dstdomain cadenaser.com

acl bloquear dstdomain fdmvalencia.es

Crear la ACL que falta y organizar el archivo de configuración con todas las ACLs y las directivas
HTTP_ACCESS.
OJO!!

Recordar que el orden de las ACLs no importa pero en la directiva HTTP_ACCESS es determinante
que estén bien ordenadas.

2. Escribe las órdenes que hay que utilizar para requerir credenciales al usuario1
obligándole a introducir una contraseña para conectar con el proxy.

2.1 En primer lugar creamos el usuario y contraseña, guardándolo en el archivo de usuarios Squid.

$ htpasswd -c /etc/squid/passwd usuario1

2.2 Descomentamos el módulo necesario en el archivo de configuración de Squid.

auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd

2.3 Agregamos las reglas necesarias

auth_param basic children 5auth_param basic realm AUTORIZACION REQUERIDA

USUARIO1auth_param basic credentialsttl 2 hoursauth_param basic casesensitive
off

acl password proxy_auth REQUIRED

La linea auth_param basic children 5: define cuantos procesos hijos puede abrir squid

La linea auth_param basic realm AUTORIZACION REQUERIDA USUARIO1: define el texto que se
presentará en el momento de pedir el nombre de usuario y contraseña en el navegador.

La linea auth_param basic credentialsttl 2 hours: define el tiempo de vida de las credenciales que es de
2 horas.

La linea auth_param basic casesensitive off: define si va a diferenciar entre mayúsculas y minúsculas.

La linea acl password proxy_auth REQUIRED: es una ACL llamada password que pide autenticación y
además es siempre requerida.

Por último habrá que añadir el http_access correspondiente a la ACL password para que la habilite. Lo
añadimos en la zona de los http_access para que estén agrupados y siempre después de la definición de
la ACL:

http_access allow password

Hay que tener en cuenta que se deben mantener el resto de directivas que han quedado configuradas para
nuestra red y que se ha probado que funcionan.

32 de 41
 UD 7 Servidores proxy

2.4 Probamos

Tarea:
1. Reproducir los pasos y completar las directivas que faltan.
2. Realizar capturas que muestren las ordenes ejecutadas con las condiciones establecidas así como las
líneas añadidas en el archivo de configuración de SQUID.
2. Realizar una captura que muestre el mensaje de aviso solicitando autenticación al usuario1.

33 de 41
 UD 7 Servidores proxy

CP -3- Listas negras

Caso práctico -3- Gestión de listas negras de

URL
Introducción

En el caso anterior hemos visto cómo bloquear determinadas páginas, una por una y aplicando alguna
condición especial.

Este caso práctico es similar pero las páginas las vamos a incluir en archivos que luego referenciamos en
las ACL.

Por ejemplo, se van a bloquear las páginas:

1. Cuyo nombre de dominio contiene la palabra 'juego' y 'fiesta'

2. Siguientes: .estudiomenta.com, .tuenti.com, .marca.com

Para bloquear las páginas web que hayamos especificado en una lista seguiremos los siguientes pasos:

1. Abrir con un editor de texto el archivo de configuración de Squid (/etc/squid/squid.conf) y buscar

la sección del archivo donde se encuentran las ACLs. Se puede utilizar el archivo básico de configuración
disponible en la carpeta de archivos de la unidad.

2. Crear una nueva ACL llamada, por ejemplo, 'listanegra' que bloquee las páginas especificadas en el
fichero de texto /etc/squid/reglas/listanegra.acl:

acl listanegra dstdomain "/etc/squid/reglas/listanegra.acl"

3. Crear el fichero de texto /etc/squid/reglas/listanegra.acl. El fichero contendrá direcciones de

páginas o palabras que se quieran bloquear:

.estudiomenta.com

.tuenti.com

.marca.com

Las páginas que tengan esas direcciones o que contengan esas palabras en su URL no serán accesibles. Y
al especificar las URLs como .dominio.com estamos bloqueando tanto el dominio como todos sus
subdominios.

Crear la regla ACL correspondiente para el punto 1.

4. Añadimos la regla que hace efectivo el bloqueo de las páginas:

http_access deny listanegra

Añadir el correspondiente http_access para el punto 1.

5. Guardamos los cambios en el archivo de configuración y reiniciamos el servicio de Squid.

Tras esto, cuando queramos acceder a una de las URLs prohibidas Squid, en vez de la página, nos
mostrará un error de Acceso denegado (Access denied) diciendo que hay ACLs que nos impiden acceder a
la página. Comprobar.

Esta página de error podría ser personalizada también, como en el caso visto anteriormente de las
descargas prohibidas.

6. Asimismo, podemos ver cómo en el log aparecen las conexiones rechazadas (TCP_DENIED).
Comprobar.

Tarea:

1. Realizar todos los pasos indicados. Crear la ACL y HTTP_ACCESS del punto 1.

2. Hacer capturas que muestren que al acceder a las páginas indicadas se muestra el mensaje de error.

3. Hacer al menos una captura de algún log de denegación.

34 de 41
 UD 7 Servidores proxy

35 de 41
 UD 7 Servidores proxy

CP -4- Excepciones

Caso práctico -4- Gestión de excepciones

Introducción

Crear un archivo 'sitios_denegados' con una serie de nombres de sitios a los que no se quiere dar acceso.
Es posible que hayan quedado incluidas palabras que no deberían de estar. Si algunas de ellas se conocen
de antemano crear un archivo 'permitidos' en el mismo directorio y crear la ACL y la regla de control de
acceso correspondiente que permita el acceso los sitios cuyo nombre contienen esas palabras.

acl permitidos url_regex "/etc/squid/permitidos"

http_access deny sitios_denegados !permitidos

La regla anterior especifica que se denegará el acceso a todo lo que comprenda la Lista de Control de
Acceso llamada sitios_denegados excepto lo que comprenda la Lista de Control de Acceso llamada
permitidos.

Para hacer efectivos los cambios hay que relanzar Squid:

#service squid restart

Tarea:

1. Seguir los pasos indicados utilizando como sitios denegados algunos que considere el alumno siempre
que de ellos pueda haber alguno con información de interés que pueda estar en permitidos.

2. Realizar capturas de los contenidos de ambos archivos y de las directivas incluidas en la configuración
de Squid.

3. También hacer capturas mostrando la prohibición de acceso al sitio denegado y del acceso permitido.

36 de 41
 UD 7 Servidores proxy

CP -5- Bloqueo páginas web HTTPs

Caso práctico -5- Squid y HTTPs

Objetivo:

Conocer el procedimiento para el filtrado de páginas seguras desde Squid.

Enunciado:

Se tiene instalado Squid con la configuración básica y se quiere controlar el acceso de los usuarios a
Internet, de forma que solo puedan navegar los usuarios Juan y Antonio y a los que, además, les vamos a
poner restricciones en la navegación.

Tarea:

1. Preparar Squid para que controle el acceso a la navegación de los usuarios Juan y Antonio. Solo
pueden navegar ellos.
2. Al usuario Juan se le da navegación libre exceptuando las páginas elpais.com y el correo gmail
mail.google.com
3. Al usuario Antonio se le da navegación libre exceptuando las páginas seguras que contengan en su
URL la palabra 'banco'.
4. Adjuntar capturas de las configuraciones realizadas y de los mensajes dados por Squid impidiendo el
acceso.

Nota

En el caso de páginas seguras (https) existe un certificado asociado a ellas y Squid por si solo no entiende.
El mensaje que mostrará en estos casos no será el de Squid propiamente, pero el navegador nos indicará
que el proxy está rechazando la conexión.

Con este mensaje es suficiente.

37 de 41
 UD 7 Servidores proxy

CP -6- SquidGuard

Caso práctico -6- SquidGuard

Objetivo

Controlar el acceso a páginas seguras con la herramienta SquidGuard desde la distribución PFSense.

Tarea:

Para ello descargar la distro PFSense e instalar en una máquina virtual.

Configurar Squid desde PFSense.

Instalar SquidGuard y configurar diferentes tipos de accesos a páginas seguras, permitiendo o denegando.

Denegar accesos a determinadas páginas para determinados usuarios.

Hacer capturas que muestren los resultados.

Mostrar losgs de denegación de acceso.

38 de 41
 UD 7 Servidores proxy

Enlaces

Webs de interés

Autenticación con Squid: http://wiki.squid-cache.org/Features/Authentication

Filtrado de descargas con Squid: http://www.cyberciti.biz/faq/squid-content-filter-block-files
SARG tutorial: http://www.howtoforge.com/monitoring_squid
Webmin: https://es.wikipedia.org/wiki/Webmin

39 de 41
 UD 7 Servidores proxy

Conceptos

Conceptos
Proxy-caché

Es un servidor, con esta funcionalidad instalada, situado entre la máquina del usuario e Internet, que
actúa como barrera de protección y como zona caché para acelerar el acceso a una página web.

Proxy transparente

Es un software para el filtrado de paquetes de entrada/salida situado entre una red local e Internet y del
que la red local no tendrá constancia de su existencia. Internamente consiste en una redirección de las
peticiones de la red local modificando la dirección a la que se dirige la conexión. Utiliza nat, en concreto
DNAT que hace la redirección antes de encaminar el paquete.

NAT

NAT significa Traducción de direcciones de red y su misión es enmascarar direcciones, es decir

cambiar la dirección de origen o destino de un paquete, con el objetivo de ocultar una red privada
detrás de un servidor con IP pública.

Netfilter

Netfilter es una funcionalidad del núcleo de GNU/Linux que permite (si está activada) realizar el filtrado
de paquetes.

Cortafuegos

Un cortafuegos es un mecanismo, hardware o software, de protección de redes. Puede implementarse

a través de un router, un equipo que haga de cortafuegos e incluso una red cortafuegos. Al separar la
red interna de la red externa (Internet) el cortafuegos la protege ante posibles ataques a su seguridad.
Además actúa como filtro de entrada/salida.

DMZ

Una DMZ (De-Militarized Zone) consiste en una implementación de cortafuegos más completa. El
objetivo es aislar de forma más segura una Intranet. Para ello se añade una red entre Internet y la
Intranet. Normalmente se compone de dos routers, uno interno y otro interno.

Host bastión

El 'host bastión' es realmente el cortafuegos que está entre las dos redes. Su misión es proteger la red
interna y en él se lleva a cabo la tarea de filtrado de paquetes. Debe disponer de altas medidas de
seguridad.

40 de 41
 UD 7 Servidores proxy

Videotutoriales externos

Video 1 Configuración de Squid

El siguiente vídeo (http://www.youtube.com/v/XQKp_3Yqc14?version=3&hl=es_ES&rel=0) muestra cómo
hacer una configuración del proxy Squid en Ubuntu GNU/Linux y su funcionamiento.

La versión de Ubuntu sobre la que trabaja es algo antigua, pero puede servir de referencia general.

41 de 41