sábado, 21 de mayo de 2011

Probando, probando... ipv6 !!

Bueno va llegando hora de ponerse manos a la obra y probar la conectividad de ipv6. Yo utilizo Linux, en concreto Fedora. Actualmente las distros de Linux vienen con el módulo de ipv6 cargado por defecto, si no basta con ejecutar:

modprobe ipv6

Con esto el módulo del kernel para ipv6 se cargará en memoria y podemos configurar la tarjeta de red con una dirección ipv6. Pero... vivimos aun en un mundo ipv4. Mi router es ipv4, mi ISP me asigna dirección ipv4, así que la única solución que me queda es configurar un túnel para encapsular las direcciones IPv6 en un paquete ipv4 para enrutarlo por internet. Para ello busco un "tunnel broker" que son sitios que nos asignan un prefijo de red ipv6 y nos gestionan un los extremos de túnel con un servidor de túneles ipv6-ipv4, facilitándonos las cosas bastante. Un tunnel broker puede entenderse entoces  como un "ISP virtual". Existen muchos brokers ,en mi caso escogí  el ofrecido por hurricane electric donde te registras y mediante un sencillo menú seleccionas un servidor de túnel y configuras tu tarjeta para encapsular tu tráfico ipv6 sobre ipv4.

Los pasos que da un tunel broker unas vez te has autenticado son: ver RFC 3053

  • Te asigna un servidor de tunel que será usado como un extremo del tunel
  • Te asigna un prefijo de red
  • Fija un tiempo de vida para el túnel
  • Registra en su DNS las direcciones ipv6 globales asignadas a los extremos del túnel
  • Configura el lado servidor del túnel
  • Informa al cliente de la configuración de su extremo, incluso instruye sobre los comandos para la creación del túnel.


En mi caso una vez configurado la cosa quedó:

modprobe ipv6
ip tunnel add he-ipv6 mode sit remote 216.66.84.42 local 192.168.50.201 ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:1f12:813::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6
ip -f inet6 addr


Donde  216.66.84.42 es la dirección del tunel server que me asignaron ,  192.168.64.21 es mi dirección local (tras el NAT de mi router, pensé que no funcionaría :D ) y 2001:470:1f12:813::2/64 es la direccion ipv6 global asignada:
[root@lobobinario networking]# ifconfig -a

eth1      Link encap:Ethernet  HWaddr 00:23:CD:B4:DC:5E  
          inet addr:192.168.50.201  Bcast:192.168.50.255  Mask:255.255.255.0
          inet6 addr: fe80::223:cdff:feb4:dc5e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11323 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10868 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:8961913 (8.5 MiB)  TX bytes:1942426 (1.8 MiB)
          Interrupt:23 Base address:0x4c00 

he-ipv6   Link encap:IPv6-in-IPv4  
          inet6 addr: 2001:470:1f12:813::2/64 Scope:Global
          inet6 addr: fe80::c0a8:32c9/128 Scope:Link
          UP POINTOPOINT RUNNING NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:12 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:720 (720.0 b)  TX bytes:720 (720.0 b)

sit0      Link encap:IPv6-in-IPv4  
          NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0bio
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
NOTA: Estas configuraciones son temporales. Para hacerlas permanentes tras un reinicio de la máquina debes hacer los cambios necesarios en los ficheros de configuracion de los interfaces de red.

El resultado fue: 


Hubieran estado bien unas capturas de Wireshark... peeeero.

Aullidos binarios.

martes, 17 de mayo de 2011

Notas de Seguridad en IPv6: Seguridad en el control del tráfico. (III de III)

