Blog en espanol destinado a diferentes temas tecnicos principalmente en IT y Networking. Se desea cubrir Linux, DNS, DNSSEC, RPKI, BGP, Cisco, Programacion (Bash, Python, etc), Protocolos de Enrutamiento, Seguridad en Redes, VoIP.
En esta oportunidad quiero hablar sobre un detalle que considero pasó en el mundo de Internet desapercibido, tanto así que yo mismo ni me dí cuenta tarde.
Un poco de historia
Recientemente estuve revisando unas presentaciones de hace pocos años (aprox 2015) y noté que en las mismas mencionaban que solo 11 de los 13 root servers tenían direccionamiento IPv6. Por ello quise chequear y para mi sorpresa hoy -Mayo 2018- los 13 Root Servers cuentan con direccionamiento IPv6.
Los últimos nuevos glues IPv6 fueron modificados de la siguiente manera y en la siguiente fecha: 20 octubre 2016: g.root-servers.net . AAAA 2001:500:12::d0d 25 agosto 2016: e.root-servers.net . AAAA 2001:500:a8::e
¿Cómo algo tan importante pudo pasar desapercibido?
Desde nuestro punto de vista fue increíble que este hecho no tuviese más difusión, pero las cosas fueron así y no podemos hacer nada al respecto. Se nos ocurren algunas razones por qué hubo esa falta de difusión:
IPv6 ya se encuentra tan avanzado y estable que no pasó a ser noticia. Por ejemplo, en el 2008 cuando se colocó la primera dirección IPv6 si existió mucha noticia por muchas listas de correo y otros medios.
Algunas noticias pasan sin pena ni gloria sobretodo cuando no hay pena como en esta oportunidad (que viene a ser bueno !!)
Una comparación que suena exagerada pero cala perfectamente en este contexto es cuando llegó el Apollo 11 a la luna en el año 1969, fue una gran noticia, en los posteriores proyectos Apollo ya la misma novedad no tenía mucho impacto.
¿Qué significa que ahora todos los Root Servers DNS cuenten con IPv6?
Para este renglón existen dos cosas que podemos mencionar que son muy significativas, 1) es un mensaje adicional a la comunidad que IPv6 es un protocolo estable y funcional 2) podemos esperar resoluciones más rápidas y con menores rata de falla.
Un punto adicional, es importante indicar que la ausencia de NAT en IPv6 dentro del mundo DNS tiene particular y mayor relevancia motivado a que los traductores no necesitan Natear las respuestas DNS.
Por último, esto también empuja a crear demanda por IPv6 en todo el mundo. No olvidemos que los root servers utilizan anycast desde hace muchos años, y cada uno de los más de 1.000 nodos tienen requerimiento de servicio IPv6 en las decenas de países y redes en que son hosteados.
El siguiente paso entonces es... ir apagando IPv4 en alguno de los root servers! ;)
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:
ip6tables -t nat -A POSTROUTING -o eth0-s2001: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:
Introducción:
Tengo estos errores en syslog luego de intentar levantar openvpn:
May 7 12:59:47 server ovpn-server[764]: library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08
May 7 12:59:47 server ovpn-server[764]: daemon() failed or unsupported: Resource temporarily unavailable (errno=11)
May 7 12:59:47 server ovpn-server[764]: Exiting due to fatal error
Solución:
En el archivo:
/lib/systemd/system/openvpn@.service
Ubicar la linea: LimitNPROC=10
y comentarla, quedaría así: #LimitNPROC=10
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
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.
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
De las direcciones IPv6 obtenidas en el paso 2 se crea una lista de direcciones IPs unicast (es decir, se eliminan duplicados)
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.
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.
Intro:
Al ejecutar GNS3 y quererme conectar por consola a los equipos recibo el error: "-bash: telnet: command not found". Muy probablemente luego de querer de hacer upgrade a MAC OS Sierra.
Solución:
Hay que instalar telnet, recomiendo los siguientes pasos:
