Blog Archives

NIC Ecuador y la importancia de la infraestructura DNS

Hace dos años escribí en este blog un post sobre NIC Venezuela, y las dificultades operativas que estaba atravesando en momentos de cambio de la estructura burocrática que la opera. Hoy, una falla en los servidores raíz del ccTLD .ve ocasionó una caída del servicio DNS y por consiguiente, que por alrededor de tres horas la vasta mayoría de personas dentro y fuera de Venezuela no pudieran acceder a los 217 mil dominios venezolanos, con el consiguiente impacto político y económico.

Así que quedó claro, de una forma un poco dolorosa, la fragilidad que tienen las infraestructuras DNS de algunos ccTLD, y el impacto que tiene DNS en la operación de un país. Ahora bien, ¿es posible extrapolar la situación de NIC Venezuela a la del NIC del Ecuador? Considerando que la motivación de mi post entonces fue, principalmente, entender cómo podríamos superar a la burocratización de esa entidad, que es pública, cuando en Ecuador el nic.ec es operado por una empresa privada, parecería que no hay mucho que extrapolar. Pero hagamos el ejercicio.

¿Qué pasa cuando usted escribe http://www.<algo>.ec?

Este nombre debe ser traducido a una dirección IPv4 o IPv6. Una dirección IPv4, por ejemplo, puede verse como 154.65.43.2, y una IPv6 como 2801:0:60::1. Pero esto es irrelevante para el usuario pues la conversión se hace detrás de las cámaras. Además, los resultados de estas conversiones se guardan en una memoria temporal (caché de DNS) ya sea en su máquina, en su router Wi-Fi o inclusive en los servidores de su ISP. De hecho, normalmente su ISP es el responsable de hacer esta conversión, pero cuando la dirección que usted solicita termina en .ec, incluso su ISP deberá consultar a NIC Ecuador para poder darle una respuesta.

El ccTLD ecuatoriano (.ec) es servido por cuatro servidores DNS. Dos de ellos, n1.nic.ec y n2.nic.ec, están asignados al mismo sistema autónomo, y presumiblemente, están en el mismo sitio físico (muy probablemente, en un centro de datos en las oficinas de NIC Ecuador, en el Edificio La Previsora del Malecón en Guayaquil) lo cual como mencioné en mi artículo de NIC Venezuela, puede ser un problema por razones de seguridad física y resiliencia ante desastres. Claro que, lo mismo ocurre con los DNS de algunos ISP, pero estos no son autoritativos para la zona .ec.

Por supuesto, n1 y n2 no son los únicos. Los otros dos servidores están fuera de Ecuador. El primero es operado por ISC, una organización inteacional, y el segundo es una adición reciente, n3.dns.ec, que no me queda muy claro quien lo está operando, pero está en la Costa Oeste de los Estados Unidos. Dos servidores, n2.nic.ec y n3.dns.ec, también responden por IPv6. Esto nos da una ventaja adicional en caso de problemas con IPv4 o de un escenario solo-IPv6, pero aun es marginal.

Replicación en el exterior y sistema de registro

Cuando se maneja un esquema así, la aplicación de registro (el sistema de NIC Ecuador) que se encarga de interactuar con los usuarios que son dueños de un dominio .ec, y escribir los resultados de sus solicitudes a los servidores, también debe replicar estos nuevos cambios a los servidores alteos.

Es de esperar que la aplicación de registro escriba primero en n1.nic.ec y n2.nic.ec, ya que están muy probablemente en sus oficinas, pero debe escribirse también a los servidores alteos. Como observación preliminar, hay momentos en que n1 y n2 responden con un serial de zona más actualizado que los otros dos. Quizás que la replicación no es inmediata.

Esto podría significar que, de existir algún problema en Guayaquil, los alteos tendrían información vieja, y se podrían perder las actualizaciones, o que se presente un escenario como el de la replicación de la zona corrupta que ocurrió en el .ve, al menos para roughly la mitad de los clientes DNS.

