[lacnog] ¿Cómo proteger una wireless IPv4-only de un ataque de RA IPv6?

[Carlos M. Martinez]

Para aclarar, en Haiti yo no intercepté nada, puse un router (bueno, un linux con radvd, dhcpv4, dhcpv6, bind9, el túnel con HE y la interfaz con el proveedor de Internet que nos daba conectividad) y la cifra que comparti de trafico surgio naturalmente. Lo que armamos con Arturo fue un router dual stack medio ad-hoc (basado en linux)

En un escenario donde si haya interceptación, eventualmente podes llegar a detectarlo.

Sobre el el ataque contra DHCP, la race condition no es tan dificil de encontrar, lo he visto demostrado, en particular en el evento de LACNIC de Panama se hizo una demostracion en la cual habia un rogue DHCP y una demostración de algo que nadie menciono aca, pero que es hasta mas facil de hacer: un rogue access point, el que te permite si interceptar _todo_ el trafico, v4, v6, etc.

Como dice Fernando, hemos llegado hasta acá a pesar de que hay un montón de problemas no resueltos en lo que seria seguridad de capa 2.

s2

Carlos

On Aug 9, 2012, at 11:57 AM, Eduardo Trápani wrote:

> 
>> Obviamente, el punto está en que funcionalidad tal como ra-guard no es
>> ampliamente soportada, y entonces, a la practica, no es solucionable.
> 
> Gracias.
> 
>> De cualquier modo, tampoco es cierto que todo el mundo implemente
>> dhcp-snooping y similares en IPv4, y asi y todo aqui estamos.
> 
> Leí ya varias veces la comparación.  Pero hay algo que me choca sobre ella:
> 
> DHCPv4 entrega una dirección, hay protección posible desde el software
> de algunos clientes y el éxito del ataque depende de una race condition.
> En IPv4-only DHCP es además opcional (en la red del tópico no).
> 
> Un rogue RA agrega direcciones a las ya existentes, no hay protección
> posible (en la red IPv4-only/IPv6-latente a menos que compres hardware
> dual-stack con RA-guard, lo configures y funcione) y el ataque es
> seguro, sabés que va a funcionar.  Además SLAAC viene habilitado por
> defecto en los sistemas, no es opcional.  Entiendo que ni con una ipv6
> estática deja de autoconfigurar.
> 
>> Aparte, si uno lo piensa, el "worst-case scenario" de una ataque de
>> estos en una conf es que a la gente no le quede otra que tener que
>> prestarle atención a las persentaciones  -- con lo cual, al final del
>> dia, de una u otra forma uno tiene el "exito" garantizado ;-))
> 
> ¿Seguro?  Lamentablemente no, el "worst-case scenario" es bastante peor,
> es alguien *interceptando* todo el tráfico IPv6, incluído potencialmente
> DNS.  Mirá la experiencia de Carlos Martínez en Haití[1] (que fue la que
> generó mi preocupación y consulta):
> 
>> Hace dos semanas estuve con Arturo en Haití y habilitamos IPv6 en la red 
>> del evento donde estabamos, sin decirle nada a nadie y usando un tunel. 
>> En 15 minutos el 30% del trafico de la red era IPv6, concretamente 
>> desde/hacia Facebook y 'Cosas Google varias'. Nadie se quejó, nadie dijo 
>> nada. Cuando se lo mostramos el comentario fue 'pero no tuvimos que 
>> hacer nada!'.
> 
> Para la parte de atención a las presentaciones no suena muy exitoso ;).
> Y el "worst-case scenario" parece un poquito worse ...
> 
> En una wireless pública uno podría esperar que le pasaran cosas, el tema
> es que esto es totalmente replicable en cualquier segmento ethernet
> IPv4-only con sistemas modernos (con IPv6 latente).  Algunos todavía no
> pueden darse el "lujo" (formación, compra de hardware, verificación de
> sistemas) de pasarse a IPv6.  Sin embargo cosas como esta tienen un lado
> "positivo", empujan violentamente la prioridad de empezar a aprender
> IPv6, aunque sea para aprender a poner cosas como (en Linux)
> 
> sudo sysctl -w net.ipv6.conf.all.autoconf=0
> sudo sysctl -w net.ipv6.conf.all.accept_ra=0
> 
> en los servidores mientras uno prepara todos los recursos necesarios
> para migrar.
> 
> Eduardo.
> 
> [1]
> http://listas.uylug.org.uy/pipermail/uylug-varios-uylug.org.uy/2012-July/002061.html
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: lacnog-unsubscribe en lacnic.net