[lacnog] unsubscribe

[Hazzim Anaya]

2010/9/6 Nicolás Ruiz <nicoruiz en gmail.com>

> Ahora estoy confundido con los comentarios de Jordi y Fernando. El
> mensaje original me dió la impresión que el problema no era que el
> port scanning encontrara equipos, sino que el proceso de host
> discovery consumió toda la memoria en un equipo de borde. En cuyo caso
> el problema es un DoS y la solución depende de liberar recursos
> (memoria) antes de tiempo si hay demasiados Host Discovery en
> progreso.
>
> nicolas
>
> 2010/9/6 Fernando Gont <fernando en gont.com.ar>:
> > Hola, Jordi,
> >
> > Mis comentarios van entre lineas...
> >
> >
> >> Al final todo depende de saber hacer bien las cosas.
> >
> > Si, siempre es asi. :-)
> >
> >
> >
> >> Si los administradores de redes no utilizan direcciones consecutivas ni
> >> patrones localizables, con tecnicas de aleatorizacion, la posibilidad de
> >> escannear un /64 sigue estando ahí,
> >
> > Al menos los datos arrojados por el estudio de Malone indican que las
> > direcciones  de "privacidad" no son dominantes. Aunque dado que Windows
> > utiliza "privacy addresses" por default, uno habria de esperar que este
> > fuera el caso en un futuro. *Salvo*¨que se vuelva predominante el uso de
> > DHCPv6 para la configuracion de direcciones, y que los mismos asignen
> > dichas direcciones con patrones previsibles.
> >
> > Hay mucho por verse, igual. Por ejemplo, las aplicaciones pueden "leak
> > out" ("develar"? :-) ) las direcciones utilizadas, por ej. en
> > encabezados de mails. En tal caso, incluso con direcciones "privacy" se
> > podrian encontrar hosts "vivos"... con el unico detalle que la ventana
> > de exposicion seria menor (ya que dichos hosts estarian disponibles en
> > dichas direcciones por menos tiempo).
> >
> >
> >> pero el tiempo necesario para ello sigue
> >> siendo tan grande, que es poco practico.
> >
> > Hay que entender que ganando acceso a un unico sistema en una LAN, el
> > escaneo se vuelve trivial (por ej., utilizando direcciones multicast,
> > sniffing, o lo que sea). -- este es otro factor a tener en cuenta.
> >
> >
> >
> >> Y si ademas a cada usuario, incluso
> >> a los uruarios residenciales se les entrega un /48, como debe ser, ese
> >> tiempo de escaneo de un /64, se multiplica por 65.535 veces ...
> >
> > Por lo que pude leer, en la IETF se esta evaluando asignar a usuarios
> > residenciales prefijos mas largos (Es decir, bloques de direcciones mas
> > cortos). -- ver discusion en el v6ops de la IETF.
> >
> >
> >
> >> Sigo pensando que se tardaran muchos años en llegar al mismo nivel de
> >> "facilidad" de hacer port-scanning que con un /24 en IPv4, y el tiempo
> >> requerido para ello, pero insisto, depende mucho de que los
> administradores
> >> de redes/seguridad sepan hacer bien su trabajo.
> >
> > Personalmente creo que lo que sucedera es que cambiara la metodologia de
> > escaneo. Hoy por hoy se utiliza scanning por fuerza bruta, sin aplicar
> > ningun tipo de inteligencia. Se me ocurre que en el futuro esto
> > cambiara. Por ej., podria utilizarse Google para identificar direcciones
> > IPv6 en mensajes enviados a lista de correo recientemente. O se podrian
> > probar direcciones "aleatorias", hasta encontrar un host "vivo", obtener
> > el OUI (fabricante de la placa de red), y luego barrer unicamente
> > direcciones con esos OUIs, etc.
> >
> > El tiempo dirá...
> >
> > Saludos,
> > --
> > Fernando Gont
> > e-mail: fernando en gont.com.ar || fgont en acm.org
> > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> >
> >
> >
> >
> >
> > _______________________________________________
> > LACNOG mailing list
> > LACNOG en lacnic.net
> > https://mail.lacnic.net/mailman/listinfo/lacnog
> >
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
>



-- 
M.S.I. Hazzim Ivan Anaya Casas
Redes y Telefonia
Facultad de Contaduria y Administracion
Tel (614) 442-00-70
Ext. 6704, 6724
http://hazzimanaya.com/
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20100906/aa800df2/attachment.html>