Update: hay momentos del día en que hay sincronización, y ventanas en que no siempre ocurre. Hice algunas observaciones más y conseguí que el tema es consistente con los dos servidores exteos en algunas horas del día. Aquí hice otras en el cambio del serial del 29 al 30 de mayo, aun más interesantesEsto es relativamente normal en operaciones de ccTLD, con ciclos de 15 minutos, aunque en estas observaciones hay ciclos mayores. Pero podría ser un problema del lado de los operadores de esos servidores exteos, y además, ¿podrían reducirse esos tiempos?

Conclusiones

No tengo ninguna razón para pensar que en NIC Ecuador puedan presentarse problemas como el que ocasionó la caída de hoy en Venezuela, pero tampoco tengo evidencia para pensar lo contrario, así que pensemos en ese escenario en el que la zona quede vacía, se replique a los alteos, eventualmente a los servidores de los ISP, y todas las consultas a dominios terminados en .ec no devuelvan respuesta lo que dejaría por ejemplo al .gob.ec fuera de operación hasta que se resuelva el problema. El impacto sería muy alto, y, sobre todo con el advenimiento de IPv6 (del cual ya existe regulación al respecto emanada del MINTEL) se vuelve total y absolutamente imprescindible.

Tratando de aprender de los dos mundos, de las cosas que se han hecho bien en los NIC de ambos países, podría sugerir que se promueva la instalación de réplicas en universidades, y en los centros de datos de los ISPs a través de la AEPROVI. Ecuador opera un NAP exitosamente, pero podría tomarse la idea de los grandes proveedores como Google o Microsoft que facilitan servidores preinstalados y preconfigurados con valor agregado para los operadores. Por ejemplo, una imagen de un sistema operativo Linux que opere un servidor DNS, un servidor NTP, un relay Teredo, un exit point de Tor… no sé, algo que ofrezca valor agregado. Si se firma un convenio para tener a alguien pendiente 24/7, y luego de un período de prueba y monitorización, ese servidor DNS podría entrar como una réplica. En este escenario “altamente distribuido”, la operación se volvería más compleja, sí, pero aumenta la resiliencia del modelo.

(Por cierto, tener un NAP en Venezuela no hubiera necesariamente impedido que se presentara el problema de hoy.)

Y, por supuesto, operar un par de servidores DNS adicionales afuera de Ecuador también representaría una gran ventaja. Técnicamente, no sería operar pues en algunos casos los convenios solo permiten que se haga la copia y no operarlos per se, pero los beneficios son importantes.

Pero aquí otra idea: ¿por qué NIC Venezuela no hospeda una copia de NIC Ecuador y NIC Ecuador una copia de NIC Venezuela
? Conozco a los administradores de sistema de ambos NIC, y tienen una buena comunicación, ¡podría ser una buena idea!

Creo que el aprendizaje es importante. DNS se encuentra en la capa más fundamental de la infraestructura de Inteet, y en medio de un escenario de crecimiento en el acceso a Inteet, especialmente de banda ancha, y de mayor acceso a servicios de gobieo electrónico, una falla en el servicio DNS en Ecuador o en cualquier otro ccTLD resultaría en pérdidas económicas y de confianza en el sistema. Y aunque suene a exageración nerd, no tenemos una infraestructura DNS infalible.

Mis más cordiales saludos a todos los que se dedican a mantener estas infraestructuras fundacionales de Inteet funcionando, en Venezuela, en Ecuador y en donde sea. Funcionamos gracias a ustedes.

Crowdsourced CSIRT en LACSEC

Hoy presenté el concepto del CCSIRT en el marco de LACSEC 2012. En el enlace está la presentación, el código, el paper y las bases conceptuales, y obviamente el sistema que ya está funcionando.

Al final de la presentación, la SUPERTEL me entrevistó para saber más sobre crowdsourcing y la importancia de los CERTs/CSIRTs en la región y colgaron el video en YouTube.

