MEGATUTORIAL Squid 5. Tercera Parte.

PDF

2. Configuraciones en Squid.

En esta tercera parte que sera bien extensa mostraremos la configuración de SQUID. La ordenaremos y explicaremos por bloques para una mejor comprensión. Este será un tutorial en constante evolución y desarrollo por lo que podrá sufrir grandes cambios. Se les recomienda a los lectores que lo revisen a cada rato.

ÍNDICE

Servidor Proxy. Conceptos y datos para el ejemplo a desarrollar.

1. Instalación de squid-5.0.2 por compilado.

1.1. Generando e instalando empaquetado “.deb” de squid-5.0.2.

2. Configuraciones en Squid.

2.1. Configuraciones básicas.

2.2. Proxy padre.

2.3. Caché.

2.4. Autenticación.

2.5. Patrones de refrescamiento.

2.6. Declaración de reglas (ACLs).

2.7. Aplicación de reglas.

2.8. Declaración y aplicación de otras reglas especiales.

2.8.1. Retardo con Delay Pools.

2.8.2. MITM con SSL Bump.

3. Integración de Squid-ADDC mediante Kerberos.

3.1. Configuraciones necesarias en el ADDC Samba4.

3.2. Sincronización de tiempo.

3.3. timesyncd.

3.4. ntpd & ntpdate.

3.5. Integración Squid-ADDC por Kerberos, mediante Ticket.

4. Ejemplo integrador de configuración de Squid.

4.1. Configuraciones del ejemplo.

Referencias Bibliográficas.

Primeramente, vamos a estructurar el fichero de configuración, para un mejor entendimiento del mismo. Esto hará propiciará una mejor gestión y funcionamiento:

1. Configuraciones básicas

    1.1 Escucha/salida del proxy

    1.2 Medidas de seguridad

    1.3 Parámetros administrativos

    1.4 Tiempos de Espera

    1.5 Otras Opciones

2. Proxy padre (proxy en cascada)

3. Caché

4. Autenticación

    4.1 Kerberos

    4.2 LDAP Básico

5. Patrones de refrescamiento

6. Declaración de reglas (ACLs)

6.1 Puertos

    6.2 Métodos de conexión

    6.3 Direcciones IP

    6.4 Usuarios

    6.5 Grupos de usuarios

    6.6 Tiempo

    6.7 Contenido

    6.8 Dominios

    6.9 Desencriptación de HTTPS

    6.10 Otras reglas específicas

7. Aplicación de las reglas

7.1 Logitud máxima de descarga por objeto

    7.2 Denegativas específicas

    7.3 Permisivas específicas

    7.4 Denegativas generales

    7.5 Permisivas generales

    7.6 Por defecto

    7.7Retardo

    7.8 Desencriptación de HTTPS

NOTA:Esta numeración no tiene nada que ver con la del menú del tutorial. Es la numeración interna del fichero de configuración de squid. Es la misma que veran en el ejemplo de configuración integrador de la última parte del tutorial.

En este tutorial explicaremos fragmentos de configuración, correspondientes a algunos de los puntos que forman la estructura anteriormente propuesta. La mejor manera es explicarlo es mediante un ejemplo. La situación problémica establece lo siguiente:

En una empresa la cual se encuentra tras un proxy padre, con dominio sysadmins.cu se pidió implementar un proxy con las siguientes particularidades.

Condiciones:

• Existirá un grupo de usuarios con solo navegación en la red cubana (.cu).
• Tendremos otro grupo que además de navegación nacional tendrá derecho de acceso a determinados sitios web de internet, autorizadas por el director de la empresa.
• Un grupo con acceso a internet.
• Creación de una cache local para el acceso más rápido.
• Condicionar y configurar un sistema de logs y monitorización en tiempo real.

Como seguridad tendremos:

• La navegación será de lunes a sábado en un horario comprendido de 8 am a 4.30 pm y los domingos de 8 am a 1 pm.
• La autentificación será obligatoria tanto para navegar nacional como en internet.
• Solo se permitirá el acceso desde la red local.
• Se filtrarán todos los puertos dejando solo los necesarios abiertos.
• Se priorizarán las conexiones de los servidores sobre las de navegación.
• Se filtrará el contenido por categorías.

