Crear ruta IPv6 en MAC OS y revisar tabla de vecinos IPv6

Share

Tweet

Crear ruta:

  route add -inet6 -net 2000::/3 2001:XXX:XX:XX::1

Revisar tabla de vecinos IPv6:

  ndp -an

Concepto: ¿Qué es un plan de direccionamiento IP(v4|v6)?

Share

Tweet

"Se define como el modo, las acciones, el modelo sistemático para llevar a cabo las asignaciones de direcciones IP (IPv4 y/o IPv6) en una red"

P.D. Concepto realizado por mí persona mezclando diversas definiciones de la palabra "plan" y haciendo enfoque  al mundo IP

IPv4 e IPv6 en una sola VPN utilizando OpenVPN

Share

Tweet

Introducción
  Recientemente conversando con un amigo (@TarantinDigital) me indicaba que le gustaría tener una VPN que soportara IPv4 e IPv6, que le parece una solución muy interesante para IoT.
  Igualmente entre otras cosas ofrece la comodidad de tener direccionamiento IPv6 persistente (siempre el mismo bloque IPv6)

Importante
  No voy a indicar los pasos para instalar o configurar OpenVPN.
  Asumo tienes un servidor OpenVPN corriendo y en el servidor tienes direccionamiento IPv4 e IPv6
  Nos enfocaremos en algunas entonaciones en el servidor y en el archivo server.conf
  Este excelente video (en Ingles) ofrece paso a paso como instalar y configurar OpenVPN: https://www.youtube.com/watch?v=XcsQdtsCS1U

Pasos para agregar IPv6 a un servidor OpenVPN que actualmente ofrece solo IPv4 

  1) Tu interfaz tun (o TAP) tiene que tener direccionamiento IPv6, OpenVPN tiene algunas restricciones en cuando a la longitud de prefijo (*máscara*) que puede utilizar en IPv6, para este ejemplo estaré utilizando un /64

  ifconfig tun0 add 2001:db8::1/64

  2) Es necesario (para nuestro ejemplo, si utilizas un /64 global de IPv4 o direccionamiento IPv4 público no sería necesario) realizar NAT44 y NAT66:

  NAT44

  iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to xx.xx.xx.xx

  NAT66

  ip6tables -t nat -A POSTROUTING -o eth0 -s 2001:db8::/32 -j MASQUERADE #noten que en eth0 hay un IPv6 global

  3) Hay que agregar algunas directivas de IPv6 en el archivo /etc/openvpn/server.conf. Las mismas son las siguientes:

  proto udp6 #hará que el server maneje sockets v4 y v6

  server-ipv6 2001:db8::1/64  #dirección IP colocada a la interfaz tun en el server openvpn

  tun-ipv6 #tipo de interfaz tunnel con IPv6 

  push tun-ipv6   #se le pide al cliente crear interfaces tun para el tunel (la VPN)

  ifconfig-ipv6 2001:db8::1 2001:db8::2

  push "route-ipv6 2000::/3" #inyecta esta ruta en el cliente

  4) Finalmente es necesario convertir el servidor VPN en un router IPv6. Para ellos editamos el archivo /etc/sysctl.conf y la linea net.ipv6.conf.all.forwarding=1 le quitamos el #

Del lado del cliente veras una interfaz similar a:

utun1: flags=8051 mtu 1500

inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff 

inet6 fe80::aebc:32ff:fe96:822b%utun1 prefixlen 64 scopeid 0xd 

inet6 2001:db8::1001 prefixlen 64 

Note que recibió una dirección IPv6 del mismo /64 de la interfaz tun del servidor.

Espero sea de tu utilidad


Referencias
  https://www.youtube.com/watch?v=XcsQdtsCS1U
  http://blog.acostasite.com/2014/07/nat66-en-linux.html

Identificando servidores DNS IPv6 Open Resolvers

Share

Tweet

Introducción

Como muchos de ustedes saben, tener servidores DNS Open Resolvers es muy negativo, tanto para el que deja el servicio abierto como para la seguridad en Internet en general.
Este tipo de servidores se utilizan como vector de ataques de DDoS por amplificación ya que a partir de un mensaje de consulta de pequeño tamaño, se puede obtener una respuesta mucho mayor. De esta manera, ese servidor DNS se convierte en un amplificador de tráfico muy potente ya que sus consultas amplificadas pueden dirigirse a una IP específica, la cual recibiría todo ese volumen de tráfico, ocasionándole indisponibilidad de sus servicios. Para este ataque ni siquiera es necesario que el hardware esté controlado por el atacante.

