<div dir="ltr"><br><div>También que la seguridad es tan buena como el eslabón más débil, en estos casos el dispositivo del usuario que trae IPv6 activado por default y que el administrador no tiene control sobre él.</div><div>
<br></div><div>Creo que la medida no es desactivar IPv6, si no asegurar que la red esta protegida ante ataques IPv6 aunque solo se use IPv4. Esa debe ser la mejor práctica.</div><div><br></div><div>.as</div><div><br></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-12 18:03 GMT-07:00 Iván Arce <span dir="ltr"><<a href="mailto:ivan.w.arce@gmail.com" target="_blank">ivan.w.arce@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
La experiencia práctica de los ultimos 15+ años me ha demostrado que<br>
esperar a que "la gente se ponga las pilas e implemente X como se debe"<br>
es una quimera.<br>
<br>
Desde el punto de vista de seguridad , la recomendación mas sensata[1]<br>
es siempre la de reducir la superficie de ataque y deshabilitar toda<br>
funcionalidad que no sea explícitamente requerida o necesaria.<br>
<br>
<br>
saludos,<br>
<br>
-ivan<br>
<br>
[1] ver "Economy of mechanism" y "Fail-safe defaults" en "The<br>
Protection of Information in Computer Systems", Saltzer J. and Schroeder<br>
M. , Communications of the ACM 17, 7 (July 1974).<br>
<a href="http://www.cs.virginia.edu/~evans/cs551/saltzer/" target="_blank">http://www.cs.virginia.edu/~evans/cs551/saltzer/</a><br>
<div class=""><br>
<br>
On 5/12/14 8:48 PM, Carlos M. Martinez wrote:<br>
> Igual, no creo que deshabilitar sea una buena recomendación, ya que el<br>
> stack esta ahí y no es cierto que los administradores controlen el 100%<br>
> del hardware que se.conecta a sus redes, mas en una epoca donde el BYOD<br>
> cobra cada vez mas adeptos.<br>
><br>
> S2<br>
><br>
> Carlos<br>
><br>
> Sent with AquaMail for Android<br>
> <a href="http://www.aqua-mail.com" target="_blank">http://www.aqua-mail.com</a><br>
><br>
> On May 12, 2014 7:04:23 PM Arturo Servin <<a href="mailto:arturo.servin@gmail.com">arturo.servin@gmail.com</a>> wrote:<br>
><br>
>><br>
>> Para evitar que en una infraestructura de solo IPv4 te metan un "gol"<br>
>> usando IPv6. Sin embargo contrario a la opinion del autor :) mi<br>
>> preferencia es que en lugar de deshabilitar la gente se ponga las<br>
>> pilas e implemente IPv6 como se debe.<br>
>><br>
>> Pero en gustos se rompen generos.<br>
>><br>
>> Slds<br>
>> as<br>
>><br>
>><br>
>><br>
>> 2014-05-12 7:53 GMT-07:00 Erick Lobo Marín <<a href="mailto:erick.lobo@cgr.go.cr">erick.lobo@cgr.go.cr</a><br>
</div>>> <mailto:<a href="mailto:erick.lobo@cgr.go.cr">erick.lobo@cgr.go.cr</a>>>:<br>
<div class="">>><br>
>> Buenos días, ¿por qué se deshabilita en la Enterprise?, será para<br>
>> que los sistemas perimetrales (firewall, ids...) de seguridad<br>
>> tengan más "certeza" al aplicar las políticas de seguridad sobre<br>
>> éstas?<br>
>><br>
>> Atentamente,<br>
>> Costa Rica<br>
>> Erick Lobo<br>
>><br>
>> lgD<br>
>><br>
>><br>
>> El 11 de mayo de 2014, 13:19, Cristian F. Perez Monte<br>
</div>>> <<a href="mailto:cdlt23@gmail.com">cdlt23@gmail.com</a> <mailto:<a href="mailto:cdlt23@gmail.com">cdlt23@gmail.com</a>>> escribió:<br>
<div class="">>><br>
>><br>
>><br>
>><br>
>> 2014-05-11 1:35 GMT-03:00 Fernando Gont <<a href="mailto:fernando@gont.com.ar">fernando@gont.com.ar</a><br>
</div>>> <mailto:<a href="mailto:fernando@gont.com.ar">fernando@gont.com.ar</a>>>:<br>
<div><div class="h5">>><br>
>> Hola, Erick,<br>
>><br>
>> On 05/09/2014 05:01 PM, Erick Lobo Marín wrote:<br>
>> > Fernando: ¿Qué tan aceptado es el método que ha<br>
>> implementado Microsoft<br>
>> > en sus sistemas operativos Windows de generación<br>
>> aleatoria de la<br>
>> > dirección IPv6 sobre el tiempo?<br>
>><br>
>> Supongo que te referis a lo especificado en RFC 4941. En<br>
>> tal caso, te<br>
>> diría que con el correr del tiempo ha sido mas y mas<br>
>> aceptado por<br>
>> distintas plataformas -- aunque no todas ellas habilitan<br>
>> dichas<br>
>> direcciones por defecto. Las que recuerdo (de memoria) que<br>
>> implementan<br>
>> RFC 4941 son:<br>
>><br>
>> * Windows<br>
>> * FreeBSD<br>
>> * OpenBSD<br>
>> * Linux<br>
>><br>
>><br>
>> Windows las habilita por defecto. FreeBSD no. Y el resto<br>
>> no recuerdo...<br>
>><br>
>><br>
>> En linux dependiendo de distribución y versión de kernel, he<br>
>> visto con y sin habilitación de lo especificado en el RFC 4941.<br>
>> En el caso de NetBSD no estaría tan seguro que no lo<br>
>> implementa, creería que si, sucede que por defecto viene todo<br>
>> desactivado.<br>
>><br>
>><br>
>> Mas alla de la habilitacion por defecto, es de notar que<br>
>> al menos en<br>
>> ambientes tipo Enterprise, este feature suele ser<br>
>> deshabilitado.<br>
>><br>
>><br>
>><br>
>> > Considerando entre las razones de su uso el evitar el<br>
>> tracking de la<br>
>> > dirección IP.<br>
>><br>
>> RFC 4941 no evita, per se, el tracking, sino que lo ahce<br>
>> mas dificil.<br>
>><br>
>> Cuando RFC4941 esta habilitado, se utilizan direcciones<br>
>> aleatorias para<br>
>> las conexiones salientes... pero las direcciones<br>
>> "tradicionales"<br>
>> (no-temporales) siguen ahí... por lo cual el tracking<br>
>> sigue siendo<br>
>> posible (ni hablar del escaneo, etc.).<br>
>><br>
>> Saludos, y gracias!<br>
>> --<br>
>> Fernando Gont<br>
</div></div>>> e-mail: <a href="mailto:fernando@gont.com.ar">fernando@gont.com.ar</a> <mailto:<a href="mailto:fernando@gont.com.ar">fernando@gont.com.ar</a>><br>
>> || <a href="mailto:fgont@si6networks.com">fgont@si6networks.com</a> <mailto:<a href="mailto:fgont@si6networks.com">fgont@si6networks.com</a>><br>
<div class="">>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF<br>
>> D076 FFF1<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> LACTF mailing list<br>
</div>>> <a href="mailto:LACTF@lacnic.net">LACTF@lacnic.net</a> <mailto:<a href="mailto:LACTF@lacnic.net">LACTF@lacnic.net</a>><br>
<div class="">>> <a href="https://mail.lacnic.net/mailman/listinfo/lactf" target="_blank">https://mail.lacnic.net/mailman/listinfo/lactf</a><br>
>> Cancelar suscripcion: <a href="mailto:lactf-unsubscribe@lacnic.net">lactf-unsubscribe@lacnic.net</a><br>
</div>>> <mailto:<a href="mailto:lactf-unsubscribe@lacnic.net">lactf-unsubscribe@lacnic.net</a>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> LACTF mailing list<br>
>> <a href="mailto:LACTF@lacnic.net">LACTF@lacnic.net</a> <mailto:<a href="mailto:LACTF@lacnic.net">LACTF@lacnic.net</a>><br>
<div class="">>> <a href="https://mail.lacnic.net/mailman/listinfo/lactf" target="_blank">https://mail.lacnic.net/mailman/listinfo/lactf</a><br>
>> Cancelar suscripcion: <a href="mailto:lactf-unsubscribe@lacnic.net">lactf-unsubscribe@lacnic.net</a><br>
</div>>> <mailto:<a href="mailto:lactf-unsubscribe@lacnic.net">lactf-unsubscribe@lacnic.net</a>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> LACTF mailing list<br>
>> <a href="mailto:LACTF@lacnic.net">LACTF@lacnic.net</a> <mailto:<a href="mailto:LACTF@lacnic.net">LACTF@lacnic.net</a>><br>
<div class="">>> <a href="https://mail.lacnic.net/mailman/listinfo/lactf" target="_blank">https://mail.lacnic.net/mailman/listinfo/lactf</a><br>
>> Cancelar suscripcion: <a href="mailto:lactf-unsubscribe@lacnic.net">lactf-unsubscribe@lacnic.net</a><br>
</div>>> <mailto:<a href="mailto:lactf-unsubscribe@lacnic.net">lactf-unsubscribe@lacnic.net</a>><br>
>><br>
>><br>
><br>
><br>
> This body part will be downloaded on demand.<br>
<div class="HOEnZb"><div class="h5">><br>
<br>
_______________________________________________<br>
Seguridad mailing list<br>
<a href="mailto:Seguridad@lacnic.net">Seguridad@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/seguridad" target="_blank">https://mail.lacnic.net/mailman/listinfo/seguridad</a><br>
</div></div></blockquote></div><br></div>