[lacnog] [LAC-TF] Fwd: just seen my first IPv6 network abuse scan, is this the start for more?

Carlos M. Martinez carlosmarcelomartinez en gmail.com
Lun Sep 6 23:40:13 BRT 2010


 Si, hay dos temas ahi. Lo que paso es que la discusion derivo para el
lado de la feasibilidad de los escaneos en IPv6.

On 9/6/10 10:52 PM, Nicolás Ruiz wrote:
> 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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20100906/6864f075/attachment.html>


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