HBoot: vigila el arranque de tu máquina con una “huella” de los primeros bloques del disco

HBoot es un script sencillo (de rootedcon/HBoot) que lee los primeros bloques del disco y calcula una firma (hash). En cada arranque compara esa huella con la que guardaste como “buena”. Si detecta cambios, dispara una alerta: podría haber manipulación del boot (MBR/GRUB, primeros sectores, etc.).

No sustituye a Secure Boot, TPM, ni a una cadena de confianza completa, pero es un canario práctico para equipos donde quieres una señal temprana y de baja fricción. Ideal para red teams, puestos críticos, laboratorios, quioscos o entornos donde “más vale prevenir”.


¿Qué problema resuelve?

Un atacante con acceso físico (o de bajo nivel) puede inyectar código en los primeros sectores del disco (MBR/partición EFI/GRUB) y persistir antes de que el sistema operativo suba. HBoot se limita a fotografiar ese arranque (los N primeros bloques) y te avisa si la foto no coincide con la original.

Filosofía: “somos paranoicos con el boot hijacking; ¿cómo detectarlo de la forma más simple posible?”


Cómo funciona (en 1 minuto)

  1. Elige el dispositivo que contiene el arranque (ej.: /dev/sda, /dev/nvme0n1).
  2. Lee N bloques de tamaño fijo (por defecto, sector_size=1024, sector_count=10).
  3. Calcula un hash (por defecto sha512).
  4. Guarda/consulta la firma sentinela en SENTINEL_SIGNATURE_FILE (por defecto /etc/sentinel.sig).
  5. Si cambia → SENTINEL-KO (código de salida -1). Si coincide → SENTINEL-OK (código 0).

Luego tú decides la acción: pintar el fondo de rojo, mostrar un popup, cortar red, apagar, enviar un webhook a tu SIEM, etc.


Variables clave (configuración)

VariableEjemploDescripción
boot_device/dev/sdaDisco del que leer los primeros bloques (en NVMe: /dev/nvme0n1)
sector_size1024Tamaño del bloque a leer (en bytes). 512/1024/4096 según hardware
sector_count10Número de bloques a leer. 10×1024 = 10 KiB (ajusta según tu esquema)
SENTINEL_SIGNATURE_FILE/etc/sentinel.sigDónde se guarda la firma “buena”
ALGORITHMsha512Algoritmo de hash (asegúrate de que tu OpenSSL/hashlib lo soporta)

Sugerencia práctica: en sistemas UEFI/GPT quizá te interese leer más que 10 KiB (p. ej., 2 MiB: sector_size=4096, sector_count=512) para abarcar gaps y áreas donde algunos “bootkits” plantan persistencia. Valídalo con tu particionado.


Instalación y primer “sellado”

  1. Clona o descarga el script de GitHub y colócalo en /usr/local/sbin/hboot (por ejemplo).
  2. Ponlo ejecutable: sudo install -m 0755 hboot /usr/local/sbin/hboot
  3. Edita las variables al inicio del script (boot_device, sector_size, …).
  4. Genera la firma de referencia (desde un estado limpio/verificado): sudo /usr/local/sbin/hboot --init # o ejecuta el script con modo “sellar” # Verás SENTINEL-OK y se creará /etc/sentinel.sig
  5. Comprueba que detecta cambios (prueba controlada): # Simula un cambio: toca temporalmente el fichero de firma sudo mv /etc/sentinel.sig /etc/sentinel.sig.bak sudo /usr/local/sbin/hboot; echo $? # Debe mostrar SENTINEL-KO y código -1 sudo mv /etc/sentinel.sig.bak /etc/sentinel.sig

Importante: cualquier actualización de GRUB, firmware o cambios de partición legítimos pueden modificar los primeros bloques. En ese caso deberás re-sellar (regenerar) la firma una vez verificado el cambio.


Integración al arranque

Opción rápida: rc.local (sistemas SysV o compatibles)

Añade al final de /etc/rc.local:

/usr/local/sbin/hboot || /usr/local/sbin/hboot-alert
exit 0
Lenguaje del código: JavaScript (javascript)

Donde hboot-alert podría contener, por ejemplo:

#!/bin/sh
# Fondo rojo en GNOME
gsettings set org.gnome.desktop.background picture-uri 'file:///usr/share/backgrounds/red.jpg'
# Popup de alerta
zenity --error --text="ALERTA: firma de arranque modificada. Revise el equipo."
# Opcional: cortar red
# nmcli networking off
# Registrar evento
logger -p auth.alert "HBoot: SENTINEL-KO en $(hostname)"
Lenguaje del código: PHP (php)

Opción moderna: systemd (recomendada)

Crea /etc/systemd/system/hboot.service:

[Unit]
Description=HBoot boot integrity check
DefaultDependencies=no
After=local-fs.target
Before=multi-user.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/hboot
ExecStartPost=/bin/sh -c '[ "$$?" -eq 0 ] || /usr/local/sbin/hboot-alert'
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
Lenguaje del código: JavaScript (javascript)

Activa:

sudo systemctl daemon-reload
sudo systemctl enable --now hboot.service
Lenguaje del código: CSS (css)

¿Y si uso UEFI + partición EFI?

En UEFI, el código de arranque principal reside en la partición EFI (FAT32), normalmente montada en /boot/efi. Los primeros bloques del disco pueden no cambiar si el ataque se centra en la ESP. Tres opciones:

  1. Leer más bloques al principio del disco (1–2 MiB) para cubrir el gap inicial y bootloader gaps.
  2. Firmar también la ESP: calcula hash de ficheros EFI críticos (/boot/efi/EFI/*/*.efi) y guarda un fichero .sig aparte.
  3. Firmar el MBR + GPT header y, en paralelo, hash de /boot y /boot/efi con una lista blanca.

HBoot es minimalista por diseño; si necesitas cobertura UEFI profunda, complementa con integridad de ficheros (AIDE, IMA) o TPM PCR.


Limitaciones y buenas prácticas

  • No es una cadena de confianza: HBoot detecta cambios, no los previene. No sustituye Secure Boot, measured boot ni BitLocker/LUKS con TPM.
  • Falsos positivos: actualizaciones de GRUB/firmware/particionado legítimas modificarán la huella. Establece procedimiento de re-sellado tras mantenimiento.
  • Qué disco firmo: en servidores con RAID/NVMe múltiple, firma el disco real de arranque y documenta el mapeo (lsblk, efibootmgr, grub-install -v).
  • Logs y SIEM: registra el resultado (logger) y, si procede, envía un webhook a tu sistema de alertas (Slack, Teams, syslog remoto).
  • Cifrado de disco: con LUKS, la cabecera suele estar al inicio de la partición cifrada, no necesariamente en el LBA 0. Decide si quieres firmar disco o partición.

Alternativa “a mano” (sin script)

Para comprender lo que hace HBoot, aquí tienes el equivalente con utilidades básicas:

# Lee 2 MiB (4096 bytes * 512 bloques) desde /dev/sda y calcula SHA-512
sudo dd if=/dev/sda bs=4096 count=512 status=none | sha512sum > /etc/sentinel.sig

# Comprobar en otro arranque
sudo dd if=/dev/sda bs=4096 count=512 status=none | sha512sum | diff -q - /etc/sentinel.sig \
  && echo "SENTINEL-OK" || echo "SENTINEL-KO"
Lenguaje del código: PHP (php)

Flujo de respuesta recomendado (cuando salta SENTINEL-KO)

  1. Aísla el equipo (red fuera).
  2. No reinicies sin capturar evidencia: imagen de primeros MiB (dd), copia de /boot y /boot/efi.
  3. Compara contra firmas anteriores y verifica cambios planificados (parches, kernel, GRUB).
  4. Si no hay explicación legítima, forense: arranque en live, clonado y análisis.
  5. Reinstala/recupera el cargador (GRUB/EFI) desde medio confiable; re-sella la firma cuando valides integridad.

FAQ

¿Basta con 10 bloques × 1 KiB?
Depende. Para MBR clásico podría valer; en UEFI/GPT es recomendable ampliar (1–2 MiB) o hash de ficheros EFI.

¿Puedo usar otro hash (SHA-256/Blake2)?
Sí, si tu openssl/hashlib lo soporta. Ajusta ALGORITHM y verifica disponibilidad (openssl dgst -help, python -c 'import hashlib;print(hashlib.algorithms_available)').

¿Y si tengo discos NVMe?
Usa /dev/nvme0n1 (no particiones, p. ej. /dev/nvme0n1p1) si tu objetivo es el disco completo. Documenta el mapeo.

¿Genera falsos negativos?
Si el atacante no toca los bloques firmados (p. ej., persiste solo en la ESP), HBoot puede no detectarlo. De ahí la recomendación de ampliar cobertura o combinar con integridad de ficheros/TPM.


Conclusión

HBoot es una pieza pequeña, comprensible y útil para añadir visibilidad al momento más crítico del sistema: el arranque. No pretende ser un “silver bullet”, pero sí un sensor de bajo coste que puedes integrar en minutos y que, llegado el caso, te dirá a gritos: “algo cambió donde no debía”. Para quien se toma en serio la seguridad del boot, es un “” inmediato.

Suscríbete al boletín SysAdmin

Este es tu recurso para las últimas noticias y consejos sobre administración de sistemas, Linux, Windows, cloud computing, seguridad de la nube, etc. Lo enviamos 2 días a la semana.

¡Apúntate a nuestro newsletter!


– patrocinadores –

Noticias destacadas

– patrocinadores –

¡SUSCRÍBETE AL BOLETÍN
DE LOS SYSADMINS!

Scroll al inicio
×