Este es un problema que en WARP nos preocupa porque hemos recibido mucho reportes de incidentes relacionados a esta vulnerabilidad. Por esta razón en conjunto con el área de I+D estamos llevando a cabo un proyecto con el objetivo de conocer el estado actual de la región, identificar los open resolvers y de forma proactiva alertar y recomendar una posible corrección de la configuración de este servicio.

Identificando un DNS Open Resolvers en IPv6 (DNS abiertos)

Identificar servidores Open Resolvers o servidores DNS abiertos en el mundo de IPv4 es muy sencillo, debido a la poca longitud del espacio de IPv4 (2**32).
En el mundo de IPv6 es imposible poder verificar cada una de las direcciones IP y ejecutar una prueba de Open Resolver. Dicha prueba puede durar miles de años.

¿Cómo se identifica un DNS Open Resolver?

Un servidor DNS recursivo solo debería responder consultas (queries) a todos los clientes que se encuentren dentro de su misma red y debería rechazar cualquier otra que provenga de fuera. Por ejemplo, los servidores DNS del ISP ACME solo deberían responder a consultas de sus propios clientes, a más nadie.
La identificación se hace realizando una consulta de un nombre de dominio a los servidores DNS. En caso que el servidor DNS responde con una respuesta válida, entonces es considerado Open Resolver. Si por el contrario, devuelve un rechazo (Query refused) o sencillamente hace timed out se encuentra bien configurado, por lo que no es un Open Resolver.

¿Cómo se consiguen los resolvers de IPv6?

LACNIC administra un servidor que puede ser llamado: Root Server Reverso, específicamente la letra “D”, es decir, d.ip6-servers.arpa. Gran cantidad de consultas a direcciones IP reversas de la región de LACNIC pasan a través de este servidor, en líneas generales este servidor SOLO recibe consultas de servidores DNS. Aquí es donde obtienen las direcciones IPv6 de los DNS que realizan consultas.

Procedimiento & Algoritmo

1. 1. En el servidor actualmente se realiza una captura de 2.5 millones de paquetes con el filtro del puerto 53 y destinados únicamente a la dirección IP de dicho equipo.
   2. De la captura anterior se ubican solo direcciones IPv6 origen (se eliminan paquetes mal formados, errores, etc). Se desprecia menos de 1% de los paquetes
   3. De las direcciones IPv6 obtenidas en el paso 2 se crea una lista de direcciones IPs unicast (es decir, se eliminan duplicados)
   4. Un script toma cada dirección IPv6 del listado del punto 3, y realiza una consulta a la dirección www.lacnic.net hacia esa dirección, verifica recursividad y el estado de la respuesta.
   5. En caso de ser un Open Resolver dicha dirección IP quedará registrada para su posterior análisis y notificación a la organización responsable de ese recurso.

Diagrama de bloques

Vista de los Resultados

Conclusiones Primarias

Para esta primera instancia, observamos aproximadamente unos 33,514 registros de consultas realizadas al Root Server Reverso “D” administrado por LACNIC.

Luego de analizar estos primeros datos obtenidos, observamos que la región más afectada por servidores open resolver sería la de APNIC con el 19.23% de los datos obtenidos para esa zona. Para la región de Ripe obtuvimos la mayor cantidad de información, curiosamente el porcentaje de servidores mal configurados es casi insignificante (0.93%).
En lo que respecta a nuestra región detectamos 39 open resolvers (4.56%) de los 817 registros recolectados, donde existen solo 3 casos que la dirección IP se repite más de una vez.

Estudios similares

https://labs.ripe.net/Members/luuk_hendriks/finding-open-dns-resolvers-on-ipv6

Referencias

Para leer sobre Open Resolvers se recomienda este link: https://www.certsi.es/blog/dns

Realizado por:

Dario Gomez & Alejandro Acosta

Propuesta de una fuente confiable de enrutamiento para la región de LAC

Share

Tweet

Introducción

