Cómo configurar Squid Proxy Caché

PROXY-CACHE

Squid es el servidor de proxy y cache por excelencia. Rechace imitaciones.

Cuando navegamos a traves de un proxy, cada peticion que hace nuestro navegador se delega al servidor proxy y es este el que se descarga la pagina o el parte web que se ha solicitado y se lo pasa a nuestro navegador. Por tanto es un intermediario entre los usuarios y la web. Al estar en medio de ese trafico puede actuar dos funciones muy importantes: controlar los accesos (permitir o desdeñar segun se disponga en sus normas); y ademas hacer cacheo de elementos (paginas web, imagenes, iconos que una vez se piden se guardan en la memoria del proxy), con lo que si se solicita un parte que ya se ha pedido en lugar de volver a bajarselo de internet, lo sirve el propio proxy. Con esta tecnica de cache nos podemos ahorrar desde un 20 a un 40% de trafico de internet.

Squid es un servidor con años y mucha solera, presente en el mundo u*ix y linux. Dispone de un régimen de reglas enmarañado para el examen de la navegacion, y lo que es mas, un protocolo propio ICP, para intercomunicar proxyes.

Squid es capaz de cooperar on otros servidores Squid y formar jerarquías de proxys. También es posible conformar el Squid como un servidor de proxy inverso. ¿Qué es eso? un acelerador de HTTP. Sirver para webs con muchos accesos, en los que se suele poner una maquina delante del servidor web con un squid inverso para servir las paginas y el contenido de la web mas rápidamente. Ver aquí. y aquí.

* Venga vale, tengo una red local y quiero conformar el proxy para que los usuarios de la red local pasen por el aro del proxy. Ademas con eso podre registrar sus accesos, jejeje. Como hacemos eso?

Si no cambiamos nada, el proxy escucha por imperfección en el puerto tcp 3128

El fichero de configuración de squid es: squid.conf

Editamos el fichero y añadimos una regla (junto al residuo de reglas definidas):

acl Safe_ports port 280
acl Safe_ports port 488
acl Safe_ports port 591
acl Safe_ports port 777
acl CONNECT method CONNECT
acl Mi.Red.Local src 192.168.100.0/24

Vale! ya tenemos una regla creada. Pero no hay que olvidar aplicarla!! un poco más abajo, podemos añadirla, pero atención!! el concierto en el que pongamos la regla es crucial, ya que jugando con el concierto se aplicaran unas reglas u otras:

#Recommended minimum configuration:
#
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager
# Deny requests to unknown ports
http_access deny !Safe_ports
# Deny CONNECT to other than SSL ports
http_access deny CONNECT !SSL_ports
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
# And finally deny all other access to this proxy
http_access allow localhost
http_access allow Mi.Red.Local
http_access deny all

Ya esta! añadiendo esa regla nuestra red local ya tendra permiso para utilizar el proxy! Pero cuidado, fijemonos en la s reglas que le rodean. Antes de llegar a la regla de nuestra red local, denegamos cualquier puerto webdistinto (simbolo !) a los definidos en las acl de arriba; lo mismo se hace con los puertos SSL, el proxy solo servira páginas con puerto seguro que hayamos definido (443 por ejemplo). Si desde la red local quieren acceder a una web de un banco que esta en puerto SSL raro (por ejemplo 8084), habrá que añadir ese puerto en la ACL. Asimismo, la última regla es «deny all», esto es, cualquier otra cosa se deniega (Es imprescindible hacerlo porque es muy peligroso tolerar emplear el proxy a cualquiera., pueden emplear nuestro proxy para ataques o para hacer SPAM. De todas formas, también se puede cerrar el puerto del proxy por firewall).

Jo! es que somos unos vagos y no queremos andar así!! Entonces mejor ceder permiso para todo:
podemos coger(che, no me entiendan mal boludos) la regla de nuestra red local y ponerla arriba del todo,
pero manteniendo la regla final de deny all.

Y como configuramos el navegador? especificamos el servidor proxy, y el puerto sera el 3128 por defecto.
Cuando al proxy le llega una petición, se comprueba en concierto cada regla hasta que alguna sea aplicable, y cuando se aplique ya no se miran mas reglas.

* Restricciones:

Para educar las restricciones, contestaremos este mail que recibimos recientemente:
Soy un gerente malandrín de una empresa, quiero que mis empleados solo usen internet a determinadas horas,
que no puedan descargarse mp3 o videos avi, que no puedan acceder a la web de marca ni a la de yonkis.com.
Eso si: desde mi equipo quiero hacer lo que me salga de los piiiiiiiiiiiii. Jar jar jar!!

Oido barra! todo eso se puede restringir con el proxy squid. Hay muchos tipos de reglas de squid, incluidas unas muy potentes que permiten emplear expresiones regulares.
La regla para limitaciones horarias:

acl name time [lista_dias] [hora_inicio:minuto-hora_final:minuto]
donde lista_dias: MTH (osea: S – Sunday M – Monday T – Tuesday W – Wednesday H – Thursday F – Friday A – Saturday)
Por ejemplo:
acl RestringirPorHoras time 9:00-10:00

