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

[JORDI PALET MARTINEZ]

Windows Vista y 7 utilizan tambien un nuevo tipo de direcciones, que no son
de privacidad, pero no dependen de la Mac. Eso implica que la busqueda se
hace mas dificil y no es posible basarse en el OUI.

Espero que los administradores de red que decidan utilizar DHCPv6, asi como
los fabricantes de dicho software, sean precavidos y no caigan en este
error. En los trainings que nosotros hacemos para clientes, damos muchas
recomendaciones en este sentido.

Insisto en que el problema es que hay mucha gente "enseñando" IPv6, que
tiene conocimiento "casi cero" de los estandares y del protocolo en
profundidad, asi como de las consecuencias de no usar las herramientas que
IPv6 proporciona de forma adecuada. Igualmente, muchas empresas lo estan
desplegando sin formar adecuadamente a sus ingenieros ...

Las aplicaciones de las que hablas, precisamente, solo desvelarian
direcciones de privacidad, y estas son cambiantes (se pueden configurar para
que cambien incluso cada pocos minutos si se requiere, aunque creo que no es
necesario), asi que un ataque no podria tener lugar, dado que aun en el caso
de interceptar un mensaje de una de esas aplicaciones (por ejemplo email),
NO existiria ya esa direccion.

Y si, claro, si se ha ganado acceso a una sola maquina, el descubriemiento
del resto de la LAN parece trivial dado que un ping multicast a todos los
nodos los revela, SALVO, que como por defecto en muchas plataformas, estas
tengan firewall activado por defecto. La seguridad desde hace muchos años ya
no es un problema de firewall de "borde" sino de que cada nodo tiene que
estar protegido por si mismo.

La discusion en IETF de cambiar la longitud de las asignaciones ya ha tenido
lugar en otras ocasiones y nunca ha fructificado y sinceramente, espero que
no ocurra tampoco esta vez. Creo que seria malo, y nos llevaria de nuevo a
una situacion de ISPs que restringen el numero de direcciones que asignan a
los usuarios, y por tanto LIMITAN SU PROPIO NEGOCIO.

Sigo pensando que aunque se logren mejoran y dar inteligencia a las tecnicas
de port scanning, lo cual sin duda ocurrira, los tiempos necesarios, aun
cuando todos los usuarios residenciales tuvieran redes de 100 Mbps (FTTH),
no seran suficientes para lograr ataques que fructifiquen ni siquiera en una
proporcion de 1 a 1.000.000 (por decir algo), comparados con IPv4.

Creo que es importante leer todo el thread en NANOG para ver detalles que
otros, como Owen de HE, han comentado y que justifican claramente lo que
estoy diciendo.

Saludos,
Jordi




> From: Fernando Gont <fernando en gont.com.ar>
> Reply-To: <fernando en gont.com.ar>
> Date: Mon, 06 Sep 2010 15:49:34 -0300
> To: <jordi.palet en consulintel.es>
> Cc: <lactf en lac.ipv6tf.org>, Latin America and Caribbean Region Network
> Operators Group <lacnog en lacnic.net>, <seguridad en lacnic.net>
> Subject: Re: [LAC-TF] [lacnog] Fwd: just seen my first IPv6 network abuse
> scan, is this the start for more?
> 
> 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
> 
> 
> 
> 
> 



**********************************************
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.