Header Ads

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:
/sbin/iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
Y abrir el puerto intercept en el squid3
http_port 192.168.1.10:8080 intercept
Pero 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:
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 wpad-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
8. No es compatible con todas las distros de Linux
9. No es compatible con todos los navegadores en todas sus versiones (Mozilla requieren de un servidor DNS-Local e IE 7 y 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). En todo caso, su compatibilidad es limitada, y funciona bien solo en las versiones más recientes de los navegadores más usados (ver recuadro)
Compatibilidad WPAD con los navegadores más usados (versiones recientes). Mozilla requiere DNS-LOCAL
10. No hay acceso al nombre de host de la máquina
11. No tiene un método fiable 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. Acceso limitado a Javascript
15. 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.
16. 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-proxysmart-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 (como Google Chrome, IE 10, 11, Mozilla) 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 un mecanismo perfecto que solucione de una manera segura 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 (quisiera ver a un experto configurando "a mano" una red de 1000 equipos itinerantes).
Ante este panorama "de peros", un tanto sombrío, nos preguntamos:
¿Cuál es realmente la diferencia entre un proxy no-transparente y uno transparente, que ocasiona que la mayoría de los administradores IT se decanten por el primero?
La respuesta, casi al unísono, es que el filtrado es más completo en un proxy no-transparente, sin embargo vamos a poner en consideración este planteamiento.
Proxy transparente vs Proxy no-transparente
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 este post) 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:
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 proxy
Sin embargo estos paleativos dependen de su versión (siempre que sea 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 (mas paranoica) 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.
Volviendo a lo que nos interesa (transparente vs no-transparente)... ¿Alguna otra diferencia?
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.
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.
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 el post 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.
Conclusión
Hemos podido constatar que no todo es blanco o negro, sino gris y 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 administrador IT y de las políticas de seguridad que implementemos, que del tipo de proxy que utilicemos.
Reflexión
No queríamos finalizar este post 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. En ese orden de ideas, Squid 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.
Con la tecnología de Blogger.