3.1.- Directivas Básicas de Configuración del Proxy Squid

Práctica Nº3.-Proxy HTTP Caché. Squid

nuestro Proxy.

De igual forma, también es muy importante señalar que el Proxy no cacheará nada que sea referente al protocolo HTTPS tcp/443 al corresponderse con una comunicación cifrada, limitándose a actuar como un simple intermediario entre el cliente y el servidor final, redireccionando directamente el tráfico hacia el puerto tcp/443 a la salida del servidor Proxy, ofreciéndonos únicamente la posibilidad de filtrar las URLs indicadas vía HTTPS.

Además, el servidor Proxy nos va a permitir hacer uso de las siguientes funcionalidades: 1. Controlar tanto desde que equipos clientes se permite el acceso a Internet, como a que equipos servidores Web HTTP esta permitida la conexión, como si se tratara de un firewall. 2. Controlar la franja horaria en la que esta permitida el acceso al servicio web. 3. Obligar a los usuarios que hacen uso del servicio a una autenticación previa (Proxy no transparente). 4. Filtrar URLs y contenidos evitando que los usuarios puedan conectarse a determinados sitios Web. 5. Controlar el ancho de banda de salida a Internet consumido por los equipos clientes, garantizando una determinada calidad de servicio, QoS. 6. Informar mediante ficheros de auditoría tanto de los accesos realizados desde los clientes, como de los contenidos solicitados.

3.1.- Directivas Básicas de Configuración del Proxy Squid

Para todo ello, en la presente práctica se va a instalar el software Squid, sobre el cual habrá que configurar su comportamiento. Para ello será necesario definir listas de control de acceso (ACLs) mediante la directiva "acl", y posteriormente tomar la decisión de permitir o denegar mediante la directiva "http_access". De manera resumida, destacaríamos los siguientes tipos de ACL:

Sintaxis directiva "acl": acl nombre-acl tipo-acl descripción|fichero-descripciones Sintaxis directiva "http_access": http_access allow|deny nombre-acl

Tipo ACL Significado Ejemplo de ACL

src Source. Permite hacer referencia a un conjunto de equipos clientes. Si al definir la ACL queremos hacer referencia a cualquier equipo cliente, podemos hacer uso del valor "all". acl intranet src 192.168.1.0/24 http_access allow intranet

acl maquina1 src 192.168.1.200 acl cualquiera src all http_access deny maquina1 http_access allow cualquiera

srcdomain

Source Domain. Hace alusión a un equipo cliente basándonos en su nombre de dominio. Para la comprobación se requiere resolución inversa dst Destination destino . Hace alusión a un equipo acl eq1 srcdomain equipo1.intranet.es http_access deny eq1

acl server dst 192.168.1.200 http_access deny server

Seguridad Informática y Alta Disponibilidad – amartinromero@gmail.com 86

Práctica Nº3.-Proxy HTTP Caché. Squid

dstdomain Destination Domain

proxy_auth Nos permite establecer como requisito para poder navegar desde un cliente la autenticación previa: login y password. Con la opción "-i" no distingue entre minúsculas y mayúsculas

time