Recientemente fue publicado un artículo por Job Snijders llamado: “A New Source For Authoritative Routing Data”, su traducción viene a ser algo como: “Una nueva fuente de información de enrutamiento autoritativa”. (Snijders 2017)

El documento trata sobre un trabajo donde explica como varios expertos y en contribución con varias instituciones construyeron una manera de proveer a la comunidad información confiable sobre enrutamiento. Para ir entrando en detalles técnicos podemos verlo como algo entre un IRR (“Internet Routing Registry - Wikipedia” n.d.) y RPKI (“Resource Public Key Infrastructure - Wikipedia” n.d.)

En este documento se describe una propuesta de LACNIC a la comunidad, con el fin de proveer una fuente de información autoritativa confiable sobre enrutamiento que pueda utilizarse por parte de los operadores de Internet de la región.

Un poco de historia

En el post de Job Snijder se explica cómo se tomó como fuente de información confiable la base de datos de Whois de ARIN y especificamente un campo llamado Origin el cual especifica cual AS (Sistema Autónomo) es quien anunciará determinado prefijo.

Posteriormente lo que se hace con esa información es construir un archivo JSON (“JSON - Wikipedia, La Enciclopedia Libre” n.d.) el cual puede ser utilizado fácilmente por programadores y diferente software de forma muy similar a lo que hace un IRR actualmente.

¿Qué hicimos en Lacnic?

Luego de analizar el post anterior y nuestras opciones, concluimos que el campo OriginAS prácticamente no es utilizado en el WHOIS de LACNIC, por lo que no estaríamos en condiciones de extraer esa información a partir de esa fuente. Sin embargo, dado el gran porcentaje de ROAs creados en varios países de la región (“Statistics — RIPE Network Coordination Centre” n.d.), creemos conveniente utilizar RPKI como fuente de información.

¿Cómo se tomó la información de RPKI?

Para utilizar la informacion de RPKI de LACNIC trabajamos con el validador RPKI de RIPE (“Tools and Resources” n.d.), con la diferencia que removimos todos los TAL (Trust Anchor Locator) exceptuando el de LACNIC. De esta manera el validador unicamente estaría procesando los ROAs correspondientes a nuestra región. Finalmente lo que hicimos fue exportar los ROAs en formato JSON, una funcionalidad que ofrece el propio validador.

Proceso de la información de RPKI

Finalmente, utilizando un script en python3 y en base al JSON exportado del Validador de RIPE construimos un nuevo archivo de JSON, (“Tools and Resources” n.d., “Website” n.d.) con una similitud sintáctica de 95% al del proyecto previo (“Website” n.d.)(Job Snijders y compañía). En este sentido, la manera como se crea la fecha, las posiciones relativas en el archivo, los nombres de las llaves son identicos, de esta manera facilitamos la interoperatividad con scripts y software ya existente.

Adicionalmente, esta misma información se publica en format RPSL(“Routing Policy Specification Language - Wikipedia, La Enciclopedia Libre” n.d.), un formato que es más habitual para los operadores. De esta forma, se puede elegir entre ambos formatos para procesar o utilizar la información autoritativa.

Avances actuales

En base a todo lo mencionado anteriormente actualmente:

• Se publica diariamente un dump de todos los ROAs en formato JSON
• Se publica en RPSL la información correspondiente al AS de Origen y el prefijo (tanto v4 como v6) Lo anterior viene acompañado de un un hash de comprobación bajo SHA384 URL http://stats.labs.lacnic.net/RPKI/RPKItoJSON/

Espacio para mejoras

Sabemos que existen muchas cosas para mejorar, por el momento debemos mencionar:

1. Publicar los archivos en un server con soporte de https

Conclusiones

Dentro de Lacnic este proyecto aun se encuentra en una etapa Alfa, a lo sumo Beta. Dependeremos 100% de los comentarios recibidos de la comunidad si deseamos llevar esta idea a un ambiente con carácter de producción. Por ello no dude en comunicarse con nosotros, somos muy buenos recibiendo quejas, comentarios y felicitaciones.

Consideraciones adicionales