Y si añadimos la regla:

http_access deny !RestringirPorHoras
http_access allow Mi.Red.Local
http_access deny all

Ya esta! denegamos el acceso a horas distintas de el margen: 9:00-10:00

Si aplicamos esta regla cerraremos el acceso a yonkis y marca.
acl dominiosChungos dstdomain yonkis.com marca.es

Y si aplicamos esta podremos desdeñar el acceso a ficheros .mp3 y .avi
acl denegarURL url_regex -i .mp3$ .avi$

Venga las aplicamos:
….
http_access deny !RestringirPorHoras
http_access deny denegarURL
http_access deny dominiosChungos
http_access allow Mi.Red.Local
http_access deny all

Pero por supuesto, hay una persona (el malandrín gerente) al que no hay que restringirle nada, y eso lo hacemos asi:

acl IPGerente src 192.168.100.3/32

Y aplicamos

http_access allow IPGerente
http_access deny !RestringirPorHoras
http_access deny denegarURL
http_access deny dominiosChungos
http_access allow Mi.Red.Local
http_access deny all

Voila! jugando con el concierto de las reglas, cuando el gerente use el proxy jamas se le aplicaran las reglas restrictivas, ya que hemos metido una regla que le permite salir y esta ENCIMA de las retricciones. Se «matchea» esa regla y las demas no se miran. No entiendes esto? Mira si hacemos

http_access allow all
http_access allow IPGerente
http_access deny !RestringirPorHoras
http_access deny denegarURL
http_access deny dominiosChungos
http_access allow Mi.Red.Local
http_access deny all

Si al comienzo del todo ponemos allow all, por muchas reglas que metamos despues, siempre se aplicara la primra regla y las demas yo ni se miraran.

¿Y si se quiere cercenar el tamaño de archivos que se descargan los usuarios?
Ahí tenemos un problema, de momento parece que squid lo puede hacer. Si que tiene una directiva de gestion de cache para cercenar el tamaño de ficheros que se guardan en la cache, pero no es eso lo que interesa.

¿Quereis más?

El proxy-cache squid esta muy documentado y no sera dificil que encontreis ayuda. Esta es la documentación oficial:

http://squid-docs.sourceforge.net/latest/html/book1.html

* Autenticación, usuario y password para navegar:

Squid incorpora un mecanismo para que los usuarios tengan que identificarse cada vez que abran el explorer y quieran navegar. La forma más singular es usando la autenticación singular con usuario/passwd sacados de un fichero de texto. Para ello debemos activar la directiva: authenticate_program
authenticate_program /usr/lib/squid/ncsa_auth /etc/squid/passwd

Y atención! ahora hay que añadir una ACL para activar esta opción. Una vez más, jugando con el concierto de las reglas podremos aplicarlo a unos si y a otros no. La ACL se definiría así.

acl password-navega proxy_auth REQUIRED

Y la aplicariamos así.

http_access allow password-navega
http_access deny !RestringirPorHoras
http_access deny denegarURL
http_access deny dominiosChungos
http_access allow Mi.Red.Local
http_access deny all

La gran beneficio que tenemos aquí es que se puede cambiar el régimen de autentificación, hasta el punto de conseguir que la autentificacion se haga contra el PDC o servidor primero de dominio de una red windows. Que beneficio tiene eso? obviamente que los usuarios no tengan un password para cada cosa. Es complejo, pero se puede hacer con winbind y samba.

nota: usando este sistema, en los logs veremos el nombre de usuario para cada petición.

* Proxy transparente:

Podemos emplear un proxy en la red local, pero siempre habrá usuarios malvados que se desconfiguren el proxy del navegador. Para que sigan pasando por el aro, o visto de otro modo, para que nadie se tenga que azorar de conformar el proxy en su navegador, podemos emplear la norma del proxy-transparent. Esto va unido al régimen de firewall, y hacemos que todas las peticiones al puerto 80 se redirigan al puerto del proxy.
Además de eso, en el proxy debemos añadir estas lineas de configuración:

## Proxy transparent
httpd_accel_host virtual
httpd_accel_port 80 443 8080 19720 19721 10000
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

httpd_accel_single_host off

Esto puede innovar de un linux a otro, en redhat furia bien. Este proyecto también esta muy documentado.
Tiene una pega: no se puede hacer proxy transparente de conexiones SSL.

* Mi proxy no funciona y tu guia es una bassssura

Vale, es posible, pero hay que aprender a acendrar los servidores. El proxy squid genera logs como muchos otros programas, y podemos echarle un vistazo:

/var/log/messages (o /var/log/syslog dependiendo del Linux)

y ademas:

/var/log/squid/access.log (aqui vemos los accesos y sobre este fichero se puede aplicar el analisis de log y generar informes de navegación)

/var/log/squid/cache.log (log de cache de objetos)

Fuentes de Información

El contenido del post es de mi autoría, y/o, es un recopilación de distintas fuentes.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *