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

Arturo Servin arturo.servin en gmail.com
Mar Mayo 13 14:53:28 BRT 2014


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.

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.

.as



2014-05-12 18:03 GMT-07:00 Iván Arce <ivan.w.arce en gmail.com>:

> 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.
> >
>
> _______________________________________________
> Seguridad mailing list
> Seguridad en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/seguridad
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20140513/1ac680ff/attachment.html>


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