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

Mar Sep 7 09:22:17 BRT 2010

	Creo que estamos en una situación muy similar a mediados de los 90's con IPv4 donde teníamos poco conocimiento del protocolo y lo único que queríamos era que funcionara. Posteriormente empezamos a mejorar esas conexiones haciéndolas más eficientes y más seguros.

	La diferencia con IPv6 es que ya tenemos la experiencia del resultado de no hacer las cosas tan bien como se podrían hacer y además ya no nos podemos dar el lujo de experimentar. Si bien es tentador configurar IPv6 con los requerimientos mínimos, yo los invitaría a hacer ese algo más y crear redes seguras y eficientes desde el principio como dice Jordi. Creo que no es fácil dado que habrá que aprender nuevas tecnologías (algunas quizá apenas gestándose) en poco tiempo para implementar IPv6 y para asegurar la convivencia con IPv4 durante algunos años.

	Creo que guías de como implementar IPv6 hay muchas, pero de como hacerlo seguro y eficiente no hay tantas. Estuve buscando en portalipv6.lacnic.net y no encontré. Como idea me queda que podría ser un buen tema o proyecto para algunos crear este material y compartirlo.

Saludos,
-asn

On 7 Sep 2010, at 03:32, JORDI PALET MARTINEZ wrote:

> Hola Nicolas,
> 
> No, ni siquiera se llego a producir una "situacion" de ataque, sino
> "warnings", ya que el sistema operativo aviso del mismo, lo cual es una
> buena ventaja !
> 
> "Since recently we noticed  "Neighbour table overflow" warnings from
> the kernel on a lot of Linux machines. As this was very annoying for
> us and our customers I started to dump traffic and tried to find the
> cause."
> 
> Saludos,
> Jordi
> 
> 
> 
> 
>> From: Nicolás Ruiz <nicoruiz en gmail.com>
>> Reply-To: <nicoruiz en gmail.com>
>> Date: Mon, 6 Sep 2010 20:52:33 -0500
>> To: Latin America and Caribbean Region Network Operators Group
>> <lacnog en lacnic.net>
>> Cc: <jordi.palet en consulintel.es>, <lactf en lac.ipv6tf.org>,
>> <seguridad en lacnic.net>
>> Subject: Re: [lacnog] [LAC-TF] Fwd: just seen my first IPv6 network abuse
>> scan, is this the start for more?
>> 
>> 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
>>> 
> 
> 
> 
> **********************************************
> The IPv6 Portal: http://www.ipv6tf.org
> 
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
> 
> 
> 
> _______________________________________________
> LACTF mailing list
> LACTF en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lactf