En los siguientes apartados se comenzará con la explicación de cada una de las partes del fichero de configuración de Squid.

NOTA: Todas las IP usadas aqui son solo de ejemplo

2.1. Configuraciones básicas

NOTA: En la configuración mostrada no estamos usando SSLBUMP en la seccion ESCUCHA/SALIDA DEL PROXY, por lo que esta comentada. Recuerde que debera elegir su uso.

2.2. Proxy padre

NOTA: Como NO se esta usando SSLBUMP en el ejemplo, si usamos proxy padre. Se tomo de ejemplo el proxy padre de la red TURNET

2.3. Caché

Aquí nos deprendemos un poco a explicar. Uno de los cuellos de botella de un servidor Squid es su cache. Esto es debido a:

• Accesos continuos al disco duro.
• Ancho de banda.
• Capacidad de procesamiento.
• Memoria RAM.

Existen diferentes algoritmos para llevar a cabo esta tarea, cada cual con sus pros y contras. Vamos a ver UFS, AUFS, DISKD, COSS y NULL:

UFS

• Es el sistema por defecto de SQUID.
• Es el más lento.
• Todo el proceso de lectura, escritura, recepción de peticiones, envío de objetos, etc. se hace con un solo demonio.
• Muchos accesos simultáneos mediante este sistema pueden producir cuellos de botella considerables.

AUFS

• Sobre la base es exactamente lo mismo que UFS.
• La diferencia es que lanza múltiples demonios para la lectura, escritura, borrado, etc.
• AUFS consume una gran cantidad de procesador y memoria cuando se ve ante una carga de trabajo alta.

DISKD

• Tambien basado en UFS y AUFS.
• La diferencia en este caso es que solo levanta un demonio extra.
• Es una solución intermedia entre UFS y AUFS.

COSS

• Ofrece un mayor rendimiento que el resto de opciones.
• Utiliza un sistema de ficheros especial y optimizado para Squid.
• Toda la información se guarda en un solo fichero.
• Se escriben en bloques de datos.
• No es del todo estable ni recomendable su uso.

NULL

• No guarda ninguna cache en el disco duro.
• Aunque no lo parezca tiene utilidad en sistemas de proxy anónimos.

Cacheo en memoria ram y algoritmos para el movimiento de objetos cacheados:

Estas políticas son las que definirán que objetos se mantienen en cache o memoria y cuales son eliminados dejando espacio para nuevos objetos. Estas políticas se aplicarán a cualquier cache_dir que configuremos después de esta política. Ellas son las siguientes:

• LRU: Los menos accedidos son los primeros en ser eliminados. (Por defecto).

• GDSF:Los objetos pequeños más solicitados permanecen en cache. Tiene menos eficiencia ya que descarga objetos grandes, aunque se utilicen a menudo.

• LFUDA:Los objetos más solicitados permanecen en cache, sin importar el tamaño. Un objeto grande impide que se cacheen muchos pequeños.

NOTA: Si está usando LFUDA como política de reemplazo deberá incrementarse el valor de maximum_object_size por encima de los 4 MB por defecto.

Parámetros para el uso de la memoria RAM y disco:

• Maximum object size (en disco o memoria): Con esta directiva se indica que los ficheros con un tamaño mayor del indicado (en kilobytes) no se guardaran en el disco duro. Por defecto, si no se indica nada, son 4 megas.
• Minimum object size (en disco o memoria): Los objetos de menor tamaño no serán guardados en el disco duro. El valor es especificado en kilobytes. Por defecto el valor es 0.
• Cache Mem: Cantidad de memoria ram que será utilizada como cache. En la memoria ram se cachean los objetos descargados directamente desde el servidor origen y desde los servidores hermanos, aumentando de una forma considerable la velocidad de respuesta si estos se piden muy a menudo. En cambio, no cachea en memoria los objetos leídos del disco duro. Un valor entre 8 y 32 Mb es los recomendable, pero dependerá de la cantidad de memoria que tengamos en el sistema.
• Marca de nivel Alto y Bajo de la Cache:

