Proxy
Uno de los principales dilemas que se presenta a la hora de configurar un servidor proxy squid es elegir su modo de trabajo: transparente o no-transparente.
Ambos modos tienen sus ventajas y desventajas y durante años se han tejido algunos mitos alrededor de este tema. Por eso hoy intentaremos aclarar algunas cosas que consideramos importantes sobre el funcionamiento del proxy Squid.
Problemas y más problemas
Según la creencia popular, un proxy en modo no-transparente brinda una mejor seguridad que en modo transparente (también llamado intercept, Web o NAT), pero una de las cosas más incómodas que tienen que realizar los administradores IT es tener que ir cliente por cliente y configurar manualmente los navegadores para que apunten a la ip:puerto del proxy.
Si nuestro proxy fuese transparente, bastaría con dejar los navegadores por default (detección automática del proxy) y redireccionar el trafico al puerto transparente (intercept) con una simple regla nat en nuestro firewall iptables. Por ejemplo:
Ambos modos tienen sus ventajas y desventajas y durante años se han tejido algunos mitos alrededor de este tema. Por eso hoy intentaremos aclarar algunas cosas que consideramos importantes sobre el funcionamiento del proxy Squid.
Problemas y más problemas
Según la creencia popular, un proxy en modo no-transparente brinda una mejor seguridad que en modo transparente (también llamado intercept, Web o NAT), pero una de las cosas más incómodas que tienen que realizar los administradores IT es tener que ir cliente por cliente y configurar manualmente los navegadores para que apunten a la ip:puerto del proxy.
Si nuestro proxy fuese transparente, bastaría con dejar los navegadores por default (detección automática del proxy) y redireccionar el trafico al puerto transparente (intercept) con una simple regla nat en nuestro firewall iptables. Por ejemplo:
/sbin/iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080Y abrir el puerto intercept en el squid3
http_port 192.168.1.10:8080 interceptPero en un proxy no-transparente los navegadores no detectan automáticamente el proxy (ya que se encuentra en una ip y puerto especifico), sin embargo existen protocolos y librerías que permiten lograrlo. Hablamos de Web Proxy Auto-Discovery Protocol ( WPAD) y proxy auto-config ( PAC), que aprovechan su divulgación gracias a la opción 252 del servidor DHCP. Ejemplo:
option option-252 code 252 = text; option option-252 \"http://192.168.1.10:8000/proxy.pac\n\";
Donde 192.168.1.10 es la ip del servidor WPAD y 8000 es el puerto elegido para la divulgación de este archivo (puede ser cualquiera siempre que no sea un puerto reservado).
Nota: Para que funcione debemos ubicar los archivos wpad en un directorio especifico, abrir el puerto de escucha en el firewall, crear el virtualhost en apache2 que contenga la ubicación y permisos de los archivos wpad y por último abrir a la escucha el puerto elegido en el archivo /etc/apache2/port.conf.
Pero... (siempre hay un pero)
De acuerdo con tuxjm, Hackplayers y otros portales, la divulgación de WPAD presenta los siguientes inconvenientes:
Nota: Para que funcione debemos ubicar los archivos wpad en un directorio especifico, abrir el puerto de escucha en el firewall, crear el virtualhost en apache2 que contenga la ubicación y permisos de los archivos wpad y por último abrir a la escucha el puerto elegido en el archivo /etc/apache2/port.conf.
Pero... (siempre hay un pero)
De acuerdo con tuxjm, Hackplayers y otros portales, la divulgación de WPAD presenta los siguientes inconvenientes:
1. El cliente tiene que tener correctamente configurado el sufijo DNS correspondiente al dominio local de la red a la esta conectado
2. Algunas versiones de navegadores (IE 6, entre otras) solicitan el archivo wpad.da en lugar de wpad.dat, por lo que debe ofrecer una forma de publicar el script con dicho nombre
3. Algunas versiones de IE 6 usan la cabecera "Host: <IP Address>", IE7+ y Firefox envían "Host: wpad" por lo que el servidor web, también debe de atender respuestas para estros nombres de host
4. Si desea realizar alguna exclusión la deberá definirla en el script autoconfig Proxy
5. Los navegadores no soportan https para el archivo pac (solo http) lo que implica un alto riesgo de seguridad y es fácilmente hackeable. (se puede montar un servidor wpad falso)
6. Involucra muchas aplicaciones, como apache, dhcp, dns (dnsmasq, bind, etc), etc
7. Hay que definir 3 archivos, ya que algunos navegadores descartan sistemáticamente el carácter definitivo del valor devuelto por la opción DHCP 252.
http://proxy.example.com:80/proxy.pac http://proxy.example.com:80/wpad.dat http://proxy.example.com:80/wpad.da
Nota: Puede declarar uno solo y crear un enlace simbólico de los otros hacia el elegido
8. Su compatibilidad es limitada (Mozilla requieren de un servidor DNS-Local e IE 7y 8 requiere modificar el registro de Windows (regedit) y eliminar la clave DWORD WpadDecision y cambiar o crear el valor de la clave DWORD WpadOverride a 1)
10. No hay acceso al nombre de host de la máquina
11. No tiene un método propio para determinar la dirección IP del usuario
12. Funciona basándose en un tiempo de espera de TCP
13. Presenta problemas de compatibilidad con IPv6
14. Si hay problemas con el archivo PAC y los navegadores no lo encuentran, no hay errores unificados; varían de acuerdo al tipo de navegador y su versión, lo cual puede crear confusión.
15. Existe malware que usa el nombre wpad para autodistribuirse y ataques WPAD Spoofing
Como podemos observar, este "método" de autoconfiguración no cuenta con un procedimiento estándar para cualquier tipo de red local o usuarios, y en más de 15 años de existencia (el borrador del protocolo WPAD se publicó en 1999) los problemas no han sido corregidos.
También tenemos DHCP Proxy, que es lo mismo que PXE ( UbuntuLTSP/ProxyDHCP), un sistema que tampoco ha recibido actualizaciones, salvo las especificaciones para dnsmasq (Vea el debate en serverfault) y DHCP Proxy de Cisco (vea DHCP Proxy vs DHCP Bridging o DHCP Proxy vs DHCP Relay vs DHCP Bridging) o de Juniper, pero no todos tenemos los recursos económicos para adquirir estos productos.
Hay otras cosas interesantes, como on-dhcp-proxy, smart-proxy y astralboot, y muchas más, y siempre estará la opción de usar scripts (bash .sh o batch .bat), que ejecutamos en cada terminal Windows o Linux, para autoconfigurar los navegadores con los datos del proxy a golpe de doble clic, o mejorar la seguridad de nuestro archivo PAC, con pactester, pero distan mucho de ser compatibles y seguros.
Muchos han tirado la toalla y se han decantado por un servicio especializado en la nube ( algo costosos), o han hecho lo que recomendó un usuario en Hackplayers: "mejor no usar dhcp". Bueno, lo segundo sería lo ideal y de paso nos evitaríamos ataques DHCP Starvation (y que nos jodan con el arsenal de herramientas disponibles actualmente para hacer colapsar el DHCP), sin embargo en una red dinámica abierta o semi-abierta (hotspot, etc), donde existen cientos de terminales, prescindir del DHCP no es la mejor solución.
DNS-Local
Una solución solventar la detección del proxy es utilizar un DNS-LOCAL (como Bind, dnsmasq...). Los navegadores modernos capturan mejor la ip:puerto del proxy si utilizamos un servidor DNS-Local, sin embargo debemos tener en cuenta que un DNS-Local "cachea" las peticiones y las resuelve localmente (salvo que sea una nueva) y esta operación demanda altos requerimientos de hardware por el nivel de procesamiento adicional a nuestro servidor, sin mencionar las fallas de seguridad a las que estaría expuesto por el simple hecho de tener un servidor DNS propio.
Resumiendo todo lo anterior, a la fecha no existe una solución segura y eficiente para la divulgación de la IP:Puerto del proxy, y por esta razón los más experimentados prefieren configurar los terminales de su red local manualmente... quisiéramos ver a un experto configurando "a mano" una red de 10000 equipos itinerantes.
Pero, para qué necesitamos un proxy?...
Un proxy no-transparente procesa todo el tráfico de la red local, tanto http, como https, ftp, etc, a diferencia del proxy no-transparente, que no procesa tráfico https (siempre y cuando no hagamos un ssl-bump y del cual no hablaremos, ya que causa más problemas de los que soluciona).
Ambos tipos de proxy filtran de igual forma el tráfico http, entonces si, por ejemplo, queremos bloquear el portal http://www.mediafire.com y lo tenemos incluido en una "lista negra" del squid, entonces el proxy lo bloqueará, sin importar que sea transparente o no, pero si tratamos de ingresar a https://www.mediafire.com, solamente el proxy en modo no-transparente bloquearía este sitio, gracias a una "regla" (mas bien un método) de squid llamado CONNECT.
En síntesis, la diferencia entre ambos modos de proxy está únicamente en el modo en que procesa el tráfico https.
Pero.... Squid does not provide the SSL/HTTPS support
Sin embargo (y aquí viene algo muy interesante que nos apartará unos segundos del objetivo de esta publicación) debemos aclarar que lo anterior tampoco es 100% cierto, ya que CONNECT no valida HTTPS porque el protocolo HTTPS es definido por conexiones "end-to-end" .
Entonces puede suceder al intentar filtrar HTTPS en un proxy no-transparente, nos encontremos con una montaña de errores, como por ejemplo TCP_DENIED/403, TCP_MISS/503 0 CONNECT, etc. (Ver códigos de log en Squid)
Sin entrar en muchos detalles, ya que para eso está la Wiki de Squid, una de las razones (hay muchas y depende del escenario) por las que ocurren estos errores es por las consultas simultáneas https IPv4 e IPv6, que realizan muchos sitios, como google, yahoo, microsoft, etc. Hay algunas medidas que podemos tomar para reducir estos problemas, tales como:
Otra manera de evitarlo es desactivando IPv6, tanto en el servidor como en los clientes, lo cual puede representar una pesadilla logística si son redes locales con cientos de usuarios.
Y este es uno de los tantos errores a los que nos podemos enfrentar cuando se trata de filtrar https en el proxy Squid.
Nota: Vale aclarar sobre las directivas " always/never_direct" que hay una gran diferencia entre GET/POST. GET siempre usará "padres" a menos que sean reemplazados por always_direct y POST nunca los usará a menos que sea forzado por never_direct. GET generalmente se ve como una solicitud cacheable y POST no. Squid por defecto solo usa "padres" en las solicitudes donde el resultado pueda ser almacenado en caché. La configuración predeterminada es:
Volviendo a lo que nos interesa (proxy)... ¿Alguna otra cosa?
8. Su compatibilidad es limitada (Mozilla requieren de un servidor DNS-Local e IE 7y 8 requiere modificar el registro de Windows (regedit) y eliminar la clave DWORD WpadDecision y cambiar o crear el valor de la clave DWORD WpadOverride a 1)
|
| Compatibilidad WPAD con los navegadores más usados |
11. No tiene un método propio para determinar la dirección IP del usuario
12. Funciona basándose en un tiempo de espera de TCP
13. Presenta problemas de compatibilidad con IPv6
14. Si hay problemas con el archivo PAC y los navegadores no lo encuentran, no hay errores unificados; varían de acuerdo al tipo de navegador y su versión, lo cual puede crear confusión.
15. Existe malware que usa el nombre wpad para autodistribuirse y ataques WPAD Spoofing
Como podemos observar, este "método" de autoconfiguración no cuenta con un procedimiento estándar para cualquier tipo de red local o usuarios, y en más de 15 años de existencia (el borrador del protocolo WPAD se publicó en 1999) los problemas no han sido corregidos.
También tenemos DHCP Proxy, que es lo mismo que PXE ( UbuntuLTSP/ProxyDHCP), un sistema que tampoco ha recibido actualizaciones, salvo las especificaciones para dnsmasq (Vea el debate en serverfault) y DHCP Proxy de Cisco (vea DHCP Proxy vs DHCP Bridging o DHCP Proxy vs DHCP Relay vs DHCP Bridging) o de Juniper, pero no todos tenemos los recursos económicos para adquirir estos productos.
Hay otras cosas interesantes, como on-dhcp-proxy, smart-proxy y astralboot, y muchas más, y siempre estará la opción de usar scripts (bash .sh o batch .bat), que ejecutamos en cada terminal Windows o Linux, para autoconfigurar los navegadores con los datos del proxy a golpe de doble clic, o mejorar la seguridad de nuestro archivo PAC, con pactester, pero distan mucho de ser compatibles y seguros.
Muchos han tirado la toalla y se han decantado por un servicio especializado en la nube ( algo costosos), o han hecho lo que recomendó un usuario en Hackplayers: "mejor no usar dhcp". Bueno, lo segundo sería lo ideal y de paso nos evitaríamos ataques DHCP Starvation (y que nos jodan con el arsenal de herramientas disponibles actualmente para hacer colapsar el DHCP), sin embargo en una red dinámica abierta o semi-abierta (hotspot, etc), donde existen cientos de terminales, prescindir del DHCP no es la mejor solución.
DNS-Local
Una solución solventar la detección del proxy es utilizar un DNS-LOCAL (como Bind, dnsmasq...). Los navegadores modernos capturan mejor la ip:puerto del proxy si utilizamos un servidor DNS-Local, sin embargo debemos tener en cuenta que un DNS-Local "cachea" las peticiones y las resuelve localmente (salvo que sea una nueva) y esta operación demanda altos requerimientos de hardware por el nivel de procesamiento adicional a nuestro servidor, sin mencionar las fallas de seguridad a las que estaría expuesto por el simple hecho de tener un servidor DNS propio.
Resumiendo todo lo anterior, a la fecha no existe una solución segura y eficiente para la divulgación de la IP:Puerto del proxy, y por esta razón los más experimentados prefieren configurar los terminales de su red local manualmente... quisiéramos ver a un experto configurando "a mano" una red de 10000 equipos itinerantes.
Pero, para qué necesitamos un proxy?...
Un proxy no-transparente procesa todo el tráfico de la red local, tanto http, como https, ftp, etc, a diferencia del proxy no-transparente, que no procesa tráfico https (siempre y cuando no hagamos un ssl-bump y del cual no hablaremos, ya que causa más problemas de los que soluciona).
Ambos tipos de proxy filtran de igual forma el tráfico http, entonces si, por ejemplo, queremos bloquear el portal http://www.mediafire.com y lo tenemos incluido en una "lista negra" del squid, entonces el proxy lo bloqueará, sin importar que sea transparente o no, pero si tratamos de ingresar a https://www.mediafire.com, solamente el proxy en modo no-transparente bloquearía este sitio, gracias a una "regla" (mas bien un método) de squid llamado CONNECT.
En síntesis, la diferencia entre ambos modos de proxy está únicamente en el modo en que procesa el tráfico https.
Pero.... Squid does not provide the SSL/HTTPS support
Sin embargo (y aquí viene algo muy interesante que nos apartará unos segundos del objetivo de esta publicación) debemos aclarar que lo anterior tampoco es 100% cierto, ya que CONNECT no valida HTTPS porque el protocolo HTTPS es definido por conexiones "end-to-end" .
Entonces puede suceder al intentar filtrar HTTPS en un proxy no-transparente, nos encontremos con una montaña de errores, como por ejemplo TCP_DENIED/403, TCP_MISS/503 0 CONNECT, etc. (Ver códigos de log en Squid)
dns_v4_first on acl to_ipv6 dst ipv6 http_access deny to_ipv6 !all tcp_outgoing_address 192.168.1.10 # ip del servidor proxy (si usa dns-local) o dns publico udp_outgoing_address 192.168.1.10 # ip del servidor proxy (si usa dns-local) o dns publico negative_dns_ttl 10 seconds http_access allow localnet icp_access allow localnet # DIRECT always_direct allow proxy # reemplazar proxy por el nombre de su servidor always_direct allow localnet never_direct allow CONNECT never_direct allow all # CACHE_PEER (cambie a 8080 si es transparente) cache_peer 192.168.1.10 parent 3128 0 proxy-only no-digest no-delay no-netdb-exchange dead_peer_timeout 2 seconds cache_peer_access 192.168.1.10 allow all # ip del servidor proxyEstos paleativos dependen de su versión (3.5 o superior) y ni así podemos garantizarlo. Pero tampoco nos debe quitar el sueño. Esto se soluciona como mismo se soluciona al problema del episodio del calentamiento global de la serie Futurama: "a mayor calentamiento, echamos un pedazo de hielo más grande en el océano"... Dicho en términos informáticos: "A mayor cantidad de errores del proxy, ampliamos más el ancho de banda y los recursos de hardware del servidor, ya que más rápido se procesan las peticiones y estos errores se vuelven imperceptibles".
Otra manera de evitarlo es desactivando IPv6, tanto en el servidor como en los clientes, lo cual puede representar una pesadilla logística si son redes locales con cientos de usuarios.
Y este es uno de los tantos errores a los que nos podemos enfrentar cuando se trata de filtrar https en el proxy Squid.
Nota: Vale aclarar sobre las directivas " always/never_direct" que hay una gran diferencia entre GET/POST. GET siempre usará "padres" a menos que sean reemplazados por always_direct y POST nunca los usará a menos que sea forzado por never_direct. GET generalmente se ve como una solicitud cacheable y POST no. Squid por defecto solo usa "padres" en las solicitudes donde el resultado pueda ser almacenado en caché. La configuración predeterminada es:
always_direct deny all always_direct deny allLo cual nos dice que Squid no está obligado a ir directamente a ninguna solicitud, y tampoco a usar "padres" en solicitudes, lo que permite a Squid elegir.
Volviendo a lo que nos interesa (proxy)... ¿Alguna otra cosa?
Pues a decir verdad, ninguna relevante, ya que las demás reglas de bloqueo o caching, etc, NO funcionan con tráfico https, en ningún modo de proxy. Por ejemplo, si queremos bloquear la extensión .exe (para evitar las descargas de aplicaciones con esta extensión en nuestra red local) y esta descarga viene por un enlace https, entonces nuestro proxy Squid no sería capaz de interceptarla y bloquearla, porque, como dijimos anteriormente, el tráfico https es cifrado y squid no es capaz de descifrarlo. Lo mismo aplica para otros tipos de reglas.
La Solución... Tendríamos que echar mano de nuestro firewall para hacer estos tipos de bloqueo con string y así frenar las descargas vía https.
Uso del Firewall para filtrar HTTPS por string, ips....
Así las cosas, cuando se trata de tráfico que involucra al protocolo https es muy poco lo que puede hacer el proxy Squid, y el modo en que se encuentre (transparente o no) es irrelevante. En ese orden de ideas, si estamos obligados a recurrir a un tercero (firewall) para bloquear algo que nuestro proxy Squid no es capaz de hacerlo, entonces porque no con filtrar todo el tráfico https con el firewall.
Uso del Firewall para filtrar HTTPS por string, ips....
Así las cosas, cuando se trata de tráfico que involucra al protocolo https es muy poco lo que puede hacer el proxy Squid, y el modo en que se encuentre (transparente o no) es irrelevante. En ese orden de ideas, si estamos obligados a recurrir a un tercero (firewall) para bloquear algo que nuestro proxy Squid no es capaz de hacerlo, entonces porque no con filtrar todo el tráfico https con el firewall.
Por ejemplo, podríamos validar en nuestro firewall las ips de sitios https que queremos permitir que entren a nuestra red local y bloquear el resto, dejando nuestro squid en modo transparente para que solo filtre el tráfico http; un método que ya explicamos con detalles en Firewall.
Puntos en contra del filtrado por Firewall
Pero no todo es recomendable hacerlo con un Firewall ya que son más lentos que un proxy cache a la hora de procesar filtrado de peticiones. Mientras el proxy puede procesar listas negras con millones de dominios web en cuestión de segundos, el firewall lo haría a una velocidad muchísimo mayor (x10), al punto que podría bloquearse y/o ralentizar el tráfico en la red local.
¿Hay otra alternativa?
Hay muchos proyectos (como Pi-Hole, etc) que usan dnsmasq para filtrar las peticiones, pero solo se limitan a bloquear dominios mediante la no resolución DNS, pero no bloquean extensiones ni hacen otros tipo de filtrado más exhaustivo como Squid.
Conclusión
El argumento de que un proxy no-transparente es superior y más seguro que un proxy transparente es un mito muy debatible, ya que las diferentes modalidades de filtrado tienen sus pros y sus contras.
A nuestro juicio, el filtrado del tráfico en una red local, cualquiera que sea (http, https, ftp, etc), depende más de la habilidad del sysadmin que del software o hardware que utilicemos para este propósito.
No queríamos finalizar sin hacer una reflexión. Si Google marcará todo el tráfico http como inseguro (y lo que hace google se ha convertido en ley), significa que, más temprano que tarde, internet migrará a https. Entonces Squid eventualmente quedará sirviendo para 3 cosas: para nada, para nada y para nada.
Si este proxy no puede cachear https, ni aplicar políticas restrictivas sobre este protocolo, salvo bloquear páginas, entonces ¿cuál es su futuro?... Si no se reestructura, estará destinado a morir lentamente ante la migración masiva a https, pero nuestro portal no esta calificado para decir qué va a suceder en el futuro, y mejor dejamos este tema tan especulativo en manos de los chamanes, adivinadores, brujos y brokers.
Lea: Autodetectar proxy en Firefox
Puntos en contra del filtrado por Firewall
Pero no todo es recomendable hacerlo con un Firewall ya que son más lentos que un proxy cache a la hora de procesar filtrado de peticiones. Mientras el proxy puede procesar listas negras con millones de dominios web en cuestión de segundos, el firewall lo haría a una velocidad muchísimo mayor (x10), al punto que podría bloquearse y/o ralentizar el tráfico en la red local.
¿Hay otra alternativa?
Hay muchos proyectos (como Pi-Hole, etc) que usan dnsmasq para filtrar las peticiones, pero solo se limitan a bloquear dominios mediante la no resolución DNS, pero no bloquean extensiones ni hacen otros tipo de filtrado más exhaustivo como Squid.
Conclusión
El argumento de que un proxy no-transparente es superior y más seguro que un proxy transparente es un mito muy debatible, ya que las diferentes modalidades de filtrado tienen sus pros y sus contras.
A nuestro juicio, el filtrado del tráfico en una red local, cualquiera que sea (http, https, ftp, etc), depende más de la habilidad del sysadmin que del software o hardware que utilicemos para este propósito.
No queríamos finalizar sin hacer una reflexión. Si Google marcará todo el tráfico http como inseguro (y lo que hace google se ha convertido en ley), significa que, más temprano que tarde, internet migrará a https. Entonces Squid eventualmente quedará sirviendo para 3 cosas: para nada, para nada y para nada.
Si este proxy no puede cachear https, ni aplicar políticas restrictivas sobre este protocolo, salvo bloquear páginas, entonces ¿cuál es su futuro?... Si no se reestructura, estará destinado a morir lentamente ante la migración masiva a https, pero nuestro portal no esta calificado para decir qué va a suceder en el futuro, y mejor dejamos este tema tan especulativo en manos de los chamanes, adivinadores, brujos y brokers.
Lea: Autodetectar proxy en Firefox
Post a Comment