En los ROAs es posible especificar una longitud máxima y mínima de prefijos a publicar, sin embargo esto no tendría una forma similar de replicarlo en el archivo de salida. Una posibilidad en IPv4 sería generar los prefijos intermedios con el mismo sistema autónomo de origen, pero en IPv6 esto no sería posible por la cantidad de direcciones involucradas. Otra posibilidad es no utilizar las longitudes mínima y máxima en los ROAs, ya que esa es la situación análoga a los IRRs. El formato JSON de salida es fácilmente convertible a RPSL, con lo cual se pueden utilizar las mismas herramientas que se utilizan para procesar la información de un IRR. Un punto a analizar es si resulta necesario poder contar con otros objetos que no están incluidos en esta base de datos auto-generada.

Por:

• Alejandro Acosta alejandro \at lacnic dot net
• Guillermo Cicileo guillermo \at lacnic dot net

https://twitter.com/lacniclabs

Referencias

1. “Internet Routing Registry - Wikipedia.” n.d. Accessed January 19, 2018. https://en.wikipedia.org/wiki/Internet_Routing_Registry.
2. “JSON - Wikipedia, La Enciclopedia Libre.” n.d. Accessed January 19, 2018. https://es.wikipedia.org/wiki/JSON.
3. “Resource Public Key Infrastructure - Wikipedia.” n.d. Accessed January 19, 2018. https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure.
4. “Routing Policy Specification Language - Wikipedia, La Enciclopedia Libre.” n.d. Accessed January 19, 2018. https://es.wikipedia.org/wiki/Routing_Policy_Specification_Language.
5. Snijders, Job. 2017. “A New Source For Authoritative Routing Data: ARIN WHOIS.” Medium. Medium. December 19, 2017. https://medium.com/@jobsnijders/a-new-source-for-authoritative-routing-data-arin-whois-5ea6e1f774ed.
6. “Statistics — RIPE Network Coordination Centre.” n.d. Accessed January 19, 2018. https://lirportal.ripe.net/certification/content/static/statistics/world-roas.html.
7. “Tools and Resources.” n.d. RIPE Network Coordination Centre. Accessed January 19, 2018. https://www.ripe.net/manage-ips-and-asns/resource-management/certification/tools-and-resources.
8. “Website.” n.d. Accessed January 19, 2018a. http://stats.labs.lacnic.net/RPKI/RPKItoJSON/.

Comprobado: Santa Claus SI tiene IPv6

Share

Tweet

Buenas noches,

 El día de hoy me he dado cuenta que Santa (Papa Noel) SI tiene IPv6, más específicamente tiene Doble Pila (IPv4 & IPv6). Lo anterior lo digo porque indiscutiblemente Santa le llega a casi todo el mundo, sobre todo a los que tienen Internet.

 Lo anterior lo digo porque no me cabe la menor duda de la ventaja de IPv6 para Santa, es la mejor forma de contactar a sus colegas en los países industrializados [1] donde absolutamente todos tienen cierto hasta bastante grado de penetración de IPv6, comenzando por Alemania con 33%, USA con 32%, Brasil, India y Francia con 21%, 23% y 22% respectivamente. Imaginense a Santa intentando comunicarse con esos países para pedir millones de regalos usando IPv4, sencillamente sería imposible.  Bien por estos países que se pusieron las pilas y obtuvieron un super cliente.

 Ahh, también quería contarles que me he dado cuenta lo difícil que es “perseguir virtualmente” a Santa, todos sabemos que vive en el Polo Norte, sin embargo gracias al uso de IPv6, la vasta cantidad de direcciones, el uso de direcciones IP de privacidad, no al uso de EUI-64 en las globales, quizás hasta un horroroso NAT66 me ha hecho imposible seguirlo cómodamente. Por cierto, he intentado de todo, publicidad, spam, cookies, cross site scripting, objetos embebidos y nada, definitivamente IPv6 si aumenta la privacidad. Bien por Santa !!

 Luego estuve pensando sobre los renos, el trineo y el tiempo de llevar las cosas alrededor del mundo.., creo que el concepto de Santa para movilizarse a través de los agujeros espacio - temporales [2] son propensos a fallas en IPv4.., con IPv6 y un NAT66 Stateless 1-1 (NPT) si funcionaría la cosa.

 Para los que no crean los agujeros espacio - temporales y apoyen más la teoría de de las nubes de relatividad [2] una vez más IPv6 es la respuesta…, para muestra un botón, todas las nubes hoy en día están en v6.

 Y finalmente, si no creen en ninguna de las dos anteriores, son los que apoyan la física cuántica [nuevamente 2], la explicación -mi favorita- es más sencilla aún: Santa debe tener una red de Elfos [3 ] anycasteados en todo el mundo lo que facilita su vida y puede entregar los regalos desde allí a las casas más cercanas, esta red seguro es Dual Stack, no podemos olvidarnos de los niños que tienen IPv4 por culpa que su ISP no le pone voluntad para poner IPv6. Pobres niños.

  En base a todo lo anterior, el despliegue de IPv6 es una muy buena noticia para Santa y más aún para los niños!!!.