cache_swap_low (percent, 0-100): La sustitución de un objeto en la cache comienza cuando el uso del swap (disco) está por encima de la marca de nivel bajo e intenta mantenerse cerca de este nivel. Si la utilización está cerca del nivel bajo, se realizarán menos sustituciones. Valor por defecto 90 (%)

cache_swap_high (percent, 0-100): A medida que la utilización de swaps se acerca al nivel alto, el desalojo de objetos se vuelve más agresivo. Valor por defecto 95 (%)

• Cache de Ip (caché DNS para la resolución de nombres de dominio):

ipcache_size (number of entries): Especifica el tamaño de esta cache. Valor por defecto 1 Mb

ipcache_low (percent): Establece el nivel bajo para esta cache. Valor por defecto 90 (%)

ipcache_high (percent): Estable el nivel alto para esta cache. Valor por defecto 95 (%)

• Cache fqdn (caché DNS para la resolución de direcciones IP):

fqdncache_size (number of entries): Especifica el tamaño de esta cache. Valor por defecto 1 Mb.

• Usuario y grupo de manejo de SQUID

cache_effective_user: Si inicia SQUID como root, cambiará al usuario especificado a continuación. El valor predeterminado es de nobody (nadie).

cache_effective_group: Grupo del usuario especificado en cache_effective_user.

NOTA: Cuando instalamos SQUID este creara el usuario proxy y el grupo proxy.

• Manejo la memoria libre:

memory_pools: Si se habilita, SQUID mantendrá los pools de memoria asignada (pero no utilizada) disponible para uso futuro. Si su RAM no es un problema y dispone de suficiente, desabilitelo.

memory_pools_limit: Si se establece en un valor distinto de cero, SQUID mantendrá como máximo lo especificado como límite de memoria asignada (pero no utilizada) en los pools de memoria.

Configuracion de logs:

• Los logs se guardan en /var/log/squid
• Squid guarda en el fichero access.log las peticiones que realiza cada cliente a páginas web.
• El fichero cache.log contiene los mensajes de debug y error que Squid genera.
• El fichero store.log es una especie de log de transaccion para los objetos que se mantienen y se remueven de la cache.

Teniendo esta base teórica ya podemos llevar a la práctica una configuración básica de la cache. El tamaño de cache en disco que se usará será de 5 GB, pero si tienen un disco duro grande y rápido pueden llevar su cache hasta 20 Gb si desean, con eso se logrará una navegación más rápida. Pero cuidado, si se aumenta la cache en disco también se deberá aumentar la memoria física. De modo predeterminado se utilizará el formato UFS para crear en el directorio /var/spool/squid un caché de 5 GB, dividido en jerarquías de 16 directorios subordinados, hasta 256 niveles cada uno:

El formato de cache UFS puede llegar a bloquear el proceso principal de Squid en operaciones de entrada/salida sobre el sistema de archivos cuando hay muchos clientes conectados. Para evitar que esto ocurra, se recomienda utilizar AUFS, que utiliza el mismo formato de UFS, pero funciona de manera asincrónica, consiguiéndose un mejor desempeño.

El espacio en disco de la cache que se usara en esta configuración será de casi 5 GB, pero si tienen un disco duro grande y rápido pueden llevar su cache hasta 20 Gb si desean, con eso se lograría una navegación más rápida. Pero cuidado, si aumentamos la cache en disco, también se debería aumentar la memoria física. De modo predeterminado utilizaremos el formato UFS para crear en el directorio «/var/spool/squid» un cache de 5 GB, dividido en jerarquías de 16 directorios subordinados, hasta 256 niveles cada uno.

Squid usa aproximadamente 10 MB de Memoria RAM por cada GB del total de todos los directorios de cache definidos (sería más, en un servidor de 64 bits). En nuestro caso usaremos 5 GB de espacio para cache en disco, lo que haría un total de 50 MB para la cache de memoria. A esto le sumaremos el valor de «cache_men» que definiremos y le aumentaremos de 10 a 20 MB más de margen. Toda esta suma la duplicaremos y ese será el tamaño TOTAL de Memoria RAM física ideal para nuestro SQUID. En nuestro caso sería:

50 MB + 256 MB + 20 MB = 326 MB

Este valor duplicado seria 652 MB, por lo que nuestro SQUID con 1GB de RAM estaría muy cómodo. Si tiene un servidor de memoria baja, entonces no necesariamente será capaz de utilizar todo el espacio en disco, ya que cuando la cache se llena la memoria disponible será insuficiente, obligando a Squid a intercambiar memoria y afectar el rendimiento. Un directorio de cache total muy grande e insuficiente Memoria RAM (Física + Swap) podría hacer que Squid dejara de funcionar completamente. La solución para caches más grandes es obtener más Memoria RAM física. Asignar más cantidad a SQUID a través de cache_mem no ayudara.

Usaremos 256 MB de memoria para la cache, este parámetro dependerá de su Memoria RAM. Usaremos el algoritmo LFUDA, por lo que tendremos que declararlo en la configuración, porque Squid usa por defecto el LRU. La longitud máxima de los objetos que se guardará en la cache será solo de 4 MB, tanto para la RAM como para el disco duro.

Por lo tanto, la configuración quedaría de la siguiente manera:

2.4. Autenticación

A condición, se ofrece un el fragmento de configuración de Squid en el fichero “/etc/squid/squid.conf”, que hace referencia a los mecanismos de autenticación por Kerberos y por LDAP Básico. Deberá elegir si usar autenticación en Kerberos o LDAP. Aquí les mostramos ambas opciones. En el caso de LDAP, el navegador web requerira autenticación mediante la especificación del usuario y la contraseña.

Usando KERBEROS:

Usando LDAP:

En la configuración anterior se usó la autenticación de grupos con Kerberos por su “helper” correspondiente “ext_kerberos_ldap_group_acl”. Esto posibilita que la calidad del servicio en el proxy responda a los usuarios que pertenezcan a dichos grupos del directorio activo. Esta variante aprovecha la ventaja de la seguridad, pues usando el “helper” “ext_kerberos_ldap_group_acl” se realizan consultas al LDAP directamente, usando un “bind dn” o usuario para autenticarse, mientras Kerberos usa su propia autenticación y ticket, conque se cuentan en el servidor para la autenticación del LDAP, que ya se encuentra integrado en Samba4.

También es necesario aclarar que, si se tiene IPv6 deshabilitado, se recomienda mantener la opción ipv4 en la definición de la ACL externa genérica, de lo contrario el programa no hará su función correctamente, aun cuando Squid inicie sin errores.

Otro aspecto importante es la definición de la cantidad máxima de procesos de autenticación para generar. Si comienzan muy pocos, Squid tendrá que esperar a que procesen una acumulación de verificaciones de credenciales, ralentizándola. Squid puede fallar cuando se alcanzan 2N+1 peticiones de clientes que procesar, teniéndose solamente N helpers configurados, sobre todo cuando el número de conexiones que abre un sitio puede influir en el número de peticiones de los clientes. Por ello se recomiendo en este tutorial que N sea un número igual o mayor a la cantidad de usuarios del proxy.

2.5. Patrones de refrescamiento

Refresh pattern

• Nos permite indicar, mediante expresiones regulares la duración de un objeto en cache.
• Sirve para objetos que no se indica su caducidad (la mayoría) por parte del webmaster.
• Se deben indicar todos los objetos que deseemos cachear.
• La lista puede ser muy larga, lo mejor es copy/paste y modificar los valores a nuestro gusto.

Objetos con fecha de caducidad (expire)

• Los objetos con expire (una fecha de caducidad) no pasan por nuestro refresh pattern. Es el webmaster el que debe indicarlo en su código.
• Si la fecha de expire no se ha superado, squid coge el objeto de la cache.
• Si la fecha de expire se ha superado, Squid consulta la fecha de ultima modificacion.
• Si no hay modificación, vuelve a coger el objeto de la cache.

NOTA:

• Objeto fresco: El objeto no ha caducado, por lo que Squid puede seguir obteniéndolo de la cache.
• Objeto caducado: El objeto ha caducado, Squid debe borrar el objeto de la cache y pedir una nueva versión al servidor web.

Los patrones de refrescamientos son efectivos si no existen cabeceras de caducidad desde el servidor que las origino, o que tus patrones tengan una opcion de overdrive-expire. Ejemplo:

refresh_pattern ^ftp: 1440 20% 10080

Esto significa:

• Sino hay encabezado de caducidad para todos los objetos cuyos nombres terminen en .gif o .GIF (ficheros de imágenes) entonces:
• Si la edad (tiempo que un objeto ha estado en la cache) es menor que 1,440 minutos, entonces se considera fresco.
• Sino si la edad es mayor que 10,080 minutos, se considera caducado y hay que ir al servidor de origen por una copia fresca.
• Entonces si la edad esta entre el mínimo y el máximo valor, usaremos el lm-factor para determinar su frescura. lm-factor es la relación de la edad en el servidor de caché con el período, desde la creación o modificación del objeto en el servidor de origen expresado en porciento. Por lo tanto, si el objeto fue creado hace 10,000 minutos atrás en el servidor de origen y ha estado en mi cache por 1,800 minutos (esta es la edad) el factor de relación lm-factor es 1,800/10,000 = 18%.
• Si este lm-factor es menor que el porciento expresado en nuestro patrón (20%) entonces el objeto es considerado fresco.
• Sino el objeto esta caducado, y hay que ir por una copia fresca al servidor de origen.

Una vez entendido como se lee una expresión regular de patrón de refrescamiento, se pueden entender mejor los siguientes patrones de refrescamiento.

2.6. Declaración de reglas (ACLs)

Las listas de control de acceso son un conjunto de reglas que permiten controlar el tráfico de la red a través de la aprobación o denegación de estas. Hay de diferentes tipos:

• Tipo src: Especifican una o varias direcciones IP de origen o un segmento de red con su máscara:

acl [nombre] src [contenido]

• Tipo dst: Especifican una IP de destino y máscara.

acl [Nombre] dst [contenido]

• Tipo dstdomain: Establecen permisos sobre dominios web de destino. Para el caso de las “listas negras” se pueden asociar varias listas a una misma ACL, lo cual propiciaría considerarlas todas como una única gran ACL, de múltiples listas. Se diferencia el nombre de las ACLs de este tipo, cuando se quiera dar un tratamiento diferenciado a las listas de cada grupo.

acl [Nombre] dstdomain [Contenido]

• Tipo dstdom_regex: Análisis de palabras de salida y expresiones regulares:

acl [Nombre] dstdom_regex [contenido]

• Tipo time: Establece límites relacionados con franjas horarias dentro de una semana, de esta forma hasta podemos habilitar o deshabilitar la navegación externa a nuestro antojo.

acl [Nombre] time [días][Horas]

• Tipo url_regex: Permite especificar expresiones regulares para comprobar una URL. De esta forma podemos deshabilitar páginas con un contenido temático.

acl [Nombre] url_regex «/ruta/al/fichero»

acl [Nombre] url_regex [contenido]

• Tipo urlpath_regex: Permite la administración de descargas por extensiones de ficheros.

acl [Nombre] urlpath_regex «/ruta/al/fichero»

acl [Nombre] urlpath_regex [contenido]

• Tipo req_mime: Permite comprobar la solicitud de un cliente.

acl [Nombre] req_mime «/ruta/al/fichero»

acl [Nombre] req_mime [contenido]

• Tipo rep_mime: Permite comprobar el tipo de respuesta a un cliente.

acl [Nombre] rep_mime «/ruta/al/fichero»

acl [Nombre] rep_mime [contenido]

• Tipo mac address: Permite administrar las MAC que acceden a través de Squid.

acl [Nombre] arp «Mac Address»

• Tipo password: Controla el acceso a internet por usuario y password. La opción “REQUIRED” no es necesaria cuando se utiliza Kerberos como método de autenticación primario. Puede ser utilizado para autenticar usuarios en específico, ya sea por un fichero de texto o por el nombre exacto del usuario.

