Enredando con el cliente de Cisco Umbrella en OS X

Hace unos días me instalaron en la máquina Cisco Umbrella. Esta es una plataforma de seguridad en la nube que básicamente hace dos cosaS:

• Modifica la configuración DNS de la máquina para que cualquier petición sea redirigida hacia los servidores de Cisco Umbrella y analizada si se permite o no.
• Un tunel IPSEC - al menos en el caso del Mac - que manda por el mismo todo el tráfico hacia direcciones que considera problemáticas.

Puesto que me ha picado un poco la curiosidad, me he puesto a mirar un poco como está implementado. Empecemos por lo fácil. Si se tiene permisos de administrador, parar el Cisco Umbrella es tan fácil como esto:

launchctl unload "/Library/LaunchDaemons/com.opendns.osx.RoamingClientConfigUpdater.plist"

Aunque claro, tb me podéis decir - con razón que lo podéis desinstlar -, pero vamos, se trata de poder pararlo en un momento dado.

El mecanismo que utiliza es bastante pedreste para comprobar los nombres: Simplemente modifica el resolv.conf para que apunte a localhost donde estará escuchando el proceso dnscrypt-proxy que se encargará de rutar las peticiones DNS a la nube - Cisco recopilando información :) - y devolver la IP correcta o dirigirnos a una página donde se nos dice que no estamos autorizados a ir a esa dirección. Un ejemplo con lo más fácil de probar y que no está autorizado: Una de como Porn Hub:

$nslookup 
> www.pornhub.com
Server:     127.0.0.1
Address:    127.0.0.1#53

Non-authoritative answer:
Name:   www.pornhub.com
Address: 146.112.61.106
> 146.112.61.106
Server:     127.0.0.1
Address:    127.0.0.1#53

Non-authoritative answer:
106.61.112.146.in-addr.arpa name = hit-adult.opendns.com.

Authoritative answers can be found from:
> 

Podéis ver de la salida anterior del nslookup, la respuesta que nos devuelve cuando se busca la dirección IP de un sitio de vídeos lúdico-festivoses una IP que apunta a una página de opendns (Cisco Umbrella) diciéndonos que no está permitido.

Pero, ¿Qué ocurre si cambiamos el servidor de DNS al que hacemos la consulta?. Por ejemplo, vamos a usar uno de los servidores de Google, 8.8.8.8

$ nslookup 
> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53
> www.pornhub.com
Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
www.pornhub.com canonical name = pornhub.com.
Name:   pornhub.com
Address: 31.192.120.36

Pues nos está devolviendo el valor correcto de la IP del sitio prohibido :)

Este tipo de artimiñas pueden hacerse por el sencillo motivo que Umbrella no intercepta las librerías encargadas de resolver nombres en el sistema, al menos en Mac OS X. Lo único que hace es cambiar los servidores DNS que utiliza el resolver por defecto, que como veis en este ejemplo es fácil de saltar. Hay infinidad de maneras de saltarse esta restricción como un usuario normal en una máquina Unix, ya que la mayaría de personas tienes accesso a un ssh y a un proxy socks. Por ejemplo, un servidor ssh al que se tenga acceso y usar la opción -D para SOCKS.

Cambiando de tema, lo que me ha llevado a mirar un poco como funciona Cisco Umbrella fue llevarme la sorpresa que de buenas a primeras, tenía una tabla de rutas con 54000 entradas que se enrutaban a través de un tunel IPSec que crea el propio Cisco Umbrella. Por ejemplo, en mi máquina ese tunel es utun0 y al ejecutar un netstat -rn me di cuenta que existían miles de entradas que iban a través de dicho túnel. Esto forma parte del mecanismo de protección de IP y es una manera bastante sencilla de saber cual es la base de datos de IP sospechosas que tiene Cisco: Todas las que están en la tabla de rutas redirigidas al túnel. Con un simple netstat -rn|grep utun0|awk '{print $1}' y voilà.

Se puede obtener los nombres de aquellas IP que tengan resolución inversa con un script similar a este, aunque estaríamos bombardeando el server de Google, así que casi mejor usar uno propio :)

netstat -rn |grep utun0|awk '{print $1;}'| while read ip;do nslookup "$ip" 8.8.4.4;sleep 1;done|grep "name = "

Maraki: Infraestructura en red y negocio

Conocía los puntos de acceso que fabricaba Meraki: Lo llevabas a una oficina, los conectabas a tu red y el solito llamaba a sus servidores centrales. Los usuarios del mismo - previo pago de la correspondiente cuota anual - pueden gestionar el aparato a través de la infraestructura que Cisco ha desplagado en la nuble. Hoy he visto que Meraki ha extendido el concepto a switches y firewalls. Servicios de core de red gestionados desde la nube de Cisco.

Todos estos nuevos productos son un paso más en los servicios gestionados donde aunque seas el dueño del hardware vas a necesitar la cuota anual de uso. ¡Cómo ha cambiado la cosa, si uno mira apenas 5 o 6 años atrás!.

Si se piensa es un modelo de negocio que es el sueño húmedo de una compañía: ingresos recurrentes por renovación de licencias de uso y en una infraestructura de red que no se suele cambiar todos los años y donde las migraciones suelen ser costosas en tiempo y dinero.

Es algo similar a lo que ha ido pasando en el mundo del contenido de música y películas, y de lo que desearían los grandes estudios de videojuegos: Siempre es mejor hacer un streaming de los contenidos y pagar cada vez, que darte el soporte físico y pagar una sóla vez. En teoría eso debería de hacer que los streaming fueran más baratos.... en teoría.

Una maldad adicional: Si fuera un servicio de seguridad de un país, siempre sería más fácil atacar estos servicios gestionados. Imaginaros que un servicio de inteligencia extranjero coloca a alguien en Meraki de los que se encargan de dar soporte a estas infraestructuras ....

There is no cloud it's just someone else's computer

Pensando sobre Vodafone Pass

Supongo que muchos habréis visto este verano la publicidad del servicio de Vodafone Pass. Por una pequeña cuota al mes se puede tener acceso a redes sociales o servicios de streaming de música sin consumir los megas que se tienen contratados. Es decir, en función del destino del tráfico nos cobran de una manera u otra. Un servicio bastante interesante para los clientes que hacen uso de este tipo de aplicaciones.

Se entiende por neutralidad en la red al principio que los actores encargados de transportar el tráfico IP no discriminan, es decir, que entre otras cosas, no se puede cobrar de manera diferente en función de la aplicación que manda los datos. Ni que decir tiene que el servicio de Vodafone Pass no cumple con este principio.

Ahora, ¿beneficia o no a los usuarios esta nueva tarifa de Vodafone?. ¿Se debería prohibir este tipo de ofertas?. Cada uno puede sacar sus conclusiones.