Un fuerte abrazo y feliz navidad para todos.

Alejandro Acosta
@ITandNetworking
@LACNICLabs

[1]  http://www.actividadeseconomicas.org/2012/06/top-10-de-los-paises-mas.html

[2] http://www.bbc.com/mundo/noticias/2014/12/141220_navidad_papa_noel_entrega_regalos_jp

[3] https://www.papanoelenlaponia.com/los-elfos-de-santa-2

BGP: Filtrar por tamaño de la red en BGP, he ahí el dilema

Share

Tweet

Introducción

 El equipo de I+D del área técnica y WARP redactaron en conjunto el presente artículo basado en algunos incidentes gestionados por el centro de respuestas de LACNIC.

 En el mundo de BGP existen decenas de maneras para filtrar prefijos. El objetivo del presente post mostrar una serie de recomendaciones para tener una red más estable, no perder conectividad con ciertos destino y reducir el número de quejas en nuestro NOC.

Situación identificada

  Muchos ISPs no pueden recibir la full routing table de BGP (para el dia de hoy consta de ~610.000 prefijos IPv4) en sus enrutadores.

  Lo anterior puede deberse a diversas razones:

• El enrutador no posee suficiente RAM para aprender todos los prefijos (además recordar que es posible que el router tenga varias sesiones BGP)
• Por ahorro de CPU
• Porque el upstream provider a su vez no entrega toda la tabla de enrutamiento
• Por simplicidad y sencillez

 Entendiendo la situación e independientemente de la razón que sea, el enrutador no aprende toda la tabla de enrutamiento.

Problema

  No aprender toda la tabla de enrutamiento puede traer algunos inconvenientes parciales pero que al final trae problemas de conectividad, quejas de los usuarios, inconvenientes de acceso a ciertos sitios, entre otros.

¿Por qué?

  Imaginemos la siguiente situación:

1. Tengo un router (propiedad de EXAMPLE) en Internet que solo aprende la tabla parcial de enrutamiento
2. El router propiedad de EXAMPLE quedó configurado solo para aprender redes “más grandes” que /21. Es decir, aprende redes /20, /19, /18, etc.  (evidentemente estamos hablando de IPv4)
3. Debido a la configuración establecida en el punto “b”, el router no aprenderá prefijos de tamaño /21, /22, /23 ni /24
4. Mientras tanto en otra parte del mundo, le acaban de secuestrar su red /21 a la empresa ACME (planteamos el caso como un secuestro pero podría ser una mala configuración)
5. ACME decide realizar anuncios más específicos de su red original /21, es decir, anuncia 8 redes /24
6. Por causa de los filtros configurados por EXAMPLE, nunca verá dichos anuncios /24 de ACME
7. EXAMPLE seguirá aprendiendo la red /21 del secuestrador de la red. Lo que puede ocasionar que el tráfico hacia ACME puede ser potencialmente secuestrado (repito, se entiende que esta situación es potencial, no necesariamente el tráfico irá hacia el atacante)

Diagrama:

  El siguiente diagrama representa la hipótesis planteada en el punto anterior de manera gráfica para facilitar su comprensión.

Recomendación

 Realizaremos la siguiente recomendación en base a algunas experiencias vividas, teniendo en cuenta que solo aplican al caso de cuando no se pueda aprender/recibir la tabla completa de BGP:

1. No filtrar permitiendo redes menos específicas. Es conveniente aprender redes más chicas, es decir: /24, /23, /22.
2. Filtrar por AS_PATH de profundidad.
3. Crear los ROAs respectivos a los prefijos (RPKI).

