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

###############################
# 1.  CONFIGURACIONES BASICAS #
###############################

# 1.1.  ESCUCHA/SALIDA DEL PROXY:
#=====================================================================
# Sin SSL BUMP:
# Si el proxy cuenta con una 2da interfaz de red, debe especificar la IP, aunque si no la tiene se puede hacer igualemte. No especificarla
# implica que el proxy escucha en cualquiera de sus interfaces, mientras especificarla la obliga a que sea en aquella que responde por la IP indicada
# http_port IP:Port
#http_port 10.7.1.15:3128
http_port 3128

# Con SSL BUMP:
#http_port 10.7.1.15:3128 ssl-bump \
  			 cert=/etc/squid/ssl_cert/squidCA.pem \
  			 generate-host-certificates=on dynamic_cert_mem_cache_size=10MB

# Si el proxy cuenta con una 2da interfaz de red, se le puede especificar como salida (debe estar bien configurado el enrutamiento y el forwarding en el sistema)
#tcp_outgoing_address 172.16.1.15
#icp_port 3130
#=====================================================================

# 1.2.  MEDIDAS DE SEGURIDAD:
#=====================================================================
via off
forwarded_for off
reload_into_ims on
quick_abort_min 0 KB
quick_abort_max 0 KB
quick_abort_pct 100
read_ahead_gap 17 KB					# La cantidad de datos que el cache almacenara antes de lo que ha sido enviado al cliente al recuperar un objeto de otro servidor.
negative_ttl 0 seconds
positive_dns_ttl 1 hour					# Limite superior sobre cuanto tiempo Squid almacenara en cache las respuestas DNS positivas.
negative_dns_ttl 1 seconds				# TTL para el almacenamiento en cache negativo de busquedas DNS fallidas.
range_offset_limit 0
httpd_suppress_version_string on			# Supresion de la visualizacion de la version implementada de Squid.

# Lista de ACLs para cada nombre de cabecera en peticiones HTTP, que permiten removerlas bajo ciertas condiciones:
request_header_access From deny all
#request_header_access User-Agent deny all		# Se comenta para que sitios como Facebook o Youtube no nos deniegue el acceso por tener un supuesto navegador desactualizado (aunque tengamos el ultimo).
request_header_access Server deny all
request_header_access WWW-Authenticate deny all
request_header_access Link deny all
request_header_access cache-Control deny all
request_header_access X-Cache-Lookup deny all
request_header_access Via deny all
request_header_access X-Forwarded-For deny all
request_header_access Pragma deny all
request_header_access Keep-Alive deny all
#=====================================================================
# 1.3.  PARAMETROS ADMINISTRATIVOS:
#=====================================================================
check_hostnames off
#=====================================================================
# 1.4.  TIEMPOS DE ESPERA:
#=====================================================================
half_closed_clients off					# Se cierran completamente las conexiones TCP cerradas a medias.
#=====================================================================
# 1.5.  OTRAS OPCIONES:
#=====================================================================
# Nombre visualizable del proxy:
visible_hostname anonymous

# Debugging para ACLs:
# debug_options <section,level>

# NOTA:
#---------------------------------------------------------------------
# Section: Significa un componente dentro del Squid que realiza una operacion particular.
# Level: significa la cantidad de informacion necesaria sobre cualquier seccion dada.
# Para mas informacion sobre las secciones ver el siguiente enlace: "https://wiki.squid-cache.org/KnowledgeBase/DebugSections"
# Nivel 0: Solo problemas criticos. No hay informacion de depuracion en absoluto.
# Nivel 1: Cuestiones importantes. Estos mensajes generalmente indican problemas de red que el administrador deberia solucionar.
# Nivel 2: Trafico de protocolo. Generalmente usado solo por las secciones de protocolo de alto nivel.
# Nivel 3-4: Debugs heredados.
# Nivel 5: La informacion de depuracion mas util se muestra en este nivel.
# Nivel 6: Mas detalles de la informacion de depuracion, si el nivel 5 no muestra lo suficiente sobre un problema especifico.
# Nivel 7-8: Alguna informacion de depuracion especifica de la seccion no suele ser util.
# Nivel 9: Datos de I/O (entrada/salida) sin procesar. Puede contener informacion confidencial de privacidad o seguridad. garantizado para generar un "cache.log" muy grande.
# Las secciones mas usadas son la 28 (Access Control) y la 29 (Authenticator, Negotiate Authenticator, NTLM Authenticator)
#---------------------------------------------------------------------
#debug_options 28,1 29,1
debug_options 28,5 29,5
#debug_options 28,9 29,9

# ID de proceso:
pid_filename /var/run/squid.pid

# Opciones para FTP:
ftp_user [email protected]
ftp_passive on						# Requiere que el FW de la red permita el uso de puertos pasivos a Squid.
ftp_sanitycheck on

# Pagina de error:
error_directory /usr/share/squid/errors/es-es

# Terminos de consulta de borrado: 
strip_query_terms off					# Se establece en "off" para ver la URL completa.

# DNS con resolucion de internet
dns_nameservers 10.7.2.1

# Coleccion de estadisticas por usuario:
client_db on                            		# Directiva requerida para el uso de "maxconn"
#=====================================================================

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

###################
# 2.  PROXY PADRE #
###################
# NOTA:
#---------------------------------------------------------------------
# Si se usa el cache_peer no se podra usar SSL BUMP, porque Squid aun no soporta TLS-in-TLS (al menos hasta la version 5.0.2).
# Si usted no tiene un proxy padre puede comentar esta seccion.
#---------------------------------------------------------------------
#=====================================================================
# Proxy padre con autenticacion:
#cache_peer proxypadre.midominio.cu parent 8080 0 default LOGIN=cascada:cascadaadmin

# Proxy padre sin autenticacion:
#cache_peer proxypadre.midominio.cu parent 8080 0 no-query no-digest no-netdb-exchange default
cache_peer proxy.tur.cu parent 81 0 no-query no-digest no-netdb-exchange default

nonhierarchical_direct off		# Enviar siempre al proxy padre los tipos de solicitud no almacenable en cache
prefer_direct off			# Siempre intentar primero con el proxy padre, luego por directo.
#=====================================================================

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:

cache_dir ufs /var/spool/squid 5120 16 256

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.

cache_dir aufs /var/spool/squid 5120 16 256

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:

#############
# 3.  CACHE #
#############
cache_mem 256 MB                                		  # Especifica la cantidad de memoria ram que el proxy usa para los objetos.

#cache_dir <schema> <ruta> <espacio MB> <memoria L1> <memoria L2> # Especifica donde y como almacena archivos cache en disco
cache_dir ufs /var/spool/squid 4352 16 256			  # Se recomienda usar maximo un 85% del espacio disponible por el disco (usar L1=16 y L2=256).

# Algoritmo de cacheo:
cache_replacement_policy heap LFUDA				  # Especifica el metodo LFUDA (Least Frequently Used with Dynamic Aging o menos frecuente con envejecimiento dinamico) 
#								    para la politica de reemplazo en el disco cache. Los objetos menos populares tendran menos posibilidades de ser 
#								    almacenados en cache, frente a otros mas populares.

memory_replacement_policy heap GDSF				  # Determina los objetos que se purgan de la memoria cuando se necesita espacio de memoria.

# Aprovechamiento del espacio en disco:
maximum_object_size 32 MB					  # Su valor por defecto es 4 MB, pero se incrementa para mejorar la politica de reemplazo LFUDA.
minimum_object_size 3 KB

# Aprovechamiento de la RAM:
maximum_object_size_in_memory 4 MB              		  # Especifica la cantidad de Memoria RAM maxima ocupada por un objeto.
#minimum_object_size_in_memory 3 KB

# Cachear mayor cantidad de datos IP:
ipcache_size 10240
ipcache_low 98
ipcache_high 99
fqdncache_size 10240

# Cache Swap:
cache_swap_low 90                               		  # Especifica el espacio maximo y min en % y controla el reemplazo de los objetos almacenados en el disco.
cache_swap_high 95

# Cache dir Logs:
cache_access_log /var/log/squid/access.log			  # Bitacora para las peticiones que realiza cada cliente a paginas web. 
cache_log /var/log/squid/cache.log				  # Bitacora que contiene los mensajes de debug y error que SQUID genera. 
cache_store_log /var/log/squid/store.log			  # Bitacora que sirve como registro de transaccion para los objetos que se mantienen y se remueven de la cache. 
coredump_dir /var/spool/squid

# Memoria libre:
memory_pools off

# Cache user n group:
cache_effective_user proxy
cache_effective_group proxy

# Notificacion ante fallo:
cache_mgr [email protected]				  # Direccion de correo del administrador local de la cache, que recibira un correo cuando esta deja de funcionar.
#=====================================================================

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:

#####################
# 4.  AUTENTICACION #
#####################

# 4.1.  KERBEROS (MECANISMO DE AUTTENTICACION PRIMARIO):
#=====================================================================
# Mapeo de usuarios del dominio con Kerberos:
auth_param negotiate program /usr/lib/squid/negotiate_kerberos_auth -r -s HTTP/[email protected]
auth_param negotiate children 300 startup=60 idle=1
auth_param negotiate keep_alive off
#=====================================================================
# Mapeo de grupos con Kerberos y LDAP:
# external_acl_type <nombre_generico_acl_externa> ipv4 children-startup=n children-max=N ttl=300 negative_ttl=60 %LOGIN ruta/al/helper/ext_kerberos_ldap_group_acl -a -D EXAMPLE.COM
external_acl_type kerberos_ldap_group ipv4 children-startup=150 \
					   children-max=300 ttl=300 \
					   negative_ttl=60 %LOGIN \
					   /usr/lib/squid/ext_kerberos_ldap_group_acl \
					   -a -D ECASA.AVIANET.CU

Usando LDAP:

#####################
# 4.  AUTENTICACION #
#####################
# Mapeo de usuarios del dominio con LDAP:
auth_param basic program /usr/lib/squid/basic_ldap_auth -R -b "dc=ecasa,dc=avianet,dc=cu" \
							-D [email protected] \
							-W /etc/squid/ldappass.txt \
							-f "(|(userPrincipalName=%s)(sAMAccountName=%s)(userPasswdac=ACTIVE))" \
							-h ecasadc01.ecasa.avianet.cu

# Mapeo de grupos del dominio con LDAP:
external_acl_type ldap_group %LOGIN /usr/lib/squid/ext_ldap_group_acl -R -b "dc=ecasa,dc=avianet,dc=cu" \
							-D [email protected] \
							-W /etc/squid/ldappass.txt \
							-f "(&(objectclass=person)(sAMAccountName=%v)(memberof=CN=%a,CN=Users,DC=ecasa,DC=avianet,DC=cu))" \
							-h ecasadc01.ecasa.avianet.cu                                                                                     
# Indica el numero de procesos de autenticacion a crear
auth_param basic children 5	
# El texto que aparecera al pedirnos usuario y clave						
auth_param basic realm Usted debe autenticarse	
# El tiempo que tardara en pedir de nuevo la clave. Fijado a 2 horas.				
auth_param basic credentialsttl 2 hours							
auth_param basic casesensitive on
authenticate_ttl 1 hour
authenticate_ip_ttl 60 seconds

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.

##################################
# 5.  PATRONES DE REFRESCAMIENTO #
##################################

#=====================================================================
#refresh_pattern [-i] regexp         min  percent    max  [options]
refresh_pattern ^ftp:               1440    20%    10080
refresh_pattern ^gopher:            1440     0%     1440
refresh_pattern -i (/cgi-bin/|\?)      0     0%        0
refresh_pattern .                      0    20%     4320

# Debian:
refresh_pattern -i \.deb$         129600   100%   129600
refresh_pattern -i \.gz$          129600   100%   129600
refresh_pattern -i \.bz2$         129600   100%   129600

# Imagenes:
refresh_pattern -i \.gif$         14400     80%    43200
refresh_pattern -i \.tiff?$       14400     80%    43200
refresh_pattern -i \.bmp$         14400     80%    43200
refresh_pattern -i \.xbm$         14400     80%    43200
refresh_pattern -i \.psd$         14400     80%    43200
refresh_pattern -i \.rgb$         14400     80%    43200
refresh_pattern -i \.ai$          14400     80%    43200
refresh_pattern -i \.cdr$         14400     80%    43200
refresh_pattern -i \.dwg$         14400     80%    43200
refresh_pattern -i \.svg$         14400     80%    43200
refresh_pattern -i \.raw$         14400     80%    43200
refresh_pattern -i \.nef$         14400     80%    43200
refresh_pattern -i \.jpg$         14400     80%    43200
refresh_pattern -i \.jpe?g$       14400     80%    43200
refresh_pattern -i \.xbm$         14400     80%    43200
refresh_pattern -i \.png$         14400     80%    43200
refresh_pattern -i \.wrl$         14400     80%    43200
refresh_pattern -i \.ico$         14400     80%    43200
..............................................................
..............................................................
refresh_pattern -i \.doc$         14400     80%    43200
refresh_pattern -i \.rtf$         14400     80%    43200
refresh_pattern -i \.tex$         14400     80%    43200
refresh_pattern -i \.latex$       14400     80%    43200

# Objetos de tipo Java:
refresh_pattern -i \.class$       14400     80%    43200
refresh_pattern -i \.js$          14400     80%    43200
refresh_pattern -i \.class$       14400     80%    43200

# Objetos de tipo Web:
refresh_pattern -i \.css$            10     20%     4320
refresh_pattern -i \.html?$          10     20%     4320
refresh_pattern \/$                  10     20%     4320

# Para evitar problemas con scripts .do:
refresh_pattern -i \.do$              0      0%     1440
#=====================================================================

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.

acl [Nombre] proxy_auth REQUIRED
acl [Nombre] proxy_auth "/ruta/al/fichero/usuarios.txt"
acl [Nombre] proxy_auth nombre_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:

squid -v

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:

cd /etc/squid
mkdir ssl_cert
chown proxy:proxy /etc/squid/ssl_cert
chmod 700 ssl_cert
cd ssl_cert

Creamos un certificado autofirmado por 2 años:

openssl req -new -newkey rsa:2048 -sha256 -days 730 -nodes -x509 -extensions v3_ca -keyout squidCA.pem  -out squidCA.pem

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

openssl x509 -in squidCA.pem -outform DER -out squid.der

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:

chown proxy:proxy squidCA.pem
chmod 400 squidCA.pem

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

mkdir -p /var/lib/squid

Generamos la DB para los certificados SSL/TLS:

/usr/lib/squid/security_file_certgen -c -s /var/lib/squid/ssl_db -M 10MB

La línea anterior debe devolver lo siguiente:

Initialization SSL db...
Done

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

chown proxy:proxy -R /var/lib/squid/ssl_db

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:

###########
# CASCADA #
###########

# NOTA:
#---------------------------------------------------------------------
#Si se usa el cache_peer no se podra usar SSL BUMP, porque Squid aun no soporta TLS-in-TLS (al menos hasta la version 5.0.1)
#---------------------------------------------------------------------

############################
# ESCUCHA/SALIDA DEL PROXY #
############################

#=====================================================================
# Sin SSL BUMP
#http_port 192.168.120.43:3128
# Con SSL BUMP
http_port 192.168.120.43:3128 ssl-bump \
cert=/etc/squid/ssl_cert/myCA.pem \
generate-host-certificates=on dynamic_cert_mem_cache_size=10MB
#=====================================================================

###################
# MITM (SSL BUMP) #
###################

# NOTA
#---------------------------------------------------------------------
# client-first -> peek
# none -> splice
# server-first -> bump
#---------------------------------------------------------------------
#=====================================================================
sslcrtd_program /usr/lib/squid/security_file_certgen -s /var/lib/squid/ssl_db -M 10MB
sslcrtd_children 5

# Se desea desencriptar todas las conexiones TLS, excepto aquellas de "localhost" y las que van a la lista blanca "no_bump_sites":
acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
acl no_bump_sites ssl::server_name "/etc/squid/reglas/no_bump_sites"    # "ss::server_name" tiene la capacidad real de determinar el nombre real del servidor solicitado por el usuario (reemplaza al despreciado "dstdomain")
acl rotos_pero_seguros dstdomain "/etc/squid/reglas/rotos_pero_seguros" # Sitios a los que se les deshabilitara la validacion de certicados (sitios a los que se debe acceder aun sabiendo que su certificado no es valido).
ssl_bump splice localhost                                               # Se deniega el SSL BUMP a conexiones de confianza que sean hacia localhost
ssl_bump peek step1 all                                                 # En el paso 1 se hace un "peeking" a la solicitud TLS del cliente para buscar el SNI, que indica el nombre real del servidor al que intenta conectarse
ssl_bump peek step2 no_bump_sites                                       # En el paso 2 se hace un "peeking" en el certificado del servidor.
# (un peek en el paso 2 da la posibilidad de hacer un "splicing" en el paso 3 y luego la posibilidad de hacer un "bump")
ssl_bump splice step3 no_bump_sites                                     # En el paso 3 se hace un "splicing" (se evita el SSL BUMP) a las conexiones que coincidan con la lista blanca
ssl_bump bump all                                                       # Se golpean todas las demas conexiones SSL (se hace el SSL BUMP)
# Se deshabilita los errores de validacion de certificados para los sitios que pertenezcan a "rotos_pero_seguros":
sslproxy_cert_error allow rotos_pero_seguros
sslproxy_cert_error deny all
#=====================================================================