• Tipo maxconn: Permite limitar el número de conexiones TCP por usuario. Esto ayuda a que usuarios que no se encuentren limitados por ancho se banda, sean controlados por numero de conexiones, evitando que abran muchas pestañas y abusen del ancho de banda compartido con otros usuarios.

acl [Nombre] maxconn N

• Tipo max_user_ip: Permite protección contra credenciales compartidas, ya que se puede ajustar a no más de una autenticación a la vez con el mismo usuario.

acl [Nombre] max_user_ip -s 1

La ACL anterior se complementa con la directiva “authenticate_ip_ttl”, la cual controla cuanto tiempo Squid recuerda la dirección IP asociada a cada usuario. Esta directiva también es usada cuando se usa autenticación en el proxy. Normalmente se especifican 60 segundos o 1 minuto cuando los usuarios de la LAN cambian su IP constantemente, sin embargo, para el caso de redes corporativas con direccionamiento estático es totalmente seguro definir un tiempo mayor, como 2 horas.

Aunthenticate_ip_ttl N [time_unit]

Así como muchas otras ACLs específicas, las cuales pueden ver en el siguiente enlace:

http://www.squid-cache.org/Doc/config/acl/

En dependencia de las condiciones de su red y lo que pretendan hacer se hará uso o no, de la gran mayoría de estas ACL’s. Muchas de estas reglas se podrán ver y entender mejor en el ejemplo integrador al final del tutorial.

2.7. Aplicación de reglas

La declaración de las ACLs por sí solas no no hacen nada y para que sean válidas las reglas de Squid, se necesita la aplicación de estas ACLs bajo determinadas condiciones. Existen varios tipos para la aplicación de las reglas, donde la sintaxis de una regla podrá resumirse en:

access_list <deny|allow> <lista de control de acceso>

Con “access_list” los autores pretenden resumir la posible regla a implementar, siendo variados los casos, como:

• http_access
• http_reply_access
• reply_body_max
• icp_access
• always_direct
• never_direct

Y otros con su propia sintaxis.

2.8. Declaración y aplicación de otras reglas especiales

No todas las reglas tienen una sintaxis tan simplificada como las anteriores. Algunas requieren definiciones específicas, ya sea en declaración como aplicación de las reglas. En esta sección veremos las referentes a “Delay Pools” y “SSL Bump”

2.8.1. Retardo con Delay Pools

Delay pools es la respuesta de Squid frente al control de ancho de banda y el “traffic shaping” (catalogación de tráfico). Esto se realiza limitando el rate en que Squid retorna los datos desde su cache.

Los delay pools son en esencia «cubos de ancho de banda” (bandwidth buckets). La solicitud a una respuesta es demorada hasta que cierta cantidad de ancho de banda esté disponible desde un cubo. Squid llena con cierta cantidad de tráfico los cubos por cada segundo y los clientes del Cache consumen los datos llenados desde esos cubos o cubetas.

El tamaño de un cubo determina cuánto límite de ancho de banda está disponible en un cliente. Si un cubo se encuentra lleno, un cliente puede descargar a máxima velocidad de la conexión disponible (sin limitación de rate) hasta que éste se vacíe. Después que se vacíe recibirá el límite de tráfico asignado.

Se requiere varios conceptos que Squid usa para el control de Delay Pools:

• Listas de control de acceso (Access rules)
• Clases de Delay Pools (Delay pool classes)
• Tipo de cubos (buckets)

Secuencia lógica:

1. Squid verifica en qué delay_access te encuentras
2. Si concuerda con una, esta apunta hacia un delay pool específico
3. Cada delay pool tiene una clase: 1, 2, 3, 4, 5
4. La clase determina qué tipo de cubo estás usando. Squid tiene 3 tipos: Global (agregate), individual, red (network)
   • La clase 1 tiene un único cubo Global (agregate)

# Clase 1: param1 (BW disponible = cubeta aggregate)

• La clase 2 tiene un cubo Global (agregate) y 256 cubos Individual

# Clase 2: param1 (BW disponible = cubeta aggregate) param2 (BW individual = cubeta individual)

• La clase 3 tiene un cubo Global (agregate) y 256 cubos de Red y 65536 cubos Individual.

# Clase 3: param1 (BW disponible = cubeta aggregate) param2 (BW de red = cubeta network) param3 ( BW de ip = cubeta individual)

• La clase 4 tiene lo mismo que la clase 3, pero agrega un 4to parámetro para usuarios.

# Clase 4: param1 (BW disponible = cubeta aggregate) param2 (BW de red = cubeta network) param3 ( BW de ip = cubeta individual) param4 (BW de usuario = cubeta user)

• La clase 5 es la única compatible con ACLs lentas, tales como las ACLs externas usadas en los mecanismos de autenticación. Ella está compuesta por un tagrate y su explicación no está muy esclarecida en la documentación oficial. Lo cierto es que con esta clase se puede brindar QoS por cuentas de usuario de ACLs lentas que puedan pertenecer a grupos de un Directorio Activo.

# Clase 5: param1 (tagrate)

Puede uno desactivar cubos que no van a ser utilizados. Por ejemplo, en la clase 2 puede uno desactivar el cubo global y solo utilizar los cubos Individual.

Por razones obvias se toma siempre el ancho de banda menor. Por ejemplo, considere la posibilidad de una clase 3 cubos agregate, network e Individual. Si tiene en Individual 20 KB, En network 30 KB, pero el agregate tiene 2 KB, el cliente recibirá sólo 2 KB.

Directivas:

• delay_pools: Define cuantos delay pools se van a utilizar
  • Ejemplo:
    • delay_pool 5: Define 5 Delay pools que serán configurados posteriormente.
• delay_class: Define la clase del delay pool. Para evitar complicaciones es recomendable tener siempre un delay_class para cada delay pool definido.
  • Ejemplo:
    • delay_class 1 3 (Define el delay pool 1 que sea de tipo 3).
    • delay_class 5 2 (Define el delay pool 5 que sea de tipo 2).
• delay_parameters: Este es el parámetro crítico en el cual se limita el ancho de banda. Para cada Delay Pool se debe definir: el fill rate (tráfico de llenado) y el tamaño máximo de cada cubo.

delay_parameters N rate/size [rate/size [rate/size]]

El valor del rate está definido en bytes por segundo y size en total de bytes.

Si se divide el size entre el rate, dispondrás del tiempo en segundos que el cubo se llenará si el cliente no está consumiendo.

Los siguientes casos se explican, teniendo en cuenta que:

1 B = 8 bits y 1 K = 1024

Una Pool de clase 1 que dispone de un solo cubo sería definido como sigue:

delay_class 2 1
delay_parameters 2 262144/262244

De esta forma se limita la red a 262144 B/s = 2 Mb/s y los primeros 262244 Bytes (poco más de 256 KB) podrán ser descargados sin restricción de velocidad.

Para un Pools de clase 2, El primer cubo es aggregate y el segundo es un grupo de cubos individuales:

delay_class 4 2
delay_parameters 4 262144/262244 65536/65636

De esta forma la red «toda la red» dispondrá, en los primeros 262244 Bytes = 256 KB y un poco más (tamaño del cubo), de una descarga a velocidad máxima sin restricción. Después de haber descargado los primeros 256 KB y un poco más (se vaciará el cubo), y comenzará a descargar a 262144 B/s = 2 Mb/s. Igualmente, cada cliente solo podrá descargar rápidamente los primeros 65636 Bytes = 512 KB y un poco más. Después descargará establemente a 65536 B/s = 512 Kb/s.

• delay_access: Permite relacionarlo a una ACL específica. Es similar a las reglas de acceso de Squid, pero es necesario definir el número de Pool antes del allow o deny.

delay_access 1 deny gerentes
delay_access 1 allow mi_red
delay_access 5 allow mime_extensiones

Squid define una lista de acceso separada para cada Delay Pool. Puede disponer de un allow o un deny. Si es allow utiliza esa regla y no sigue buscando en las siguientes de ese Pool. Si es deny, automáticamente cancela la búsqueda en ese Pool, pero seguirá buscando en las listas de acceso de los otros pools.

Esto se explica mejor en el ejemplo integrador al final del tutorial, donde se hace uso de varias clases y se le brinda una calidad de servicio para la navegación a internet. Este retardo se planifica basado en el nivel de privilegios que estos estos usuarios en la red, lo cual permitirá clasificarlos en los diferentes grupos de navegación de Squid.