Algunos ejemplos (Cisco like)

1)  Solo queremos aprender redes entre /22 y /24 (hay otras maneras de hacer esto):

router bgp 65002

neighbor 10.0.0.1 remote-as 65001

neighbor 10.0.0.1 route-map FILTRO-IN in

!

ip prefix-list REDESCHICAS seq 5 permit 0.0.0.0/0 ge 22 le 24

!

route-map FILTRO-IN permit 10

match ip address prefix-list REDESCHICAS

!

2) Solo queremos aprender dos AS de profundidad (hay otras maneras de hacer esto):

router bgp 65001

neighbor 10.0.0.2 remote-as 65002

neighbor 10.0.0.2 route-map ASFILTER-IN in

!

ip as-path access-list 5 permit ^[0-9]+_$

ip as-path access-list 5 permit ^[0-9]+ [0-9]+_$

!

route-map ASFILTER-IN permit 10

match as-path 5

!

Mas información

• Demostración de secuestro de prefijo  1/2: https://www.youtube.com/watch?v=X5RNSs8y8Ao&t=39s
• Demostración de secuestro de prefijo 2/2: https://www.youtube.com/watch?v=m51WtuEZOKI
• BGP Prefix-Based Outbound Route Filtering
  http://www.cisco.com/c/en/us/td/docs/ios/12_2s/feature/guide/fsbgporf.html
• Ejemplo de configuración de BGP con dos prestadores de servicio diferentes (conexiones múltiples)
  http://www.cisco.com/cisco/web/support/LA/7/75/75930_27.html
• Certificación de Recursos (RPKI)
  http://www.lacnic.net/web/lacnic/certificacion-de-recursos-rpki
• Información General sobre Certificación de Recursos (RPKI)
  http://www.lacnic.net/web/lacnic/informacion-general-rpki

Autores

- Dario Gomez

- Alejandro Acosta (@ITandNetworking)

Ejemplo: Linux y Network Prefix Translation (NPT)

Share

Tweet

Introducción:

En este post voy a intentar explicar brevemente que es NPT, por qué es útil y finalmente dejaré un pequeño ejemplo que espero sea de utilidad.

¿Qué es NPT?

NPT por sus siglas en Inglés significa Network Prefix Translation, algunos lo podrás comparar con NAT en IPv6.., y bueno,., es medianamente cierto. Siendo la palabra “medianamente” perfectamente utilizada en la oración previa.

En NPT básicamente lo que se busca es traducir la dirección origen en un datagrama IPv6, pero particularmente la sección del prefijo de red (NET ID) dejando la parte del IID (Host ID) sin modificación.

¿Por qué hacer NPT?

Existen varias razones. Voy a mencionar solo dos.

1. Estoy en una red con dos proveedores de Internet (no tengo IPs propias ni ASN), pero necesito alguna redundancia para salir a Internet. El equipo de borde en vez de realizar un NAT con sobre de carga de puertos a una sola dirección IP (con todos los problemas y limitantes que esto ocasiona) solo modifica los primeros bits del la dirección (digamos, los primeros 64 bits solo como manera de ejemplo).
2. Si necesitar hacer “renumbering” de tu red pero tienes IPs del tipo ULA (u otra propia quizas) tu vida será mucho más sencillo al solo tener que modificar el traductor NPT y no hacer re-enumeración de toda la red.

Diagrama ejemplo

Configurando un equipo Linux para hacer NPT:

Los pasos para configurar NPTv6 (o NPT) en Linux son muy sencillos. Debes hacerlo tanto de paquetes salientes como de paquetes entrantes.

#From internal network to external Network

ip6tables -t nat -A POSTROUTING -d 2000::/3 -s 2001:db8:AAAA:AAAA::/64 -j NETMAP

--to 2001:db8:CCCC:CCCC::/64;

#From external network to internal network

ip6tables -t nat -A PREROUTING -s 2000::/3 -d 2001:db8:CCCC:CCCC::/64 -j NETMAP

--to 2001:db8:AAAA:AAAA::/64;

Mas info:

https://dn42.net/howto/IPv6

http://www.howfunky.com/2012/02/ipv6-to-ipv6-network-prefix-translation.html

Y por supuesto el RFC mismo:

https://tools.ietf.org/html/rfc6296