[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