url_regex Permite especificar una franja horaria. La sintaxis es: acl nombre-acl [días] [h1:m1-h2-m2] Los días se especifican con la abreviatura del día en inglés: M (monday), T (tuesday), W (wednesday), H (thursday), F (friday), A (saturday) y S (sunday). Permite filtrar URL por palabras clave o mediante el uso de expresiones regulares. Lo más sencillo es simplemente poner una lista de palabras clave que no deseamos permitir que aparezcan en las URLs de los clientes. En el caso de que la lista de palabras clave sea muy extensa, puede hacerse uso de un archivo de texto cuyo contenido se corresponderá con dicha lista. Este archivo se indicará mediante la ruta donde se ubica encerrándola entre comillas dobles. En el caso de querer hacer uso de expresiones regulares, convendría repasar previamente su sintaxis (http://es.wikipedia.org/wiki/Expresi %C3%B3n_regular). Por ejemplo, el carácter "^" es para hacer referencia a URLs que empiezan por alguna cadena de caracteres en concreto, y "$" para indicar terminaciones de la URL. Si no se indica ningún carácter especial, la cadena de caracteres indicada se usará como patrón de búsqueda dentro de las URLs. acl google dst www.google.com acl autenticar proxy_auth REQUIRED acl todas src all http_access allow todos autenticar

acl todas src all acl grupo1 proxy_auth -i usu1 usu2 acl grupo2 proxy_auth -i usu3 http_access deny grupo2 todas http_access allow grupo1 todas

acl todas src all acl horario1 time M T W H F 9:00-18:00 acl finde time A S 9:00-13:00 http_access allow horario1 finde todas

acl maquinas src all acl palabras1 url_regex sex porn acl palabras2 url_regex "ruta_archivo" http_access deny palabras1 palabras2 http_access allow all

acl webseguras url_regex -i ^https:// acl multimedia url_regex -i mp3$ mp4$ acl videos url_regex youtube http_access allow webseguras http_access deny multimedia videos

acl a src all acl p1 url_regex sex porn acl p2 url_regex "ruta_archivo" acl w url_regex -i ^https:// acl m url_regex -i mp3$ mp4$ acl v url_regex youtube http_access allow a !p1 !p2 !w1 !w !m !v

acl todas src all acl filtro1 url_regex "ruta_archivo" acl horario1 time M T W H F 8:00-20:00 http_access allow todas horario1 !filtro1

Seguridad Informática y Alta Disponibilidad – amartinromero@gmail.com 87

Práctica Nº3.-Proxy HTTP Caché. Squid

Para este tipo de filtrado puede resultar sumamente útil el uso de la admiración "!" en el control de acceso con http_access, para indicar lo contrario a lo que hace la referencia la ACL. ¡¡Observación!! El Proxy Squid que vamos a configurar a lo largo de los ejercicios prácticos que se proponen a continuación nos van a permitir gestionar las conexiones Web que se realizar desde los equipos y usuarios que forman parte de nuestra Intranet privada. A este tipo de Proxy se le denomina Proxy Cache HTTP o directamente Proxy Web o Proxy "a secas", y hay que diferenciarlo de otros tipos de Proxy como es el Proxy SOCKS (SOCKetS), el cual esta pensado no sólo para gestionar el tráfico Web, sino para hacer de intermediario entre equipos clientes y servidores permitiéndonos gestionar cualquier tipo de conexión que sea soportada por el protocolo SOCKS (RFC 3089). Es decir, el equipo cliente tiene que ser un cliente SOCKS que implemente este tipo de protocolo específico.

Una forma sencilla de comprender como funciona un Proxy SOCKS es utilizar ssh con la opción "-D número_puerto IP_servidor_SSH", la cual nos permite hacer una redirección de puertos dinámica, convirtiendo nuestro equipo y el túnel SSH creado con el servidor, en un Proxy SOCKS redireccionando todo el tráfico de la aplicación que configuremos por el canal seguro hacía el servidor SSH que hayamos especificado, redirigiendo éste a su vez el tráfico hacia el equipo que indiquemos.

Un caso típico de uso de un Proxy SOCKS podría ser el siguiente: nos encontramos navegando por Internet en una red insegura, o con dudas relativas a que nuestras comunicaciones puedan ser husmeadas por algún "sniffer", y queremos evitarlo creando un túnel SSH cifrado seguro por el cual viajará todo el tráfico generado por nuestro navegador Web. A través de esta configuración todo el tráfico que generemos será redireccionado hacía el servidor SSH que especifiquemos y este hará de intermediario (Proxy) entre yo y los servidores a los que me conecte. Por ejemplo, supongamos que tenemos asociado un nombre de dominio público gratuito a la dirección IP pública del router de nuestra casa (p.e. micasa.no-ip.org), y que éste tiene redireccionado el puerto 22 hacía un servidor SSH que tenemos internamente (p.e. una Raspberry Pi). Al establecer el tunel SSH con el servidor haciendo uso de la opción -D, hacemos que el servidor de nuestra casa haga de Proxy entre nosotros y los servidores a los que nos conectemos durante la navegación Web.

A modo de ejemplo, a continuación se muestra como configurar un equipo cliente para hacer uso de un Proxy SOCKS local implementado mediante SSH mientras esta navegando en una red supuestamente insegura, de tal forma que todo el tráfico generado por el cliente (p.e. Mozilla Firefox integra un cliente SOCKS que soporta el protocolo SOCKS) y dirigido hacía el puerto que especifiquemos (p.e. 12345), será encapsulado y redireccionado hacía el servidor SSH, reenviándolo éste a su vez al servidor Web correspondiente.

Advertir, que en tal situación, el ancho de banda de la conexión vendrá limitado por la velocidad de upload de la línea ADSL contratada en el lado del servidor SSH.

Seguridad Informática y Alta Disponibilidad – amartinromero@gmail.com 88

Práctica Nº3.-Proxy HTTP Caché. Squid

Para ello, tan sólo necesitaremos crear el tunel SSH (en Windows haríamos uso de putty), y posteriormente configurar las opciones de nuestro navegador: [usuario-cliente@linux]$ ssh -D 12345 micasa.no-ip.org

En el caso de que hagamos uso de Mozilla Firefox (Editar → Preferencias → Avanzado → Red → Configuración), aunque podría cualquier otro tipo de navegador:

Otra opción de uso muy interesante de todo lo anterior, es usar el túnel SSH creado a modo de "VPN", ya que a través del Proxy SOCKS podemos alcanzar cualquier equipo de la Intranet donde se localiza el servidor SSH. Por ejemplo, podríamos configurar el router ADSL haciendo uso de la dirección IP privada de la Intranet que tenga asignada (p.e. 192.168.1.1):

Seguridad Informática y Alta Disponibilidad – amartinromero@gmail.com 89