[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 ivan.w.arce en gmail.com
Lun Mayo 12 22:03:37 BRT 2014


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.

Desde el punto de vista de seguridad , la recomendación mas sensata[1]
es siempre la de reducir la superficie de ataque y deshabilitar toda
funcionalidad que no sea explícitamente requerida o necesaria.


saludos,

-ivan

[1] ver "Economy of mechanism"  y "Fail-safe defaults" en  "The
Protection of Information in Computer Systems", Saltzer J. and Schroeder
M. , Communications of the ACM 17, 7 (July 1974).
http://www.cs.virginia.edu/~evans/cs551/saltzer/


On 5/12/14 8:48 PM, Carlos M. Martinez wrote:
> Igual, no creo que deshabilitar sea una buena recomendación, ya que el
> stack esta ahí y no es cierto que los administradores controlen el 100%
> del hardware que se.conecta a sus redes, mas en una epoca donde el BYOD
> cobra cada vez mas adeptos.
> 
> S2
> 
> Carlos
> 
> Sent with AquaMail for Android
> http://www.aqua-mail.com
> 
> On May 12, 2014 7:04:23 PM Arturo Servin <arturo.servin en gmail.com> wrote:
> 
>>
>> Para evitar que en una infraestructura de solo IPv4 te metan un "gol"
>> usando IPv6. Sin embargo contrario a la opinion del autor :)  mi
>> preferencia es que en lugar de deshabilitar la gente se ponga las
>> pilas e implemente IPv6 como se debe.
>>
>> Pero en gustos se rompen generos.
>>
>> Slds
>> as
>>
>>
>>
>> 2014-05-12 7:53 GMT-07:00 Erick Lobo Marín <erick.lobo en cgr.go.cr
>> <mailto:erick.lobo en cgr.go.cr>>:
>>
>>     Buenos días, ¿por qué se deshabilita en la Enterprise?, será para
>>     que los sistemas perimetrales (firewall, ids...) de seguridad
>>     tengan más "certeza" al aplicar las políticas de seguridad sobre
>>     éstas?
>>
>>     Atentamente,
>>     Costa Rica
>>     Erick Lobo
>>
>>     lgD
>>
>>
>>     El 11 de mayo de 2014, 13:19, Cristian F. Perez Monte
>>     <cdlt23 en gmail.com <mailto:cdlt23 en gmail.com>> escribió:
>>
>>
>>
>>
>>         2014-05-11 1:35 GMT-03:00 Fernando Gont <fernando en gont.com.ar
>>         <mailto:fernando en gont.com.ar>>:
>>
>>             Hola, Erick,
>>
>>             On 05/09/2014 05:01 PM, Erick Lobo Marín wrote:
>>             > Fernando: ¿Qué tan aceptado es el método que ha
>>             implementado Microsoft
>>             > en sus sistemas operativos Windows de generación
>>             aleatoria de la
>>             > dirección IPv6 sobre el tiempo?
>>
>>             Supongo que te referis a lo especificado en RFC 4941. En
>>             tal caso, te
>>             diría que con el correr del tiempo ha sido mas y mas
>>             aceptado por
>>             distintas plataformas -- aunque no todas ellas habilitan
>>             dichas
>>             direcciones por defecto. Las que recuerdo (de memoria) que
>>             implementan
>>             RFC 4941 son:
>>
>>             * Windows
>>             * FreeBSD
>>             * OpenBSD
>>             * Linux
>>
>>
>>             Windows las habilita por defecto. FreeBSD no. Y el resto
>>             no recuerdo...
>>
>>          
>>         En linux dependiendo de distribución y versión de kernel, he
>>         visto con y sin habilitación de lo especificado en el RFC 4941.
>>         En el caso de NetBSD no estaría tan seguro que no lo
>>         implementa, creería que si, sucede que por defecto viene todo
>>         desactivado.
>>
>>
>>             Mas alla de la habilitacion por defecto, es de notar que
>>             al menos en
>>             ambientes tipo Enterprise, este feature suele ser
>>             deshabilitado.
>>
>>
>>
>>             > Considerando entre las razones de su uso el evitar el
>>             tracking de la
>>             > dirección IP.
>>
>>             RFC 4941 no evita, per se, el tracking, sino que lo ahce
>>             mas dificil.
>>
>>             Cuando RFC4941 esta habilitado, se utilizan direcciones
>>             aleatorias para
>>             las conexiones salientes... pero las direcciones
>>             "tradicionales"
>>             (no-temporales) siguen ahí... por lo cual el tracking
>>             sigue siendo
>>             posible (ni hablar del escaneo, etc.).
>>
>>             Saludos, y gracias!
>>             --
>>             Fernando Gont
>>             e-mail: fernando en gont.com.ar <mailto:fernando en gont.com.ar>
>>             || fgont en si6networks.com <mailto:fgont en si6networks.com>
>>             PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF
>>             D076 FFF1
>>
>>
>>
>>             _______________________________________________
>>             LACTF mailing list
>>             LACTF en lacnic.net <mailto:LACTF en lacnic.net>
>>             https://mail.lacnic.net/mailman/listinfo/lactf
>>             Cancelar suscripcion: lactf-unsubscribe en lacnic.net
>>             <mailto:lactf-unsubscribe en lacnic.net>
>>
>>
>>
>>
>>
>>         _______________________________________________
>>         LACTF mailing list
>>         LACTF en lacnic.net <mailto:LACTF en lacnic.net>
>>         https://mail.lacnic.net/mailman/listinfo/lactf
>>         Cancelar suscripcion: lactf-unsubscribe en lacnic.net
>>         <mailto:lactf-unsubscribe en lacnic.net>
>>
>>
>>
>>     _______________________________________________
>>     LACTF mailing list
>>     LACTF en lacnic.net <mailto:LACTF en lacnic.net>
>>     https://mail.lacnic.net/mailman/listinfo/lactf
>>     Cancelar suscripcion: lactf-unsubscribe en lacnic.net
>>     <mailto:lactf-unsubscribe en lacnic.net>
>>
>>
> 
> 
> This body part will be downloaded on demand.
> 




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