tenga conectividad a internet durante Stage1 del proceso de Boot. Claramente, si nuestro sistema no tiene red, sera imposible realizar un proceso de descifrado remoto. En donde explico como tener internet en Stage1, también explico como habilitar un servidor SSH para estos propósitos. Nuevamente, esto es solo opcional y algo útil de tener habilitado en caso de encontrarnos con errores inesperados durante el Boot.
2- Estar dispuestos en usar
3- En caso de seguir la parte final de este articulo: "Implementación de una VPN para el proceso de desbloqueo remoto (opcional)", estar dispuestos a pagar por los servicios de
Por ultimo, hacer un recordatorio que lo expuesto en este articulo es focalizado en NixOS. Aunque no me cabe duda que puede servir de inspiración para realizar una implementación similar en otras distribuciones de Linux.
para resolver el protocolo HTTPS. Nuestra primera configuración sera añadir estos certificados al proceso de Boot.
Para esto, en nuestro archivo de configuración /etc/nixos/hardware-configuration.nix añadiremos unas declaraciones. Específicamente en la sección boot.initrd.systemd.contents. Esta delcaracion nos permite listar ficheros que deben ser considerados para ser "montados" en el se debe a que los .crt realmente son symlinks. Para que contents pueda copiar el contenido de los .crt correctamente debemos usar estos métodos auxiliares para leer el contenido, traspasarlos a un archivo temporal y luego copiar el contenido de dicho archivo a los que deberán estar disponibles durante el Boot.
Clave criptográfica RSA
Ahora debemos generar un par de . Es MUY importante que la calve RSA generada tenga una longitud de 4096bits. Para generar la clave privada podemos usar el comando:
openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:4096
Luego, para generar la parte publica, de dicha clave privada, podemos usar el comando:
openssl rsa -in private_key.pem -pubout -out public_key.pem
( aleatorio para crear la ID que usaremos para el canal. La longitud máxima de caracteres para la ID es de 64... así que recomiendo usar dicha cantidad. Recordemos guardar la ID que usaremos, ya que la vamos a necesitar en futuras configuraciones.
Como pueden ver... son bastantes cosas...
Como sea, el contenido de CustomDecrypt.sh lo pueden , los siguientes paquetes:
libuuid: Para el uso de lsblk y poder listar unidades de almacenamiento.
gnugrep: Para el uso de grep.
cryptsetup: Para poder manejar particiones que tengan LUKS.
openssl: Para crear y manipular claves RSA.
curl: Para comunicarnos con HTTPS con Ntfy.
iproute2: Para el uso del comando ip y validar algunas cosas relacionas a la red.
gnused: Para el uso de sed.
Para esto añadimos:
boot = {
...
initrd = {
...
systemd = {
...
initrdBin = [ pkgs.libuuid pkgs.gnugrep pkgs.cryptsetup pkgs.openssl pkgs.curl pkgs.iproute2 pkgs.gnused ];
};
};
};
Nota: Si tienen la necesidad de añadir mas paquetes, simplemente los listan en este arreglo.
Con todo esto estamos listos para crear una nueva generación de NixOS:
sudo nixos-rebuild switch
. Es algo un poco "burdo" y "aburrido"... pero mas que suficiente en términos de funcionalidad practica.
De antemano, me quiero disculpar con lo básico y poco profesional del Script Python. Se que se puede ser mejorado mucho, pero la verdad, es que no he puesto mucho esfuerzo en esta parte del proyecto. Lo importante, es que funciona.
El Script para funcionar necesita del paquete , los cules pueden instalar con pip install requests pycryptodome. También este Script necesita de dos configuraciones:
- En la variable
TOPIC, dejar la ID del canal de Ntfy que estemos usando.
- En la variable
PRIVATE_KEY_PATH el Path a la clave privada que hemos generado al inicio del guía.
Hora de probar todo:
Usaremos Python para ejecutar el Script. Mientras tengamos activo el Script de Python, vamos a reiniciar NixOS. Durante el proceso de Boot se enviara un mensaje de NixOS a Ntfy, el Script de Python va a reaccionar a dicho mensaje. Luego veremos que el Script de Python nos solicitará introducir la clave LUKS. Luego de digitarla y apretar enter, un nuevo mensaje sera enviado desde el Script de Python a Ntfy. CustomDecrypt.sh, que corre en NixOS, reaccionara a dicha respuesta y la analizará. Si todo va bien, luego de unos 10 a 15 segundos la unidad LUKS terminara de descifrarse y veremos como el proceso de Boot continuara y terminara de forma normal.
Y con eso ya estamos listos !
El Script de Python no necesariamente lo tenemos que tener previamente activo antes que NixOS se reinicie. Si deseamos, podemos primero reiniciar NixOS y luego podemos iniciar el Script de Python. El Script debería poder "recuperar" el ultimo mensaje enviado a Ntfy (el enviado por NixOS), para usarlo en el proceso de solicitar la calve LUKS.
Recordemos que el TimeoutStopSec de CustomDecrypt.sh es de 3700 segundos (un poquito mas de 1 hora), por tanto ese sera el plazo de tiempo que tenemos para digitar la clave LUKS desde el momento en que se reinicia NixOS.
Móvil Android como "dispositivo remoto"
Es fácil tener como "dispositivo remoto" nuestro celular Android. Solo debemos instalar la aplicación . Luego de instalarla pueden "subscribirse" al canal de comunicaciones usando su ID. De esta manera recibirán notificaciones en su celular cuando mensajes lleguen al canal. Esta es una buena manera de enterarse de forma oportuna si nuestro NixOS esta solicitando la clave LUKS. Luego podremos usar el Script de Python desde Pydroid 3 para digitar la clave LUKS, o acercarnos a nuestro computador de escritorio y usar el Script desde ahí.
En caso de iOS supongo que existe algo similar a Pydroid 3... pero la verdad no he probado.
Implementado un Watchdog en Stage1 del Boot
Hay un aspecto que aun debemos considerar en nuestra implementacion. Y es el uso de un Watchdog que se encargue de reiniciar el sistema operativo, de forma completa, en caso que dentro un periodo de tiempo determinado, no se desbloquee la unidad LUKS de forma exitosa. Esto lo hacemos por varias razones:
- Siempre esta la posibilidad que durante el Boot algo falle. Por ejemplo que, luego de un corte energético, la arquitectura de red aun no esta totalmente restablecida. O que existe alguna falla en el arranque de Stage1 relacionada al hardware. Un reinicio siempre es la mejor opción para "purgar" y cargar todo limpiamente.
- Nuestro CustomDecrypt.sh solo acepta claves LUKS durante 3700 segundos (
TimeoutStopSec) desde el momento que iniciar. Si ese tiempo ya ha transcurrido, no hay forma de reiniciar CustomDrcrypt.sh. Nuestro equipo quedara sin poder terminar el Boot. Reiniciar es la única opción.
- Esto también ayuda a que CustomDecrypt.sh genere nuevamente las claves RSA efímeras (de uso internas). Esto ayuda que los mensajes enviados por Ntfy siempre estén en un constante ciclo de "renovación criptográfica", haciendo que no exista tiempo suficiente para hacer ataques mas sofisticados. Mejor dicho, es buena practica permitir al sistema de CustomDecrypt.sh renovar sus claves efímeras de forma habitual... como por ejemplo cada 1 hora.
CustomDecrypt.sh solo acepta 1 vez una contraseña remota LUKS. Si esta es digitada de forma incorrecta, CustomDecrypt.sh no acepta reintentos. Y estos es apropósito. Es para evitar ataques de fuerza bruta desde el dispositivo remoto. Con el reinicio permitimos que CustomDecrypt.sh solicite nuevamente la clave, dandonos la opcion de tener "reintentos" de manera controlada y segura.
Para implementar nuestro Watchdog sera tan simple como agregar un nuevo servicio a nuestro hardware-configuration.nix. En la sección boot.initrd.systemd.services agregamos, junto a nuestro Script de CustomDecrypt, el nuevo servicio de CustomWatchdog:
services = {
...
CustomWatchdog = {
enable = true;
after = [ "timer.target" ];
requiredBy = [ "initrd.target" ];
unitConfig = {
Description = "CustomWatchdog";
DefaultDependencies = false;
};
serviceConfig = {
Type = "forking";
ExecStart="${pkgs.bash}/bin/sh -c 'sleep 3600 && reboot -f &'";
TimeoutStopSec = "3700s";
};
};
};
Lo mas importante en este servicio es el valor de 3600 segundos (1 hora) que tiene asignado el comando sleep (localizado en la instrucción de ejecución ExecStart). Este sera el tiempo que CustomWatchdog esperara antes de reiniciar el sistema operativo.
Nota 1: Usamos after y requiredBy para ejecutar CustomWatchdog lo antes posible en la cadena de procesos de Stage1 del Boot.
Nota 2: CustomWatchdog se ejecuta en modo forking, ya que estará constantemente en background esperando ejecutar el reinicio (en caso que el proceso de Boot no logre superar la etapa de LUKS correctamente).
Nota 3: Usamos reboot con la flag -f (force) para asegurarnos que el sistema se reinicie, a pesar de que otros procesos lo bloqueen.
Nota 4: El TimeoutStopSec es muy importante. Pueden notar que tiene un valor un poco mayor al usado en el sleep. Este TimeoutStopSec es esencial para que SystemD no "crea" que CustomWatchdog esta "pegado" y termine el proceso antes de tiempo. Esto puede suceder, porque en algunas ocasiones, SystemD no sabe interpretar correctamente los sleep prolongados y "cree" que el servicio esta fallando por alguna razón y que esta "pegado" sin hacer nada.
En caso que deseemos ajustar los tiempos, deberemos ser cuidadosos. El TimeoutStopSec de CustomDecrypt y de CustomWatchdog siempre deben tener un valor ligeramente mayor al usado en el sleep de CustomWatchdog. Esto es importante para no entrar en condiciones de carrera. Por tanto, si queremos por ejemplo, reiniciar nuestro equipo cada 6 horas, deberemos dejar en el sleep de CustomWatchdog con un valor de 21600 (segundos en 6 horas); y en TimeoutStopSecde CustomDecrypt como CustomWatchdog, un valor un poco mayor, por ejemplo "21700s".
Con esto listo, podemos crear una nueva generación de NixOS sudo nixos-rebuild switch y luego reiniciar nuestro sistema. Es un poco difícil "probar" si nuestro Watchdog funciona... ya que deberemos esperar 1 hora. Pero si quieren pueden reducir el valor de los TimeoutStopSec y sleep a algo como 10 minutos para hacer una prueba completa.
Conclusión, primera parte, sistema de desbloqueo remoto
Listo, ya tenemos nuestro sistema de desbloqueo remoto LUKS completo, usando Ntfy como intermediario para los mensajes. Yupi!
Ahora inicia la segunda parte, totalmente opcional, de este articulo. Y esto es la implementación de OpenVPN, con el proveedor AirVPN, durante el proceso de Boot. Esto nos ayudara a anonimizar el trafico de red entre NixOS y Ntfy. Posteriormente vamos a abordar algunos temas relacionados a como proveedor de VPN (de pago). Es mi servicio de VPN favorito (y por mucho). La política y respaldo que tiene la empresa de AirVPN es muy difícil de cuestionar. Y técnicamente son geniales. Si... soy un poco de "Fanboy". En un internet lleno de VPNs que son estafas y "trampas de tontos"... creadas específicamente para obtener dinero; AirVPN aparece como una opción "real" de lo que debe ser una VPN. Bueno, como sea. El punto es que usaré AirVPN, pero ustedes pueden usar cualquier proveedor que les permita usar OpenVPN como cliente (o sea, que el proveedor les de la posibilidad de genera un archivo .ovpn de conexión). Incluso pueden crear su propio servidor VPN usando algún servicio cloud u otro servidor que tengan disponible.
Creando el archivo .ovpn en AirVPN
Lo primero que haremos es crear nuestro .ovpn. Este es el archivo que tiene las credenciales para que el cliente OpenVPN pueda conectarse al servidor VPN.
Lo primero sera entrar a la web de AirVPN y crear un "Device" en el panel de "Client Area". Los Device permiten diferenciar distintos equipos que usen la misma cuenta de AirVPN. Por ejemplo, yo tengo un Device para mi celular, otro para mi notebook y ahora voy a crear uno para este proyecto. Yo le he puesto como nombre "NIX".
Con el Device ya creado, ahora vamos al panel de "Config Generator", que encontraran también en la Client Area.
En Config Generator vamos a activar la opción Advanced. Luego vamos a seleccionar el OS, o sea, Linux. Posteriormente el protocolo de conexión que usaremos. Yo generalmente uso "OpenVPN TCP 443". Y en la sección Advance vamos a marcar "Resolved hosts". Luego bajaremos y vamos a seleccionar el Device al cual vamos asignar este .ovpn, en mi caso "NIX". Finalmente vamos a seleccionar el servidor al cual nos conectaremos. Yo generalmente uso "Global". Al final de la pagina pueden darle a "Generate" para iniciar la descarga de su .ovpn.
Nota: La opción Resolved hosts nos sirve para que el .ovpn generado tenga definido el punto de acceso del servidor VPN con una dirección IP y no con un hostname. Esto lo necesitamos ya que durante Boot veremos que existen algunos problemas en la resolución de hostnames de manera consistente. Por tanto es mejor usar directamente la IP del servidor VPN.
Luego deberán copiar el .ovpn y dejarlo en /etc/nixos/ de su NixOS. Yo he usado como nombre para el archivo airvpn.ovpn.
Antes de continuar, no olvidemos que debemos disponibilizar dicho archivo para que este presente durante el Boot. Para esto en boot.initrd.secrets de nuestro hardware-configuration.nix añadimos:
secrets = {
...
"/etc/nixos/airvpn.ovpn" = "/etc/nixos/airvpn.ovpn";
};
Configurando OpenVPN
Ahora vamos a indicar al sistema que permita el uso del " al proceso de Boot, para que el sistema tenga la capacidad de crear adaptadores de red de
Aprovecho de mencionar que CustomDecrypt.sh en su interior tiene una rutina donde, si detecta que un servicio llamado "Openvpn" (ojo, con "O" mayúscula, igual que el nombre usado en boot.initrd.systemd.services.Openvpn) activo, procurara que el túnel esta activo antes de proseguir con la comunicación con Ntfy. Este es un resguardo para que no se genere comunicación https con el servidor antes que el VPN este listo. En caso que el servicio de Openvpn lo llamarán de forma distinta, pueden cambiar el nombre en la variable OPENVPN_SERVICE_NAME localizada al inicio de CustomDecrypt.sh.
Una feature que me gustaría añadir en un futuro es la capacidad de tener distintos .ovpn (apuntando a distintos servidores). Y si uno falla, OpenVPN pase a usar otro .ovpn.
Arreglando bug que provoca DNS leak
El talón de Aquiles de los VPN es cuando nuestro OS no resuelve los hostname (, donde el ISP puede analizar nuestro trafico usando la resolución de DNS. En este segmento nos aseguraremos que los DNS se usen de forma apropiada y no provoquen este problema que potencialmente des-anonimice nuestro trafico.
Generalmente cuando usamos una VPN, se usa un servidor DNS interno a dicha VPN para resolver hostname. Ese es el caso típico también con el servicio de AirVPN... ellos tienen servidores DNS que podemos usar una vez tengamos el túnel activo. Esta configuración de "selección de DNS" casi casi casi siempre es automática. Pero por alguna razón... en NixOS... específicamente en el sistema de red usado en Boot... no sucede.
Esto quiere decir, que aunque estemos conectados al VPN y tengamos el túnel activo, no siempre se usará el DNS de AirVPN. Resulta que si tenemos un DNS configurado a nivel interfaz física, este valor "sobrescribirá" al indicado por OpenVPN al configurar el túnel. Esto, en palabras simples, nos generará un catastrófico DNS leak.
Por suerte solucionarlo es sencillo. Deberemos ir a nuestro hardware-configuration.nix a la declaración boot.initrd.systemd.network y luego identificar la interfaz que usamos para conectarnos a internet. En mi caso es la llamada enp0s3.
Ahora, la forma de solucionar el problema depende de como se configura su interfaz:
- La interfaz es configurada de forma estática (sin DHCP):
En este caso deberían ver algo como:
enp0s3 = {
enable = true;
name = "enp0s3";
address = [ "192.168.4.152/24" ];
gateway = [ "192.168.4.1" ];
dns = [ "8.8.8.8" ];
};
La solución consiste en remover la definición de DNS. O sea, dejarlo así:
enp0s3 = {
enable = true;
name = "enp0s3";
address = [ "192.168.4.152/24" ];
gateway = [ "192.168.4.1" ];
};
- La interfaz es configurada usando DHCP:
En este caso deberían ver algo como:
enp0s3 = {
enable = true;
name = "enp0s3";
DHCP = "yes";
};
La solución consiste en añadir las siguientes declaraciones:
enp0s3 = {
enable = true;
name = "enp0s3";
DHCP = "yes";
dhcpV4Config = {
UseDNS = false;
};
dhcpV6Config = {
UseDNS = false;
};
};
Con esto le indicamos a DHCP que solo configure de forma automática el address y gateway de la interfaz y que no defina ningún DNS.
Independiente del modo en que resuelvan la configuración esto solucionara el echo que, una vez conectados al VPN, se use efectivamente el DNS del VPN.
Otros problemas que pueden causar DNS leak
Resulta que existe otro "problema", que puede surgir, dada la solución que implementamos en el paso anterior. El escenario de este "problema" es el siguiente:
- Nuestras interfaces no tienen asignado un DNS (ni manualmente ni por DHCP).
- Por alguna razón la conexión a la VPN falla de forma catastrófica.
- Por otra razón, totalmente anómala, nuestro sistema operativo intenta resolver un hostname.
¿Que pasará? Pues resulta que el servicio que se encarga de administrar la resolución de DNS del sistema operativo, llamado . El servidor DNS privado de AirVPN soporta DNSSEC, así que de esta manera nos aseguramos que las consultas sean realizadas de manera segura.
Nota: Me gustaría mencionar que CustomDecrypt.sh, en su interior, tiene una parte de código que se encarga de sobre escribir, automáticamente, el valor de fallbackDns en caso que OpenVPN se este usando. El valor de fallbackDns queda configurado con la misma IP que la gateway del túnel generado con AirVPN. Esta es la IP que AirVPN recomienda usar en caso de querer configurar manualmente el uso del DNS privado de ellos. El motivo de reescribir el valor de fallbackDns es simplemente para asegurarnos que resolved use correctamente el DNS. Es una prevención extra, a lo que ya es una serie de bugs y comportamientos particulares. Si no desean que CustomDecrypt.sh toque el fallbackDns pueden desactivar esta configuración pasando el valor de la variable FORCE_FALLBACK_DNS_VPN (localizada al inicio de CustomDecrypt.sh) a 0. Esto puede que sea necesario en caso que usen otro proveedor de VPN (donde la configuración manual para el uso del DNS privado sea distinta).
Conclusión
Y con esto ya tenemos un sistema que nos permite desbloquear de forma remota nuestra unidad LUKS, durante el Boot, de forma segura y anomia. Usando como intermediario Ntfy hemos logrado crear un sistema de notificaciones y mensajes asíncronos, así que podemos usar un celular como nuestro dispositivo remoto autorizado. Ademas, la implementación de seguridad interna que usa CustomDecrypt.sh para gestionar los mensajes, nos protegen de múltiples vectores de ataque, haciendo que el uso de canales públicos de comunicación no sea un problema.
No olviden, en su Stage1, desactivar el servidor SSH... ya no lo van a necesitar. También recomiendo ejecutar sudo nix-collect-garbage -d para limpiar el cache :)
Nuevamente los invito a seguir mejorando esta propuesta. Creo que una gran contribución seria hacer que el sistema funcione de forma modular, permitiendo cambiar que el canal de comunicación sea Discord, Slack, un sistema basado en intercambio de emails firmados o incluso un comunicación directa entre servidores.
En los próximos días subiré un articulo donde explicaré, detalladamente, la lógica detrás de las decisiones de seguridad que usa CustomDecrypt.sh. Puede ser una lectura interesante si te apasiona la seguridad.
Un saludo a todos!
SOCIAL SHARE CARD GENERATOR