Quiero agradecer a Feando Gont, chair de LACSEC, y al Comité de Evaluación de Trabajos de LACSEC por haber aceptado la presentación y al público por su fenomenal participación, estoy muy honrado de haber podido participar en este evento como ponente en mi primera asistencia.

Consideraciones para implementar IPv6 en Linux

Fui invitado por Amanda Mafla y la gente del FLISOL en Ibarra (Ecuador) para participar en un evento en la Universidad Técnica del Norte en el que realicé una presentación introductoria sobre IPv6.

Es la segunda vez que participo en un evento de la UTN, y nunca han fallado en la convocatoria, muy por encima de las cien personas, en esta oportunidad para compartir sobre IPv6. Así que gracias de nuevo a las autoridades y los organizadores por la invitación.

Lo primero que quiero aclarar es que el estilo de la presentación está a medio camino entre Lessig y Matz. Por eso las láminas podrían no mostrar información de manera estructurada o como referencia y les invito a que revisen los enlaces complementarios si necesitan más información.

Esta presentación es la primera en una serie de actividades que tengo preparadas sobre IPv6 durante el año, y la realizo el día antes de que se inicie la reunión anual de LACNIC en Quito.

DNSCrypt en… ¿Windows?

A estas alturas quizás ya conozcasDNSCrypt, la respuestaeducada de OpenDNS al problema de DNS spoofing que surge en escenariosde MITM. Sin embargo, puede que estés utilizando alguna plataformaarcana, como… Windows, y quieras usar DNSCrypt, ¿se podrá hacer?

Definitivamente. De hecho, para lograr el punto, escribo esto desdeWindows 7, usando DNSCrypt (específicamente dnscrypt-proxy) y loúnico que necesito es Cygwin y obviamenteuna conexión a Inteet.

Una vez instalado Cygwin, llamas a bash (el script aparece en el menúcomo Cygwin Bash Shell) y descargas el código delgithub deDNSCrypt; yo usé el último tar.bz2. Puedes usar wget para bajar elcódigo y luego tar cjf para descomprimirlo. Adentro es solo cuestiónde:

./configure make && make install

Y algunos minutos después tengo dnscrypt-proxy instalado enusr/local/sbin, por lo que solo queda llamar a DNSCrypt, que vienepreconfigurado para usar OpenDNS, de la siguiente forma:

/usr/local/sbin/dnscrypt-proxy —daemonize

Ahora puedes configurar la resolución de nombres DNS contralocalhost, por ejemplo con netsh (sí, Windows tiene línea decomandos)

netsh interface ip set dns static 127.0.0.1

Y solo queda un problema por resolver y es el inicio del servicio alarranque, o de otra forma no podrás resolver nombres por DNS cuandoreinicies, esto es trivial creando un servicio, por ejemplo:

sc create dnscrypt binPath=

E iniciar dnscrypt con sc o por PowerShell.

Básicamente, DNSCrypt cifrará las consultas entre tu equipo y OpenDNS,eliminando el vector de ataque para el DNS spoofing, y circunveniendoasí censuras a nivel de DNS que implementan algunos ISPs. Sin embargo,cualquier tráfico no cifrado con aplicaciones en una red bajo MITM,específicamente ARP spoofing o suplantación del router continúa sujetoa los problemas de privacidad que ya he citado en artículosanteriores y de igual forma cualquiercensura en base a IP (blackholes, por ejemplo) continuaráfuncionando a menos que se usen proxies o redes como Tor.

Farewell, VirtualBox

Hace unas semanas dejé de usar definitivamente VirtualBox y pasé a utilizar KVM. Para aquellos que, como yo, empezaron a usar QEMU back in the days y se recuerdan todavía de kqemu probablemente les haya ocurrido que, cuando VirtualBox tomó vuelo, se convirtió en un estándar de facto para sus proyectos de virtualización.

