[LACNIC/Seguridad] [LAC-TF] Fwd: RFC 7217 on A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)

[Iván Arce]

Hola Carlos


On 5/13/14 4:51 PM, Carlos M. Martinez wrote:
> Hola!
> 
> On 5/12/14, 10:03 PM, Iván Arce wrote:
>> La experiencia práctica de los ultimos 15+ años me ha demostrado que
>> esperar a que "la gente se ponga las pilas e implemente X como se debe"
>> es una quimera.
> 
> Igual de quimera que creer que uno como administrador controla el 100%
> del hw y sw que se conecta o usa la red. Aparentemente estamos ante una
> elección entre quimeras.


Yo coincido con que es una quimera creer que un administrador pueda
controlar todos los dipositivos que existen en su red pero ello no
implica que la mejor recomendación de seguridad sea "dejemos las cosas
como estan y que alguien (quien?) se ponga la pilas para implementar bien"

> 
> Basta snifear un rato cualquier red para ver la cantidad increible de
> basura que circula por ella para ver que esa ilusión de control
> absoluto, es eso, una ilusión.
> 

Completamente de acuerdo, pero entonces por qué dejar todo prendido y
aumentar la cantidad de tráfico basura?


> ¿Cuantas redes corporativas de nuestra región implementan L2 security
> (802.1X) ? Estoy seguro que hay honrosas excepciones, pero me temo que
> no son la mayoría.

No puedo comentar sobre el tema porque no dispongo de evidencia empírica
para corroborar o flasear la hipotesis. Hay algún  estudio publicado
sobre el tema?

> 
> Mi problema con estas recomendaciones de 'deshabilitar X' es que en la
> cadena de pensamiento de los administradores de redes corporativas, esto
> fluye así:
> 
> 1- emitimos una politica corporativa que dice 'deshabilito ipv6'
> 2- [1] implica que ipv6 no existe en la red
> 3- [2] implica que puedo ignorar ipv6 a todo nivel, en mi firewall, en
> mis logs de dhcp, en mi antivirus, en mi antispam. De esa manera ahorro
> costos, de todas maneras sintiéndome seguro
> 
> El problema es que [2] *no es cierto en la gran mayoría de los casos*
> por lo que lo que sigue a continuación se cae por su propio peso.

Ok pero, nuevamente,  ese argumento dificilmente justifica la
recomendación de no deshabilitar IPv6 y que alguien se ponga las pilas
para implementar bien.

Que tal deshabilitar IPv6 por defecto y que alguien se ponga las pilas
para bien?

EL hecho objetivo es que deshabilitar IPv6 reduce la superficie de
ataque lo cual, en términos de seguridad, es preferible que no hacerlo.

La discusión sobre si es mejor fail-open vs. fail-close, whitelist vs.
blakclist, default deny vs. default allow fue zanjada hace años en la
disciplina de seguridad informática.

Sobre lo demás podemos debatir ad infinitum.

De todas formas, el mensaje original no era respecto de deshabilitar
IPv6 sino sobre deshabilitar generación de ifIDs segun RFC 4941.

Creo que si alguien se toma el trabajo de habilitar IPv6 (si el default
fuera que este deshabilitado) tendría sentido que tambien habilite
RFC4941 pero no estoy completamente convencido.


> Lo anterior no es exclusivo de IPv6, sustituyan IPv6 por <cualquier
> tecnología ampliamente implementada en dispositivos que los usuarios
> pueden comprar o conseguir> y se aplica exactamente lo mismo.

completamente de acuerdo!

Deshabilitar por defecto todo aquello que no es necesario es una buena
recomendación general. Se aplica tambien a IPX, por ejemplo.


> En la vida 'off line' sería el equivalente de decir que puedo no tener
> policía porque de todas maneras los robos y los asesinatos están
> prohibidos por una ley.

No me atrevería a hacer tamaña analogía pero en todo caso no es lo que
yo sugerí. En ningun momento dije deshabiliten IPv6 y olvidense de
aplicar buenas prácticas de seguridad de redes y seguridad en los endpoints.

saludos,

-ivan