Para prevenir  tráfico ipv6  no deseado o no autorizado relacionado con  internet algunas recomendaciones serían:

  • Firewalls
    • Si no tenemos soporte IPv6 en nuestro site, debemos evitar que hosts de la intranet usen túneles Ipv6 a Ipv4 para alcanzar internet configurarndo los firewall IPv4 para descartar todo el tráfico de salida marcado con protolo IP 41 (tunel). En el otro sentido, denegando en el firewall los paquetes IP 41 de entrada, evitaremos que alguien desde internet use un tunel para inyectar trafico ipv6 en la red
  • Intranet con IPv6 ISATAP
    • Configurar correctamente ISATAP de modo que la ruta por defecto nunca se dirija hacia la red IPv4 y siempre lo haga hacia el router ISTAP que es el elemento que manejará la redirección hacia la porción interna de la red que implementa IPv6
    • En el firewall asegurar que se descartará el trafico IP 41
  • Teredo
    • Para prevenir que via Teredo se pueda establecer contacto con internet , igualmente como medida preventiva se descartará en el firewall el tráfico UDP 3544. Esta medida no sería eficaz si el puerto UDP se cambiase a otro y en ese caso tendríamos que recurrir a  técnicas de inspeccion de tráfico
En el caso que tuviésemos que permitir tráfico IPv6 con internet, la recomendación principal es actualizar firewall, proxy e IDS para incluir funcionalidades IPv6, añadido a las ya comentadas de autoconfiguración de direccion y de seguridad en los paquetes IP




sábado, 14 de mayo de 2011

Notas de Seguridad en IPv6: Seguridad en los paquetes IP. (II de III)


Continuando con las recomendaciones de seguridad para IPv6, vamos a abordar el tema de la seguridad de los paquetes. IPv6 por definición implementa obligatoriamente IPSec lo cual nos brinda un gran avance en la seguridad respecto a IPv4 donde es opcional. IPSec usa criptografía para proporcionar seguridad de los datos e incluso las cabeceras (modo túnel) evitando con ello el spoofing o cambio de las direcciones IP de los paquetes. Es un estándar definido en los RFCs 4301-4303.

En este caso vulnerabilidad  se localiza en las tecnologías de transición de IPv4 a IPv6, en concreto en los túneles  que se usan para transmitir paquetes de versión 6 sobre redes IPv4. Las tecnologías de túneles que se contemplan son 6to4 que establece comunicación unicast a través de internet sobre IPv4,  ISATAP  o comunicación unicast dentro de una intranet IPv4  y Teredo (desarrollo de Microsoft, RFC 4380) donde la comunicación unicast es por internet IPv4 añadiendo soporte para redes con NAT.

En el caso de los túneles para IPv4 el paquete IPv6 se encapsula en un paquete IPv4 y por tanto con las mismas vulnerabilidades. Lo que debemos hacer es identificar los túneles y  proteger su tráfico en IPv4 con IPSec:
  • ISATAP fija el campo "IP Protocol" a 41------> Establecer IPSec para IPv4 si IP protocol=41 y proteger ese tráfico. Puede hacerse ya que al estar en una intranet podemos fijar la clave compartida por los extremos IPSec sobre ipv4
  • 6to4 también marca IP protocol a 41 pero atraviesa internet. 6to4  se identifica porque las direcciones tienen el prefijo 2002::/16 y son direcciones IPv6 que se encaminarán a través de ipv4 hacia otro domino 6to4 , para ello el router cuando debe recibe este prefijo sabe que dentro hay un destino 6to4 que tiene que atravesar IPv4 y que debe entegarlo a otro router que maneje los prefijos 2002::/16 y que tenga conectividad ipv4 (llamado relay 6to4). El relay se encargará enrutar el paquete por internet bajo IPv4 encápsulandolo en un paquete marcado con "IP=41". En este caso solo podremos usar IPSec para proteger ipv4 si el router Ipv6 y el relay 6to4 se encuentran en el mismo dominio administrativo de de red  y se supone que existe una confianza entre ambos como para compartir la configuración necesaria para establecer IPSec (autenticación). Si la organización no tuviese su propio relay 6to4 no podríamos usar IPSec (salvo que nuestro proovedor de relay nos diese confianza) . Sin IPSec,  la seguridad debemos basarla en el filtrado del tráfico en el router de relay y establecer reglas para que solo se admitan paquetes IP 41 con el prefijo anycast de nuestra red. O quizás en una VPN....
  • Teredo usa el puerto 3544 y encapsula el paquete IPv6 en un datagrama UDP----->Establecer IPSec para IPv4 si puerto origen o destino es UDP 3544 . Teredo no necesita una IP v4 pública en el destino para hacer llegar el paquete Ipv6 encapsulado ya que se basa en una solución cliente/servidor UDP



Notas de Seguridad en IPv6: Seguridad en la autoconfiguración de direcciones

Con la inevitable llegada de IPv6 llegarán nuevas amenazas para la seguridad de la información. Por ello, además de ir planeando la actualización de protocolos y equipos a IPv6 habrá revisar las implicaciones a nivel de seguridad, y teniendo en cuenta aquellas características necesarias de este protocolo debemos hacer hincapié en:

  1. Seguridad en Autoconfiguración  y autorización de direcciones. Amenaza de Denegación (DoS) o suplantación de identidad , Man in the Middle. (Disponibilidad, Autenticidad) 
  2. Seguridad en Protección de los paquetes IP. ( Confidencialidad, Integridad )
  3. Seguridad en Control del tráfico de y hacia internet. ( Autorización, control acceso )
Vamos a discutir estos tres aspectos a los que dedicaré una entrada independiente para cada uno.

Comencemos pues: 

  1. Seguridad en la Autoconfiguración y Autorización para las direcciones y configuraciones automáticamente asignadas

Bien, como sabemos, una de las novedades de IPv6 es la autoconfiguración de la dirección IP. Esto puede hacerse por dos métodos: stateless o stateful .

En la autoconfiguración stateless el host genera su  dirección IP bien a partir de su propia MAC o bien generando una direccion aleatoria. Durante este este proceso el host interroga al entorno de red  por si algún dispositivo está usando esa dirección. Además si está conectado a una red donde exista un enrutador recibirá de él el resto de parámetros, como puede ser el prefijo de red. Estas acciones se realizan siguiendo el protocolo Neighbor Discovery Protocol (NDP) descrito por el RFC 2461 y a través de  los mensajes Neighbor Solicitation, Neighbor Advertisement, Router Solicitation y Router Advertisement. 
Aquí ya surge la primera amenaza de un posible ataque de DoS  si un host malicioso interceptara y  propagase un mensaje de Neighbor Solicitation, informando que la dirección solicitada está en uso (ICMP 136) e impidendo el acceso a la red (DoS)
ATAQUE DoS

Neighbor Solicitation ICMP 135 (Duplicate Address Detection) y ataque con ICMP 136 (Direccion ocupada)

Del mismo modo el atacante pude hacerse pasar por un router estableciendo un ataque  Man in the Middle atacando al mensaje Router Solicitation (ICMP 133) con el Router Advertisement (ICMP 134).


En la configuración stateful, la dirección IP se obtiene por DHCPv6 (RFC 3315) que puede ser blanco también de los mismos ataques que la autoconfiguración stateless por alguien mailintencionado que generase los mensajes DHCPv6.

En resumen, el ataque de spoofing ARP de IPv4/icmp se convierte en un ataque NDP spoofing en IPv6/icmpv6
Mensajes informativos ICMPv6

Recomendaciones de Seguridad

Contra esta amenaza  de denegación o suplantación (DoS o Man in the Midle), concluimos que la solución pasa por autentificar al dispositivo en capa 2 antes de darle acceso a la capa de red que inicie la autoconfiguración de IP.
Una opción posible contra  este problema la ofrece el protocolo de capa 2 SEND (SEcure Neighbor Discovery, RFC 3971) que es una extensión de NDP, y que haciendo uso de criptografía asimétrica y firma electrónica autentifica un host antes de permitirle acceso a la capa de red . SEND aún no es implementado por muchos sistemas operativos, careciendo de él, por ejemplo  los de Microsoft (Vista, XP, Server 2008, Server 2003...).
Otra opción, esta ya más extendida y soportada por la mayoría de Sistemas  ( incluido Microsoft }:-)  ) es la autenticación en capa 2 manejada por el protocolo 802.1X basado en EAP  ( Protocolo de Autenticación Extensible RFC 2284 )que del mismo modo, provee la autenticación de un dispositivo en un switch (red cableada) o en un Punto de Acceso inalámbrico antes de permitirle mandar tráfico a la red. 

