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.
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.2. Proxy padre.
2.3. Caché.
2.4. Autenticación.
2.5. Patrones de refrescamiento.
2.6. Declaración de reglas (ACLs).
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.
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:
Como seguridad tendremos:
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
############################### # 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 squid@proxysquid.ecasa.avianet.cu 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. 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
Aquí nos deprendemos un poco a explicar. Uno de los cuellos de botella de un servidor Squid es su cache. Esto es debido a:
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
AUFS
DISKD
COSS
NULL
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:
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:
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 (%)
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 (%)
fqdncache_size (number of entries): Especifica el tamaño de esta cache. Valor por defecto 1 Mb.
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.
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:
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 squid@midominio.cu # Direccion de correo del administrador local de la cache, que recibira un correo cuando esta deja de funcionar. #=====================================================================
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/proxysquid.ecasa.avianet.cu@ECASA.AVIANET.CU 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 squid@ecasa.avianet.cu \ -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 squid@ecasa.avianet.cu \ -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.
Refresh pattern
Objetos con fecha de caducidad (expire)
NOTA:
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:
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 #=====================================================================
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:
acl [nombre] src [contenido]
acl [Nombre] dst [contenido]
acl [Nombre] dstdomain [Contenido]
acl [Nombre] dstdom_regex [contenido]
acl [Nombre] time [días][Horas]
acl [Nombre] url_regex «/ruta/al/fichero»
acl [Nombre] url_regex [contenido]
acl [Nombre] urlpath_regex «/ruta/al/fichero»
acl [Nombre] urlpath_regex [contenido]
acl [Nombre] req_mime «/ruta/al/fichero»
acl [Nombre] req_mime [contenido]
acl [Nombre] rep_mime «/ruta/al/fichero»
acl [Nombre] rep_mime [contenido]
acl [Nombre] arp «Mac Address»
acl [Nombre] proxy_auth REQUIRED acl [Nombre] proxy_auth "/ruta/al/fichero/usuarios.txt" acl [Nombre] proxy_auth nombre_usuario
acl [Nombre] maxconn N
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.
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:
Y otros con su propia sintaxis.
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”
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:
Secuencia lógica:
# Clase 1: param1 (BW disponible = cubeta aggregate)
# Clase 2: param1 (BW disponible = cubeta aggregate) param2 (BW individual = cubeta individual)
# Clase 3: param1 (BW disponible = cubeta aggregate) param2 (BW de red = cubeta network) param3 ( BW de ip = cubeta individual)
# 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)
# 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_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 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.
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:
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:
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 #=====================================================================
Me complace anunciar la creación de esta útil herramienta (SquidStats), para el análisis y monitoreo…
La inteligencia artificial está revolucionando las industrias al automatizar tareas, predecir patrones y permitiendo tomar…
Uno de los grandes retos al que nos podemos enfrentar cuando una aplicación crece, es…
Percona Monitoring and Management (PMM) es una herramienta de código abierto para la supervisión y…
Qué es lo que deseo hacer en este capítulo? Básicamente un sonoff, quiero encender/apagar las…
Hace algunos meses estoy escuchando hablar del proyecto Home Assistant (HA). En palabras literales del…
View Comments
Buensimo!!!
Se podrian interceptar apks tipo whatsapp con este metodo?
Me encantaria probarlo en mi celular si asi fuera
jejeje puros windowseros!!!!
Algo mas inteligente que decir en el comentario??
Las debilidades del uso de MITM con squid se pueden resolver utilizando e2guardian.
https://github.com/e2guardian/e2guardian/wiki/MITM---Filtering-HTTPS
Hola estimado, le consulto, en esta parte no debería decir cache_mem en vez de cache_dir ?
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.
Muchas gracias!
Por favor, los feedbacks que hagan tienen que ser en base a Squid5, no una version inferior.
Gracias ahora mismo lo pruebo