Blog Archives

Rebasing CoreOS for ephemeral cloud storage

The convenience and economy of cloud storage is indisputable, but cloud storage also presents an I/O performance challenge. For example, applications that rely too heavily on filesystem semantics and/or shared storage generally need to be rearchitected or at least have their performance reassessed when deployed in public cloud platforms.

Some of the most resilient cloud-based architectures out there minimize disk persistence across most of the solution components and try to consume either tightly engineered managed services (for databases, for examples) or persist in a very specific part of the application. This reality is more evident in container-based architectures, despite many methods to cooperate with the host operating system to provide cross-host volume functionality (i.e., volumes)

Like other public cloud vendors, Azure presents an ephemeral disk to all virtual machines. This device is generally /dev/sdb1 in Linux systems, and is mounted either by the Azure Linux agent or cloud-init in /mnt or /mnt/resource. This is an SSD device local to the rack where the VM is running so it is very convenient to use this device for any application that requires non-permanent persistence with higher IOPS. Users of MySQL, PostgreSQL and other servers regularly use this method for, say, batch jobs.

Today, you can roll out Docker containers in Azure via Ubuntu VMs (the azure-cli and walinuxagent components will set it up for you) or via CoreOS. But a seasoned Ubuntu sysadmin will find that simply moving or symlinking /var/lib/docker to /mnt/resource in a CoreOS instance and restarting Docker won’t cut it to run the containers in a higher IOPS disk. This article is designed to help you do that by explaining a few key concepts that are different in CoreOS.

First of all, in CoreOS stable Docker runs containers on btrfs. /dev/sdb1 is normally formatted with ext4, so you’ll need to unmount it (sudo umount /mnt/resource) and reformat it with btrfs (sudo mkfs.btrfs /dev/sdb1). You could also change Docker’s behaviour so it uses ext4, but it requires more systemd intervention.

Once this disk is formatted with btrfs, you need to tell CoreOS it should use it as /var/lib/docker. You accomplish this by creating a unit that runs before docker.service. This unit can be passed as custom data to the azure-cli agent or, if you have SSH access to your CoreOS instance, by dropping /etc/systemd/system/var-lib-docker.mount (file name needs to match the mountpoint) with the following:

[Unit]
Description=Mount ephemeral to /var/lib/docker
Before=docker.service
[Mount]
What=/dev/sdb1
Where=/var/lib/docker
Type=btrfs

After systemd reloads the unit (for example, by issuing a sudo systemctl daemon-reload) the next time you start Docker, this unit should be called and /dev/sdb1 should be mounted in /var/lib/docker. Try it with sudo systemctl start docker. You can also start var-lib-docker.mount independently. Remember, there’s no service in CoreOS and /etc is largely irrelevant thanks to systemd. If you wanted to use ext4, you’d also have to replace the Docker service unit with your own.

This is a simple way to rebase your entire CoreOS Docker service to an ephemeral mount without using volumes nor changing how prebaked containers write to disk (CoreOS describes something similar for EBS) Just extrapolate this to, say, your striped LVM, RAID 0 or RAID10 for higher IOPS and persistence across reboots. And, while not meant for benchmarking, here’s the difference between the out-of-the-box /var/lib/docker vs. the ephemeral-based one:

# In OS disk

--- . ( ) ioping statistics ---
20 requests completed in 19.4 s, 88 iops, 353.0 KiB/s
min/avg/max/mdev = 550 us / 11.3 ms / 36.4 ms / 8.8 ms

# In ephemeral disk

--- . ( ) ioping statistics ---
15 requests completed in 14.5 s, 1.6 k iops, 6.4 MiB/s
min/avg/max/mdev = 532 us / 614 us / 682 us / 38 us

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.

Follow

Get every new post delivered to your Inbox.

Join 2,116 other followers