¿Por qué? QEMU no era particularmente útil, y el performance era en realidad frustrante, y Xen no resolvía la situación, con una configuración sinceramente críptica. Sí, estable, enterprise-grade (3 años después y sin tocar el SLA todavía está funcionando un cluster de Zimbra Collaboration Suite, Open Source Edition para 25K cuentas con alta disponibilidad y conexión a NAS que instalé en la industria petrolera) pero se sentía como un acto de fe.

Así que muchos empezamos a utilizar VirtualBox y a consumir muchas de sus funcionalidades que lo hacían competitivo ante escenarios complejos de virtualización, sobre todo en aplicaciones de escritorio, tipo VMWare, o App-V/RDS de Microsoft. Entre estas funciones estaba el soporte para USB y VRDP. VBoxHeadless y mucho scripting salvaban la patria. Para mi, usar imágenes base (discos diferenciados) y snapshots era muy útil, y eventualmente las opciones de networking mejoraron mucho en VirtualBox. Una herramienta suficiente.

Sin embargo, el problema de ser un fanboy es que te pierdes como gira el mundo a tu alrededor. Hay muchos ejemplos. En este caso, libvirt se convirtió en realidad, y Red Hat (entre algunos otros mecenas) pusieron énfasis en GUIs y toolkits para virtualización, incluyendo específicamente a KVM como un motor de virtualización integrado al núcleo.

Manos a la obra. Instalé libvirt-bin, virt-manager y, por supuesto, qemu-kvm. Estoy en el keel 2.6.39-1-686-pae de Debian Unstable. Si vas a administrar con un usuario sin privilegios, éste debe estar en el grupo libvirt. Hay un servicio llamado libvirt-bin que debes activar y que en principio vela porque los módulos del keel estén cargados y, lo más importante, que el networking virtual esté configurado.

Quizás ésta sea una de las patas flojas de libvirt, el networking. En principio no hay tantas opciones como en VirtualBox para hacer networking arbitrario, pero si sabes manejar Netfilter (iptables) y puentes, puedes hacer lo que te dé la gana (es decir, no hay una opción explícita en virt-manager para configurar una interfaz como puente de una física, solo como un NAT o enrutando) Además, si usas dnsmasq, puede que tengas problemas de compatibilidad con los dnsmasq que utiliza libvirt para configurar la red.

Dicho esto, como tenía solo 8 máquinas virtuales en mi laptop, no investigué sobre “migradores automáticos” de la configuración de VirtualBox a KVM/libvirt. Solo migré los discos virtuales. Para esto usé kvm-img, migrando de VDI a QCOW2, como desventaja, para los discos diferenciados tuve que hacer un paso previo de “exportar” el disco con VBoxManage usando el ID del disco en VirtualBox, y luego convertirlo a QCOW2. De hecho, en este setup no tengo discos diferenciados, lo cual me incomoda pero no me he dedicado a revisar si hay alteativas.

Así mismo, donde necesité configurar dispositivos USB, lo hice por la interfaz de virt-manager. No tuve ningún problema para presentar un dispositivo del host a las máquinas virtuales. Y, para mi sorpresa (porque en qemu nunca hubo, y recuerdo el revuelo cuando Novell se la desarrolló al SuSe Studio) el acceso por VNC es una funcionalidad excepcionalmente útil, de hecho virt-manager usa esta función para presentar la pantalla en la interfaz gráfica. Excelente.

Finalmente, creo que libvirt fue una excelente opción porque me permite escalar. De hecho, en algunos de los servers que tengo en la red de la casa usé libvirt también. Solo hice ssh, e instalé los paquetes. Y solo con eso, y con tener replicados los discos (puede ser vía SAN/NAS) puedo migrar una máquina virtual de mi laptop al server y dejarla ejecutando allí de forma transparente. Awesome.

¿Performance? Muy bueno. En mis casos de uso, es casi imperceptible la diferencia con VirtualBox. Las ventajas para la administración, y sobre todo la falta de drama en las actualizaciones, valen la pena. ¡Dale libvirt!

Follow

Get every new post delivered to your Inbox.

Join 1,800 other followers