Squid proxy cache para tu LAN: control de acceso y filtrado

Hay un tipo de servidor que casi todas las redes de oficina montaron en algún momento y que hoy está medio olvidado: el proxy de salida. No es un reverse proxy (eso ya lo cubren Caddy, Nginx y Traefik), sino lo contrario: un servidor al que la LAN apunta para salir a internet con una sola salida controlada, filtrada y cacheada. Eso es Squid, y sigue siendo la herramienta de referencia para filtrar por ACL, bloquear destinos y centralizar el tráfico saliente de una red mediana.

La tentación es instalarlo y esperar que funcione. No funciona: la configuración por defecto de Squid es deliberadamente restrictiva y deja al proxy cerradísimo hasta que decides abrirlo. Peor: la versión que te instala la distribución puede no ser la que quieres. Ubuntu 24.04 LTS empaqueta la serie 6, que perdió el soporte de seguridad en julio de 2025, mientras que la serie 7 es la única que recibe parches y ya acumula avisos de seguridad con CVSS de 10.0 (CVE-2025-62168) y de 9.2 (CVE-2026-33526). Esta guía arma el servicio completo sobre Debian 13 o Ubuntu 24.04: ACL por rangos de la LAN, filtrado por dominio, el camino real para HTTPS, el modo transparente y el estado real de squidGuard, que ya no es lo que era.

Qué es Squid y en qué se diferencia de lo que ya tienes

Squid es un proxy de caché y control de acceso. Los clientes de tu LAN apuntan a él y todo su tráfico HTTP sale por esa única puerta. Eso te da tres cosas que un reverse proxy no te da: una sola salida controlable, reglas de filtrado por ACL aplicadas a cada petición, y una caché de objetos reutilizables.

La diferencia con Caddy o Nginx es de dirección, no de calidad. Un reverse proxy recibe peticiones dirigidas a sus dominios y las reparte hacia atrás. Squid recibe peticiones de clientes que quieren salir y las saca hacia adelante. Si ya montaste un reverse proxy para tus servicios, no necesitas reemplazarlo: lo que te falta es la capa de salida.

La configuración por defecto que trae el paquete de Ubuntu o Debian ya define las ACL que vas a necesitar. El archivo /etc/squid/squid.conf de Ubuntu 24.04 incluye la definición de localnet con los rangos privados RFC 1918, el espacio de direcciones compartidas RFC 6598, el rango link-local RFC 3927 y sus equivalentes IPv6:

acl localnet src 0.0.0.1-0.255.255.255	# RFC 1122 "this" network (LAN)
acl localnet src 10.0.0.0/8		# RFC 1918 local private network (LAN)
acl localnet src 100.64.0.0/10		# RFC 6598 shared address space (CGN)
acl localnet src 169.254.0.0/16 	# RFC 3927 link-local (directly plugged) machines
acl localnet src 172.16.0.0/12		# RFC 1918 local private network (LAN)
acl localnet src 192.168.0.0/16		# RFC 1918 local private network (LAN)
acl localnet src fc00::/7       	# RFC 4193 local private network range
acl localnet src fe80::/10      	# RFC 4291 link-local (directly plugged) machines

Y trae también el bloque de reglas de acceso por defecto, que es donde se decide todo:

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localhost
http_access deny to_localhost
http_access deny to_linklocal
# http_access allow localnet
http_access deny all

Lee ese bloque con calma porque define el comportamiento real. http_access deny !Safe_ports bloquea peticiones hacia puertos que no están en la lista Safe_ports, que en la v7 incluye 80, 21, 443, 70, 210, el rango 1025-65535, 280, 488, 591 y 777. La línea http_access deny CONNECT !SSL_ports impide hacer túneles CONNECT hacia puertos distintos del 443. Las dos reglas deny to_localhost y deny to_linklocal protegen a las aplicaciones que corren en la misma máquina que asumen que solo localhost puede alcanzarlas. Y la línea decisiva es la última: http_access deny all.

Esa última línea es la razón por la que un Squid recién instalado no navega por nadie. La regla http_access allow localnet viene comentada, tanto en el archivo por defecto de la rama v7 como en el conf.d/debian.conf que Ubuntu deja aparte con el comentario de que por seguridad extra solo localhost usa el proxy en instalaciones nuevas. Y el orden importa: en Squid gana la primera regla que coincide, así que una regla deny all colocada antes del allow localnet deja todo bloqueado sin importar qué reglas hayas puesto después.

Antes de instalar: qué versión te va a tocar

Esta es la parte que más se salta la gente y la que más problemas genera después. Squid 7.8 es la versión estable actual, publicada el 30 de octubre de 2026, y es la única serie que recibe soporte de seguridad: la serie 6 perdió ese soporte el 10 de julio de 2025. Las últimas versiones de cada serie archivada son 6.14 (24 de junio de 2025), 5.9 (30 de abril de 2023), 4.17 (3 de octubre de 2021) y 3.5.28 (15 de julio de 2018).

El problema es qué te instala el gestor de paquetes:

Distribución	Versión de Squid	Serie	Estado
Ubuntu 24.04 LTS (noble), amd64	6.14-0ubuntu0.24.04.5	6	Sin soporte de seguridad
Ubuntu 24.04 LTS (noble), arm64	6.6-1ubuntu5	6	Sin soporte de seguridad
Ubuntu 24.04 LTS (noble), amd64 y arm64, con actualizaciones aplicadas	6.14-0ubuntu0.24.04.5	6	Sin soporte de seguridad
Debian 13 (trixie)	6.13-2+deb13u3	6	Sin soporte de seguridad
Debian 12 (bookworm)	5.7-2+deb12u5	5	Sin soporte de seguridad
Debian sid / forky	7.8-1	7	Con soporte

Sobre el papel parece que hay una asimetría: el paquete base de noble va en 6.6-1ubuntu5 en las dos arquitecturas, y la 6.14-0ubuntu0.24.04.5 que aparece en las tablas de Ubuntu viene de noble-updates y noble-security. Pero el repositorio de ports publica esa misma 6.14 para arm64, así que en una instalación al día de noble recibes 6.14 tanto en amd64 como en arm64. La diferencia real es entre la release original y las actualizaciones aplicadas, no entre x86 y arm.

Los avisos de seguridad recientes explican por qué importa la serie. Estos son los que afectan a squid en un proxy de salida típico:

Aviso	Problema	CVSS	Corregido en
CVE-2026-61642	Petición smuggling en HTTP Transfer-Encoding	7.7	7.6
CVE-2026-33526	Denegación de servicio al procesar peticiones ICP	9.2	7.5
CVE-2026-32748	Denegación de servicio en ICP	8.7	7.5
CVE-2026-33515	Lectura fuera de rango en mensajes ICP	6.9	7.5
CVE-2026-47729	Divulgación de memoria en la pasarela FTP	6.5	7.6
CVE-2026-50012	Corrupción de memoria al procesar respuestas de cache_digest	5.5	7.6
CVE-2026-104786	Desbordamiento de buffer en la autenticación HTTP	5.4	7.7
GHSA-vh99-xw7j-fx5c	Desbordamiento de buffer en la autenticación ICAP	3.4	7.7
CVE-2025-62168	Divulgación de información en el manejo de errores	10.0	7.2
CVE-2025-54574	Desbordamiento de buffer al procesar URN	9.3	6.4

Hay un rasgo que reduce el riesgo real en un proxy de LAN, y conviene no pasar por alto el matiz: los tres avisos de la tabla relacionados con ICP (CVE-2026-33526, CVE-2026-32748 y CVE-2026-33515) solo se activan si tienes el protocolo ICP habilitado, y la versión por defecto lo deja apagado con icp_port en 0. El aviso de CVSS 10.0, en cambio, no tiene nada que ver con ICP y sí te alcanza igual.

La directiva icp_port viene comentada en el archivo por defecto, y su valor por defecto en el código es 0, que significa ICP deshabilitado. Puedes confirmarlo en tu instalación con:

grep -nE "^[[:space:]]*icp_port" /etc/squid/squid.conf

El aviso de CVSS 9.3, CVE-2025-54574, es un desbordamiento de buffer al procesar respuestas URN, con posible ejecución remota de código. El propio aviso trae el contorno: deny sobre el protocolo URN, que es un rareza que ningún proxy de salida necesita.

acl URN proto URN
http_access deny URN

Si el grep no devuelve nada, el protocolo ICP está apagado y no te alcanzan los tres avisos de ICP. Los demás no se pueden descartar así de fácil. El de CVSS 10.0, CVE-2025-62168, es una divulgación de información en el manejo de errores: el Squid no redacta las credenciales de autenticación HTTP en los mensajes de error, así que un atacante puede llegar a conocer las credenciales que usa un cliente de confianza para autenticarse. Y CVE-2026-61642, el smuggling por Transfer-Encoding, es el tipo de falla que permite encadenar peticiones en una conexión. La conclusión práctica: si vas en serio con esto, compila la serie 7 desde fuente en lugar de quedarte con lo del repositorio.

Instala Squid en Debian 13 o Ubuntu 24.04

El paquete se llama squid y trae todo lo necesario para un proxy de salida:

sudo apt update
sudo apt install -y squid
squid -v | head -n 1

Un detalle de empaquetado que confunde: squidclient, squid-cgi y squid-purge vienen en paquetes separados, no dentro de squid. Instálalos si los vas a usar:

sudo apt install -y squidclient squid-cgi squid-purge

Los archivos y rutas que te van a importar, tomados del listado oficial de archivos del paquete en Ubuntu noble:

• /etc/squid/squid.conf: la configuración principal.
• /etc/squid/conf.d/debian.conf: los ajustes propios de Debian y Ubuntu.
• /usr/sbin/squid: el binario.
• /usr/lib/systemd/system/squid.service: la unidad de servicio.
• /etc/apparmor.d/usr.sbin.squid: el perfil de AppArmor que confina al proceso.
• /etc/ufw/applications.d/squid: la regla de UFW lista para usar si filtras el puerto con el firewall.

La configuración que viene en el paquete ya trae el puerto correcto y las ACL base. En Ubuntu 24.04, http_port 3128 aparece sin comentar en el archivo principal. Fíjate en eso porque el QUICKSTART oficial de la rama v7 usa rutas de compilación propia (/usr/local/squid) que no existen en Debian ni en Ubuntu: si copias comandos de ese documento tal cual, fallan.

Configura las ACL y abre el paso a tu LAN

La edición mínima para tener un proxy funcional se reduce a una línea: descomentar el http_access allow localnet y colocarlo antes del deny all. En /etc/squid/squid.conf el bloque queda así:

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localhost
http_access deny to_localhost
http_access deny to_linklocal
http_access allow localnet
http_access deny all

La regla http_access allow localnet habilita el acceso a todos los clientes de los rangos privados que ya define la ACL localnet. Si tu LAN usa un rango que no está en la lista (por ejemplo una red 10.0.0.0/8 desplazada o un CGNAT del ISP con rangos que no calzan), añade tu ACL propia con un nombre distinto y úsala en la regla, en vez de editar las líneas de localnet que vienen por defecto.

Un detalle sobre el rango CGNAT: 100.64.0.0/10 viene incluido en localnet por defecto. Si tu ISP te da una IP de ese rango en el servidor y quieres que ese servidor también pueda usar el proxy, ya está cubierto. Si por el contrario quieres excluir a alguien de ese rango, no basta con borrar la línea: tienes que definir una ACL negativa antes del allow localnet.

Antes de recargar, valida la sintaxis. Es el paso que evita que un typo te deje el servicio caído:

sudo squid -k parse

El comando devuelve código de salida distinto de cero si encuentra un error, y el mensaje incluye el archivo, el número de línea y la línea exacta que no pudo interpretar. Cuando pasa, recarga:

sudo systemctl reload squid
systemctl status squid --no-pager

Y prueba desde un cliente de la LAN, no desde el propio servidor. La razón es que http_access allow localhost viene antes del allow localnet, así que un curl contra 127.0.0.1 te da un falso positivo de que todo funciona:

curl -x http://IP_DEL_PROXY:3128 -I https://soylinux.com/

Si el curl devuelve la cabecera de respuesta del sitio, el proxy está reenviando. Si devuelve un error 403 con el texto ERR_ACCESS_DENIED, el problema está en las reglas http_access.

Filtra por dominio y bloquea lo que no quieres

El filtrado por destino se hace con la ACL dstdomain, que evalúa el nombre de dominio de la petición. El wiki oficial trae un ejemplo de bloqueo por dominio de nivel superior (TLD):

acl block_tld dstdomain .tv .xxx
http_access deny block_tld
deny_info TCP_RESET block_tld

El deny_info TCP_RESET es opcional pero interesante: en lugar de devolver una página de error, corta la conexiónTCP. El cliente ve un fallo de conexión en lugar de un mensaje de política, lo que evita que el usuario identificque el proxy y cambie de navegador para saltarse el bloqueo.

Para bloquear dominios concretos, el patrón es el mismo. Puedes definir varias ACL y aplicarles reglas separadas para tener control granular:

aclSitiosBloqueados dstdomain .redirigir.example .anuncios.example
aclSitiosPermitidos dstdomain .miempresa.local
http_access denySitiosBloqueados
http_access allow SitiosPermitidos

Un detalle de la serie 7 que te va a ahorrar un dolor de cabeza: las notas de release dicen que dstdomain ahora detecta y maneja solapamientos entre subdominios y comodines, combinándolos o ignorándolos según el caso. Lo mismo se aplica a src, dst, localip y ssl::server_name. En la serie 6 ese comportamiento no estaba garantizado, y una ACL mal construida podía dar resultados distintos según el orden de las entradas.

Sobre el orden de las reglas, insisto porque es el error número uno: en Squid se aplica la primera regla http_access que coincide con la petición. Si deny all aparece antes de tus reglas de permiso, nada más se evalúa. Las reglas de denegación específicas van arriba y las de permiso abajo, siempre.

HTTPS: la parte que nadie quiere explicar

Acá está la diferencia entre un proxy que funciona y uno que parece funcionar. Sin intervención, un proxy de salida maneja HTTPS de una sola manera: recibe un método CONNECT con el destino, abre un túnel TCP y se limita a retransmitir bytes. Ve que el cliente va a ejemplo.com:443, pero no ve nada de lo que pasa dentro del túnel. Eso significa que puedes bloquear por dominio, pero no puedes filtrar el contenido, y las listas negras por URL no aplican a HTTPS.

La alternativa es ssl_bump, que intercepta el TLS y descifra el tráfico. Requiere tres cosas: una CA propia que firme los certificados que Squid genera para cada sitio, que los clientes confíen en esa CA, y las directivas ssl_bump con la ruta a esa CA. El wiki oficial tiene el ejemplo con CA intermedia, en su variante de proxy explícito:

http_port 3129 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB \
   cert=/etc/squid/signingCA.crt \
   key=/etc/squid/signingCA.key \
   cafile=/etc/squid/chain.pem

Antes de que lo pruebes: el wiki de Squid advierte explícitamente que la interceptación de HTTPS tiene implicaciones éticas y legales que varían según el país y el contrato laboral. En algunos países la interceptación de conexiones exige registro previo; en otros es un delito tipificado con consecuencias penales. Si esto es para una red de la empresa, ese tema se resuelve con el área legal antes de tocar la configuración. Y hay una limitación técnica que conviene entender: el SSL-Bump de Squid está diseñado de modo que los clientes pueden detectar que el proxy existe. No es un interceptador invisible.

Mi recomendación para una LAN doméstica o de oficina pequeña: empieza con CONNECT sin inspección. El filtrado por dominio resuelve el caso más común, que es bloquear sitios enteros, sin necesidad de descifrar el tráfico HTTPS. El ssl_bump tiene sentido cuando tienes que aplicar políticas que un WAF no cubre, y en ese caso ya tienes el artículo sobre WAF open source con Coraza para comparar las dos capas.

Proxy transparente: cuando el cliente no puede configurarse

Un proxy explícito requiere que cada cliente apunte a la IP del proxy. En una red con dispositivos móviles, equipos de guest o appliances que no puedes tocar, eso no es viable. La alternativa es el modo transparente: el cliente cree que habla directo con internet y el gateway desvía el tráfico con DNAT hacia Squid. El wiki oficial tiene el ejemplo para interceptar tráfico IPv4 en Linux:

SQUIDIP=192.168.0.2
SQUIDPORT=3129
iptables -t nat -A PREROUTING -s $SQUIDIP -p tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination $SQUIDIP:$SQUIDPORT
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -t mangle -A PREROUTING -p tcp --dport $SQUIDPORT -j DROP

Y en squid.conf el puerto se declara en modo intercept:

http_port 3129 intercept

Tres advertencias sobre esto. Primera: la última regla de iptables en el ejemplo descarta el tráfico que vuelve hacia el puerto del proxy, y va en la tabla mangle antes del DNAT para evitar bucles de reenvío. Si la sacas, tienes bucles de paquetes. Segunda: el DNAT solo funciona para IPv4 en este esquema; para IPv6 el wiki apunta a la variante TPROXY v4. Tercera: el modo transparente no aplica a HTTPS sin ssl_bump, porque el túnel CONNECT sigue siendo opaco. Para HTTPS transparente hay que configurar ssl_bump en el puerto, lo que vuelve a los mismos requisitos de CA y de confianza del cliente.

El gestor de caché: cambió en la serie 7

La serie 7 eliminó varias herramientas que existían en la 6 y que mucha documentación vieja todavía te va a mandar a usar. La más importante: squidclient ya no viene con Squid, y cachemgr.cgi también se eliminó. La forma nueva de consultar el gestor de caché es por HTTP, con el prefijo /squid-internal-mgr/:

curl -u manager:clave_secreta http://IP_DEL_PROXY:3128/squid-internal-mgr/info

La contraseña se define en el squid.conf con la directiva cachemgr_passwd, que asocia una clave con acciones concretas:

cachemgr_passwd clave_secreta shutdown
cachemgr_passwd otra_clave info stats/objects

El gestor tiene acciones marcadas con asterisco en la documentación oficial, que son las que no se ejecutan sin contraseña válida: shutdown, reconfigure, offline_toggle y config. Para el resto de las acciones, la clave no es obligatoria.

La otra eliminación relevante es la herramienta de purga. En la serie 6 existía un comando dedicado; en la 7 se eliminó y la forma de purgar es habilitar el método HTTP PURGE en una ACL:

acl PURGE method PURGE
http_access allow localhost PURGE

Con eso, purgar una URL es una petición HTTP normal:

curl -X PURGE http://IP_DEL_PROXY:3128/http://ejemplo.com/recurso

Un detalle más sobre la serie 7 que afecta a migraciones: se eliminó el soporte del protocolo Ident. Las ACL ident e ident_regex, las directivas ident_lookup_access e ident_timeout y el código de log %ui ahora hacen fallar el arranque. También se retiró el soporte de ESI, así que la directiva esi_parser ya no existe. Y los nombres de idioma antiguos en error_directory se reemplazaron por códigos ISO-639. Si vienes de la serie 6 con una configuración larga, valida el arranque con squid -k parse antes de reiniciar el servicio.

squidGuard: el complemento clásico y su estado real

squidGuard es el complemento que todos asocian a Squid para listas negras, y la verdad es que el panorama se enfrió bastante. La última versión publicada en SourceForge es la 1.3.0, del 5 de noviembre de 2007. Debian empaqueta la 1.6.0-6 en la suite estable, pero no hay fecha de publicación verificable para esa versión.

El dato que va de cabeza es otro: Netgate, la empresa detrás de pfSense, deprecó los paquetes Squid, squidGuard y Lightsquid en pfSense Plus y pfSense CE por múltiples vulnerabilidades de seguridad sin corregir upstream, y recomienda enfáticamente desinstalarlos. Ojo con la lectura de eso: la deprecación es de pfSense y del ecosistema pfSense, no una declaración de que Squid esté abandonado. El proyecto Squid tiene la serie 7 activa con parches y avisos de seguridad en 2026.

Si decides usarlo, la configuración es por ACL externa. Squid llama a un binario helper y le pasa la URL; el helper responde con ALLOWED o BLOCKED. La forma de declararlo es con external_acl_type:

external_acl_type squidGuard /usr/bin/squidGuard -v
acl bloqueados url_regex -i .*\.exe$
acl todos src 0.0.0.0/0
http_access deny bloqueados
http_access allow todos

La directiva external_acl_type acepta parámetros de caché que te importan en un entorno real: ttl por defecto 3600 segundos, negative_ttl para los resultados negativos, cache con un máximo de 262144 entradas y children-max con 5 procesos helper por defecto. Si tienes una lista negra grande, esos parámetros son la diferencia entre un proxy que responde rápido y uno que se arrastra.

Mi opinión honesta sobre squidGuard hoy: la lógica de listas negras la puedes resolver hoy de forma más simple con ACL nativas de Squid (dstdomain, url_regex) y, si necesitas listas grandes mantenidas al día, con un resolver DNS propio tipo Pi-hole. El post sobre Pi-hole con AdGuard Home cubre ese camino. squidGuard queda como opción si ya tienes un archivo de listas negras consolidado y quieres aprovechar el formato existente.

Verifica que todo funciona

Una checklist corta para el momento en que el navegador de un cliente sigue sin navegar:

1. sudo squid -k parse tiene que salir con código 0. Si devuelve un error, el servicio ni siquiera intentó arrancar con esa configuración.
2. systemctl status squid tiene que estar en active. Si está en failed, el log de arranque dice por qué.
3. Desde un cliente de la LAN: curl -x http://IP_DEL_PROXY:3128 -I https://ejemplo.com/. Si devuelve ERR_ACCESS_DENIED, el orden de las reglas http_access está mal.
4. Un dominio bloqueado tiene que fallar. Un sitio bloqueado que responde significa que la ACL dstdomain no está funcionando, o que la regla de denegación quedó después de un allow general.
5. tail -f /var/log/squid/access.log muestra cada petición con el resultado del cache. Los códigos TCP_MISS son peticiones que no estaban en caché; los TCP_HIT son las que sí.

Sobre el punto 5, una advertencia para no perder el tiempo: el porcentaje de acierto de caché de Squid depende por completo de tu mezcla de tráfico y de los headers de caché de cada origen, así que no esperes una cifra concreta ni te la compares con la de nadie. Lo que sí puedes usar es la tendencia en tu propio access.log para saber si el cache_dir está bien dimensionado.

Preguntas frecuentes

Lee también

• Certificados TLS internos para tu LAN con mkcert
• Configura Pi-hole con AdGuard Home: DNS local para sysadmins Linux
• WAF open source: cómo configurarlo con Coraza
• Hardening de TLS en Nginx y Apache
• Servidor web Linux desde cero: guía definitiva
• Cómo configurar Caddy como reverse proxy en Linux