[LAC-TF] [LACNIC/Seguridad] [lacnog] Fwd: just seen my firstIPv6 network abuse scan, is this the start for more?

[Arturo Servin]

	El próximo mes el LACNOG 2010. Además de que seguro habrá alguna presentación tocando estos temas de IPv6 (estrategias de migración, seguridad, etc.) creo que será una buena oportunidad para que los operadores, usuarios y vendors se reunan y platiquen informalmente sobre estas necesidades. 

	Por si aún no se registran:

http://www.lacnog.org/en/eventos/lacnog-2010/registro

Saludos,
-asn


On 7 Sep 2010, at 10:26, OPE Paredes John wrote:

> Buenos días,
> 
> Como responsable de los enlaces internacionales de la CNT, se ha estado trabajando también para prestar servicios masivos y de broadband con ipv6, pero estamos teniendo dificultades en cuanto a la definición de subredes, de DHCP y de si se podrá trabajar con pppoE o si existe otra posibilidad más segura y eficiente.
> 
> Si a los ISP de la región se nos puede asesorar mejor en este tema sería una mejor forma de asegurar un pronto creciemiento
> 
> Saludos Cordiales,
> John Paredes Valencia ING.
> BACKBONE ATM-IP/MPLS
> Arquitecto de Red
> Corporacion Nacional de Telecomunicaciones E.P.
> 	
> 	' (593)-2-3967035
> ) (593)-9-6183938
> *   john.paredes at cnt.com.ec 
> 
> 
> 
> -----Mensaje original-----
> De: seguridad-bounces at lacnic.net [mailto:seguridad-bounces at lacnic.net] En nombre de Arturo Servin
> Enviado el: Martes, 07 de Septiembre de 2010 7:22
> Para: lactf at lac.ipv6tf.org
> CC: Latin America and Caribbean Region Network Operators Group; seguridad at lacnic.net
> Asunto: Re: [LACNIC/Seguridad] [LAC-TF] [lacnog] Fwd: just seen my firstIPv6 network abuse scan, is this the start for more?
> 
> 
> 	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 at gmail.com>
>>> Reply-To: <nicoruiz at gmail.com>
>>> Date: Mon, 6 Sep 2010 20:52:33 -0500
>>> To: Latin America and Caribbean Region Network Operators Group
>>> <lacnog at lacnic.net>
>>> Cc: <jordi.palet at consulintel.es>, <lactf at lac.ipv6tf.org>,
>>> <seguridad at 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 at 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 at gont.com.ar || fgont at acm.org
>>>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> LACNOG mailing list
>>>> LACNOG at 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 at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lactf
> 
> _______________________________________________
> Seguridad mailing list
> Seguridad at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/seguridad
> _______________________________________________
> Seguridad mailing list
> Seguridad at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/seguridad