2.8.2. MITM con SSL Bump

SSL Bump o Golpeo a SSL es la solución MITM (Man In The Middle) de Squid implementada desde el 2011 y que ha ido madurando con el paso del tiempo. La motivación detrás de esta configuración es desencriptar las conexiones HTTPS para aplicar filtrado de contenido. HTTPS fue creado para respetar la privacidad del usuario, y la implementación de SSL Bump puede llevar a una violación legal. Sin embargo, para entornos empresariales, donde la internet está en función de la labor que realiza en usuario y es necesario saber a dónde está accediendo.

La nueva colección de SSL Bump para Squid se basa en el método de «Peek and Splice». Este método le da la opción al administrador de desencriptar más tarde en el proceso de “handshake” del TLS/SSL, donde el cliente SNI y el certificado del servidor están disponibles (o cuando se esclarece de que no se está lidiando con una conexión TLS/SSL), dando mucha más información en la traza que deja la intercepción.

Su objetivo principal es tomar decisiones de desencriptación, después de conocido el nombre del servidor de origen, especialmente cuando se intercepta trasparentemente TLS/SSL. Permite además evitar la desencriptación de sitios con tráfico no encriptado y de los sitios HTTPS que se especifiquen.

El gran obstáculo es que para que MITM sea usable se requiere que un certificado privado (el de Squid) sea instalado en cada uno de los navegadores de los clientes del proxy, dando como resultado la necesidad de un mayor procesamiento en el servidor, para poder encriptar y desencriptar el tráfico.

Las páginas de bloqueo funcionaran de igual manera en HTTPS como para HTTP, para aquellos sitios desencriptados que coinciden con alguna regla de filtrado de contenido.

NOTA: Si usted no tiene intenciones de usar SSL Bump o se encuentra detrás de un proxy padre en cascada (no NAT), puede omitir esta sección.

Prerequisitos para usar SSL Bumping en Squid

Squid debe haberse compilado con las siguientes opciones:

• –with-openssl
• –enable-ssl-crtd

Para estar seguros si Squid lo soporta, verificamos sus opciones habilitadas:

NOTA:Por defecto, Squid no habilita esta opción en Debian

A continuación, se explicará el procedimiento para generar un certificado root CA autofirmado:

Creamos un certificado autofirmado por 2 años:

Creamos un certificado DER-encoded para importar en los navegadores de los usuarios:

Para importar el certificado «.der» en Firefox, hacer lo siguiente:

• Opciones
• Opciones avanzadas
• Ver certificados > Autoridades
• Importar > Seleccionar el «.der» > OK

Debemos asegurarnos de que seleccionamos este certificado para validar sitios web.

Ahora si accedemos a cualquier sitio HTTPS nuestro navegador confiara en la CA de Squid, mientras Squid generara un certificado dinámico para ese hostname.

NOTA: Si se usa un antivirus como Kaspersky con el módulo de filtrado Web activado, este no dejara acceder a los sitios en internet que usen conexiones HTTPS, pues no reconocerá el certificado de Squid como valido para el sitio. La solución que encontramos en este tutorial fue la de deshabilitar esta opción de filtrado web en el antivirus y dejarle todo ese trabajo al proxy. En el caso de Kaspersky basta con hacerlo desde su KSC (Kaspersky Security Console) para que todas las máquinas que administra se les aplique la política. Tambien pudiera dejarse habilitada este filtrado de contenido web en el KSC, pero especificando que el dominio “empresa.midominio.cu” se trata de un dominio de confianza.

Configuramos los permisos para usar un certificado autofirmado:

Creamos un directorio para cache de los certificados y sus respectivos permisos:

Generamos la DB para los certificados SSL/TLS:

La línea anterior debe devolver lo siguiente:

Configuramos el usuario y grupo “proxy” para que maneje este fichero:

A continuación, se presenta un fragmento de la configuración del “squid.conf”, que hace referencia a la configuración de SSL Bump (metodo Peek and Splice) en Squid: