Filtrado seguro en Squid

En  Firewall y en la serie Squid Cache, explicamos que el proxy SQUID no filtra HTTPS en modo transparente. En esa publicación, también propusimos un método para hacer filtrado https utilizando Iptables, sin embargo esto implicaría un altísimo consumo de recursos de hardware y la ralentización de las peticiones y sus respuestas (no es lo mismo filtrar peticiones en un proxy que en un firewall).

Con el tiempo, el Proxy Squid poco a poco ha ido perdiendo vigencia y su función ha quedado relegada únicamente a ser una caché peticiones recurrentes a servidores web y DNS y esto se debe mayormente al uso extensivo del protocolo https.
Por ejemplo, si un terminal de la red local accede a un enlace de Mediafire, dicha petición pasaría por el proxy, pero como las comunicaciones por https son cifradas y  Mediafire utiliza https, entonces Squid poco o nada puede hacer al respecto, ya que ninguna regla sería capaz de bloquear el contenido detrás del enlace, simplemente porque "no sabe qué es, porque está cifrado".

Y redireccionar las peticiones del puerto 443 al 80 (8080) no funciona, porque el navegador web no podría verificar los certificados procedentes de estas conexiones seguras y se presenta el típico error de certificado. Y crear certificados propios implementando un Squid-in-the-middle SSL Bump entre el servidor proxy y el cliente, no solo ralentiza el tráfico, sino que es literalmente una invasión a la privacidad.

En este orden de ideas, no sirve de mucho realizar bloqueos con grandes listas negras (como nuestro proyecto Blackweb, entre otros proyectos similares), ya que, en su mayoría, son sitios http, y, por ejemplo, si tenemos incluido en la lista negra el dominio facebook.com, el usuario, con tan solo cambiar de http:// a https:// se saltaría el bloqueo.

Y para empeorar la situación,  Google va a marcar el tráfico http como inseguro y priorizará las búsquedas en sitios https, por tanto, mas temprano que tarde, la mayoría de los portales cambiarían a https. Lo mismo sucede con los aplicativos tipo circumvention (ver Blackstring) que ya comienzan a usar sitios https, lo cual, en ambos casos, deja al proxy Squid muy mal parado...
Pero Squid aún tiene un as debajo de la manga y es el filtrado por direcciones IP. 

Filtrado por IP

En realidad cuando escribimos una url en el navegador, el sistema de nombres de dominios (DNS) se encarga de hacer la "traducción URL a IP" para que la petición sea "entendible" a nivel de máquinas. Entonces, lo que en realidad hace Squid es "bloquear el dominio asociado a una IP".
Por ejemplo, si escribimos en el navegador www.google.es, el DNS lo traduce como 172.217.11.131 (en dependencia desde dónde se haga la consulta) y Squid bloquea la url asociada a esta IP, obviamente si se encuentra en nuestra lista negra, caso contrario lo deja pasar.

El filtrado IP nos ahorra tiempo en el proceso de petición-consulta-respuesta y hace que Squid trabaje mucho más rápido (porque ya tenemos la url traducida a IP en nuestra lista), pero implementarlo es más tedioso que el filtrado por dominios, ya que si, por ejemplo, la IP de un sitio porno que queramos bloquear no se encuentra en nuestra lista negra de IP, entonces sucede exactamente lo mismo que con el filtrado por dominios, con la diferencia que a veces hay más de una IP asociada a un dominio, o "algo" antes del dominio (servicios cloudflare, cloudfront, etc) y estos a menudo cambian de IP (muchos dominios de Google tienen IPs dinámicas y/o por región), lo cual hace que el trabajo de alimentar esta "enorme lista negra de IP" sea mucho más dispendioso.

NGFW en Squid

Si realmente queremos mantener la navegación lo más segura posible en nuestra red local (nada garantiza un 100%), no tiene sentido pasarnos el día bloqueando dominios o direcciones IP (un trabajo de nunca acabar), sino hacer exactamente lo contrario, aplicando uno de los principios de los NGFW (Next Generation Firewalls); un esquema de seguridad en el cual solo lo legitimo y autorizado es permitido, bloqueando todo lo demás; dicho de otro modo, denegar todo el tráfico (peticiones) y permitir solamente nuestra "lista blanca", en este caso de direcciones IP/CIDR.

Regla Squid

Para aplicar este principio, editamos el archivo de configuración de squid:

nano /etc/squid/squid.conf

Y agregamos la siguiente regla (a modo de ejemplo, nuestra lista blanca IP/CIDR "whiteip" la ubicamos en /etc/acl):

# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
# Deny all except whiteip
acl whiteip dst "/etc/acl/whiteip.txt"
acl no_ip url_regex -i [0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}
http_access allow whiteip
http_access deny no_ip

Y cerramos el proxy Squid:

http_access deny all

Implementar y mantener este tipo de soluciones representa una gran carga de trabajo para el administrador del proxy (sysadmin), ya que no solo debe estar validando las IP/CIDR permitidas cada cierto tiempo, sino que cada cliente que haga una petición de un dominio en su navegador y su IP asociada no se encuentre en nuestro "whitelist", el sysadmin debe hacer manualmente un host -t o dig +short -f al dominio en cuestión, para determinar la/s IP/CIDR y agregarla/s a la lista blanca.
Pero este esquema de protección tiene más ventajas que desventajas. El sysadmin se quitaría de encima la pesadilla de tener que correr (y sobre-engordar) una lista negra con millones de dominios (cada día se crean miles de sitios maliciosos), lidiar con el problema http/https, además de recibir otros beneficios asociados, como bloquear muchos programas tipo proxy y/o VPN, como TOR, Hotspot shield, etc. ( excepto los circumvention, como Ultrasurf), ya que estos consultan directamente direcciones IPs (y no dominios) para eludir el bloqueo y con la regla propuesta quedarían bloqueados de facto.
Pero para que esta regla funcione correctamente, también debemos implementar un firewall que mantenga un control estricto de los puertos y redirigir TODO el tráfico de la red local al servidor proxy Squid, sin excepciones y sin conexiones transparentes, y parametrizar muy bien el Squid para que no se "cuele nada", ya que Squid lee las reglas en orden, por tanto si ponemos antes de nuestra regla alguna otra muy permisiva, comprometería la efectividad de la regla propuesta.
Hemos creado un proyecto llamado whiteip, el cual contiene una lista blanca de IPs/CIDR asociadas a los dominios descritos en nuestra lista whiteurls y que puede ser un punto de partida para el sysadmin que quiera implementar este esquema de filtrado seguro en Squid.