miércoles, 11 de mayo de 2011

Plan de implantación Ipv6 en España

El 29 de abril,el consejo de Ministros aprobó un Plan para el fomento de la implantación de Ipv6 a nivel nacional impulsado por el Ministerio de Industria, Turismo y Comercio. El Plan difundirá información didáctica sobre el nuevo protocolo de Internet, desarrollará acciones formativas y dinamizará en los agentes interesados los cambios tecnológicos que resulten necesarios para la incorporación efectiva de IPv6.

El Plan describe 10 puntos donde se definen las estrategias adoptadas para afrontar el paso a Ipv6 con apoyo de las administraciones públlicas, RedIris, jornadas de formación... Además se ha creado un portal web donde se ofrece seguimiento e información del Plan. Puede visitarse en http://www.ipv6.es/
Podremos encontrar mucha información útil tanto a nivel de usuario como de empresa así como un test para comprobar tu conectividad.

Aullidos binarios

martes, 10 de mayo de 2011

El protocolo del café

Hoy navegando por la ietf buscando estándares y borradores sobre dkim me llevé una sorpresa. El sueño me vencía y medio "groggy" pensaba en tomar un café para despejarme.... cuando entre líneas mientras avanzo páginas y páginas de búsquedas de RFCs me parece leer la palabra "coffee". Me detengo un momento y me digo.. puff si, necesito un café. Pero un momento.... CTRL+F.... buscar.. "coffe" ein?. RFC 2324... HTCPCP = Hiper Text Coffe Pot Control Protocol , si sí un RFC sobre un protocolo de hipertexto para controlar cafeteras!!!!


 Busco en la wiki y ahi está también !! .Alucinante, y esto está publicado desde 1998. Echad un vistazo por curiosidad al RFC, o a la entrada a la wiki. Implementa métodos GET, POST (BREW "infusionar café") , WHEN (para señalizar el vertido de leche)...e incluso mensajes de error no exentos de humor:
418: I'm a teapot (soy una  tetera)


Genial!!

miércoles, 4 de mayo de 2011

Esperando al hombre del medio con el ArpON en la mano

¿ Quién no ha sentido cierta inquietud cuando ha pensado en introducir sus contraseñas de acceso a alguna cuenta y estaba en una red no controlada?. Si, me refiero al miedo al  "hombre del medio" que hoy en día sirve para asustar más que "el hombre del saco".
En serio, a pesar de ser de los más antiguos y conocidos, el famoso ataque  "Man in the Middle" es uno de los más peligrosos para nuestra seguridad informática puesto que a pesar de su sencillez de concepto, su funcionamiento es impecable. Se basa en alterar nuestra tabla de resolución de direcciones MAC que se actualiza vía ARP de modo que a la víctima le hacemos creer que nosotros somos a quien debe mandar paquetes para enrutarlos, y por el otro sentido hacemos creer al gateway que nosotros somos la víctima. Es decir, hacemos de paso intermedio entre la víctima y el gateway, recogiendo y reenviado todo el tráfico entre ambos. De ahi, lo del hombre en el medio.

Hoy en Security by Default se publicaba un artículo comentando una herramienta para Linux llamada ArpON que actúa como un demonio y vigila nuestras interfaces de red para asegurar que no estamos siendo "spoofeados". El artículo lo escribe Alberto Ortega y podemos verlo en la página de SbD.

Merece la pena echarle un vistazo, y si eres usuario de Linux, tenerlo disponible entre tus "demonios".