[lacnog] Articulo: How to avoid security issues with VPN leaks on dual-stack networks

[Eduardo Trápani]

>>> The simplest option (though not necessarily the most desirable) is to
>> disable IPv6 support in all network interface cards when a VPN
>> connection is meant to be employed.
>>
>> ¿Qué debería entender por "network interface *cards*"?  No me queda
>> claro si incluye pseudo interfaces (tipo "tun/tap", que puede ser usado
>> por OpenVPN, y que no manejan NICs).
> 
> Otra respuesta seria "el advice aplica a cuanto elemento/interfaz te sea
> reportado por ifconfig/ipconfig"... :-)

¿Y eso no equivaldría a deshabilitar completamente IPv6?  ¿Para qué
enumerar?

Algo como (Linux):

ipv6.disable=1 como comando de arranque.

> Estoy en un bus en este momento (offline, y con pocos recursos). Pero me
> atreveria a decir que los OSes que no habilitan el rocesamiento de RDNSS
> "por defecto" lo haran en el corto plazo. -- sin ir mas lejos, SLAAC sin
> RDNSS es, salvo para casos puntuales, inutil.

Inútil...  Pero, en la red donde estoy ahora es justamente así.  Todos
tenemos IPv6, con SLAAC y el RA no anuncia nada más que el prefijo.  El
resolv.conf en cada equipo ya tiene los valores.  De repente justo este
es el caso puntual :), o no es deseable, pero se me hace que debe ser
bastante común.

> Mas alla de eso, hay otro vector similar para el atacante: enviar RAs
> con el bit "M" ("Managed") seteado, de modo que los hosts envien luego
> DHCPv6 requests. -- Y luego instalas el "recursive DNS server" via
> DHCPv6 (en vez de via SLAAC).

Pero tengo que tener instalado el cliente de DHCPv6.  Sin ese cliente y
sin el demonio rdnss no se puede.  Digamos que tengo que exponerme a
propósito.

En Ubuntu el NetworkManager puede procesar el RDNSS por defecto (pero se
puede apagar), así que depende también del entorno.

Algo más para agregar a las pautas de seguridad, una vez que procesar el
RDNSS se vuelva la norma, asegurarse, en los entornos donde esto sea
válido, que no te cambien el DNS si es estático, por ejemplo dentro de
una empresa.  Capaz que eso merece un artículo aparte...

>> Como todo parece empezar por la preferencia de IPv6 sobre IPv4,
> 
> Es mas, en un ataque real, no encuentro mucho argumento para publicar
> ambos, si al fin y al cabo lo que vos querés es que la victima use los
> AAAA y *no* los A.

Sí, está bien.  Yo lo que quiero es que la víctima saque el tráfico para
afuera.  Pero puede servirme también dar una dirección A, depende de qué
servicios tenés en la VPN.

Si tu VPN te da acceso NAT hacia la internet, un A te puede robar
tráfico igual.

Si tu VPN no te da acceso a internet, solo a una intranet (como la VPN
en la que estoy conectado ahora) entonces la ruta por defecto que
instala la VPN solamente abarca ese espacio de direcciones.  Ahí un A
modificado te puede sacar a otro lado, evitando esa ruta y robándote
tráfico.

>> ¿podría
>> ser una alternativa más (en Linux) el configurar gai.conf (la
>> configuración de getaddrinfo) para que se prefiera IPv4[1]? 
> 
> Esto es una alternativa para mitigar leaks que ocurren de forma casual,
> al visitar destinos dual-stack.
> 
> Sin embargo, personalmente no recomendaria esta estrategia: Por ej., si
> visitaras un destino v6-only, el leak ocurriria igual.

>>  Al menos
>> eso funcionaría para los hosts de destino que no sean IPv6-only y para

Eso mismo te decía :). Pero, yo entendí en el artículo que el host era
dual-stack y la VPN solamente manejaba IPv4.  En ese caso ni siquiera sé
si considerarlo un leak ;), ese tráfico nunca hubiera podido pasar por
la VPN.  Aunque te entiendo, la respuesta deseada si tu VPN tiene que
ser un embudo sería 'host not found'.

Entiendo que hay dos leaks que proponés, el casual, que se mitiga con
las preferencia de protocolo y el deliberado, que surge de un ataque.
Para ese segundo caso estaría bueno buscar más maneras para evitar que
te cambien el DNS.  Deshabilitar IPv6 es una, no tener instalados rndss
y dhcpv6 puede ser otra y ...

Y ... llegué a tu misma conclusión, lo más simple es deshabilitar IPv6 :).

> En cuanto llegue a casa voy a ver de hacer algunas pruebas con distintos
> OSes -- windows en particular.
> 
> Para quien quiera adelantarse :-), esto puede ensayarse con la
> herramienta ra6 del IPv6 toolkit: <http://www.si6networks.com/ipv6toolkit>.

Ojalá pueda adelantarme ...  Pero creo tendré que esperar cuentos tuyos.

Saludos, Eduardo.