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

Eduardo Trápani etrapani en gmail.com
Dom Ene 27 02:36:00 BRST 2013


Lo leí y me quedaron un par de dudas:

> 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).

> An attacker could simply pose as the local recursive DNS server by
sending forged Router Advertisement messages that include the corresponding
RDNSS option

¿Es así de fácil?  Es decir, ¿eso alcanza en algún sistema con una
instalación "por defecto" para que el sistema olvide su resolv.conf y pase
a usar el nuevo servidor?  En Linux por lo menos, creo que tenés que
instalar *y* configurar el demonio rdnssd.

> If an application at the host attempts to communicate with a dual-stacked
system, it typically queries both A and AAAA DNS resource
records<http://whatis.techtarget.com/definition/AAAA-resource-record>.
If the host supports both IPv4 and IPv6 connectivity but prefers an IPv6
destination address, even though the other system has both A and AAAA DNS
resource records, the host will employ IPv6 to communicate with the
aforementioned system.

Como todo parece empezar por la preferencia de IPv6 sobre IPv4, ¿podría ser
una alternativa más (en Linux) el configurar gai.conf (la configuración de
getaddrinfo) para que se prefiera IPv4[1]?  Al menos eso funcionaría para
los hosts de destino que no sean IPv6-only y para las aplicaciones que usen
esa biblioteca (me parece que todas las ipv6-aware).  Al día de hoy creo
que eso puede ayudar a mitigar bastante el problema del tráfico ipv6 por
afuera de la VPN.  Siempre y cuando lo del RDNSS que mencionabas no sea así
de fácil, porque ahí podés hacer que cualquier host se vea como IPv6-only.

Eduardo.

[1] http://tools.ietf.org/html/rfc3484#section-10.3
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20130127/b6974d02/attachment.html>


Más información sobre la lista de distribución LACNOG