Hardening del sistema operativo: LUKS, radios, cold boot, fingerprinting y swap cifrada

2.2.1 Desactivación de radios: WiFi, Bluetooth, NFC (kill switches físicos)

Todo radio activo en tu dispositivo es una superficie de ataque y una fuente de metadatos de localización. WiFi escanea puntos de acceso aunque no estés conectado, Bluetooth anuncia un identificador único, NFC puede ser leído a centímetros de distancia sin que lo notes. Desactivarlos cuando no los necesitas no es paranoia — es reducir la superficie de exposición al mínimo necesario.

rfkill: control de radios por software en Linux

rfkill es la interfaz del kernel de Linux para gestionar dispositivos de radiofrecuencia. Puede bloquearlos a nivel de software (soft block) o responder al interruptor físico del hardware (hard block). La diferencia es importante: un soft block puede deshacerse por software; un hard block requiere acción física.

bash — gestionar radios con rfkill

# Ver el estado de todas las radios
rfkill list
# 0: phy0: Wireless LAN
#         Soft blocked: no
#         Hard blocked: no
# 1: hci0: Bluetooth
#         Soft blocked: no
#         Hard blocked: no

# Desactivar WiFi
sudo rfkill block wifi

# Desactivar Bluetooth
sudo rfkill block bluetooth

# Desactivar NFC
sudo rfkill block nfc

# Desactivar TODAS las radios de golpe
sudo rfkill block all

# Reactivar una radio específica
sudo rfkill unblock wifi

# Verificar que el bloqueo se aplicó
rfkill list
# Soft blocked: yes  → bloqueado por software

Desactivación persistente al arranque

bash — bloquear radios en el arranque con systemd

# Opción 1: blacklist de módulos del kernel (la más efectiva)
# Impide que el módulo se cargue — la radio no existe para el SO
cat > /etc/modprobe.d/disable-radios.conf << 'EOF'
# Deshabilitar WiFi
blacklist iwlwifi
blacklist ath9k
blacklist rtl8xxxu

# Deshabilitar Bluetooth
blacklist btusb
blacklist bluetooth

# Deshabilitar NFC
blacklist nfc
blacklist pn533
EOF

# Actualizar initramfs para que el cambio se aplique en el arranque
sudo update-initramfs -u

# Opción 2: servicio systemd que bloquea al arrancar
# Menos agresivo que el blacklist — los módulos cargan pero las radios quedan bloqueadas
cat > /etc/systemd/system/rfkill-block.service << 'EOF'
[Unit]
Description=Bloquear todas las radios al arrancar
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/rfkill block all
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl enable rfkill-block.service
sudo systemctl start rfkill-block.service

⚠️

El soft block no es suficiente contra malware con root: Un proceso con privilegios de root puede hacer rfkill unblock all y reactivar las radios. Si el modelo de amenaza incluye malware con root en tu equipo, el soft block es insuficiente. La única contramedida real es el kill switch físico — cortar la alimentación del hardware de la radio, ya sea mediante el interruptor físico del portátil o mediante modificación del hardware.

Kill switches físicos y modificaciones de hardware

Algunos portátiles tienen kill switches físicos para WiFi y Bluetooth (los ThinkPads de la serie X son famosos por esto). En los que no los tienen, hay dos opciones:

Desconexión física de la antena: abrir el portátil y desconectar el cable de antena del módulo WiFi/Bluetooth. Sin antena, la radio no puede transmitir ni recibir aunque el módulo esté activo. Reversible.
Extracción del módulo: quitar completamente la tarjeta WiFi/BT del slot M.2 o Mini-PCIe. La solución más limpia si no necesitas WiFi en ese equipo.
Portátiles con kill switches notorios: ThinkPad X200/X230 (con coreboot), Librem de Purism, System76 — tienen interruptores físicos que cortan la alimentación de las radios, inmunes a software.

2.2.2 Cifrado completo de disco: LUKS, FileVault, BitLocker sin TPM y con deniability

El cifrado completo de disco convierte todos los datos en texto cifrado ilegible sin la clave correcta. Sin él, cualquier persona con acceso físico al disco puede leer todos tus archivos independientemente de la contraseña del SO — simplemente monta el disco en otro equipo. Con cifrado bien implementado, el disco es basura sin la passphrase.

LUKS en Linux: instalación desde cero

bash — cifrar un disco con LUKS2

# Instalar cryptsetup
sudo apt install -y cryptsetup

# Cifrar un disco o partición completa (LUKS2, cifrado AES-256-XTS)
# ADVERTENCIA: esto destruye todos los datos en /dev/sdb
sudo cryptsetup luksFormat --type luks2 \
    --cipher aes-xts-plain64 \
    --key-size 512 \
    --hash sha512 \
    --iter-time 5000 \
    /dev/sdb
# Pedirá confirmación y la passphrase dos veces

# Abrir el volumen cifrado (crear el mapper)
sudo cryptsetup luksOpen /dev/sdb disco_cifrado
# El volumen descifrado queda disponible en /dev/mapper/disco_cifrado

# Crear sistema de archivos sobre el volumen descifrado
sudo mkfs.ext4 /dev/mapper/disco_cifrado

# Montar y usar normalmente
sudo mkdir /mnt/cifrado
sudo mount /dev/mapper/disco_cifrado /mnt/cifrado

# Al terminar: desmontar y cerrar el volumen
sudo umount /mnt/cifrado
sudo cryptsetup luksClose disco_cifrado

# Ver información del volumen LUKS
sudo cryptsetup luksDump /dev/sdb

Gestión de key slots: múltiples passphrases

bash — gestionar key slots de LUKS

# Añadir una passphrase adicional (key slot 1)
# Útil para tener una clave de emergencia o de recuperación
sudo cryptsetup luksAddKey /dev/sdb

# Ver los key slots activos
sudo cryptsetup luksDump /dev/sdb | grep "Key Slot"

# Eliminar una passphrase (por número de slot)
sudo cryptsetup luksKillSlot /dev/sdb 1

# Hacer backup del header LUKS (imprescindible — sin header los datos son irrecuperables)
sudo cryptsetup luksHeaderBackup /dev/sdb \
    --header-backup-file luks_header_backup.bin
# Guarda este backup en un lugar DIFERENTE al disco cifrado

# Restaurar header desde backup
sudo cryptsetup luksHeaderRestore /dev/sdb \
    --header-backup-file luks_header_backup.bin

Plausible deniability: header separado y VeraCrypt

La deniability plausible permite negar la existencia de datos cifrados. Hay dos aproximaciones principales:

LUKS con header separado: por defecto el header LUKS está al principio del volumen — su presencia revela que el disco está cifrado. Si mueves el header a un dispositivo separado (otro USB, por ejemplo), el disco parece datos aleatorios sin ninguna estructura reconocible:

bash — LUKS con header en dispositivo separado

# Cifrar el disco con el header en un archivo externo
sudo cryptsetup luksFormat \
    --header /ruta/segura/header.img \
    /dev/sdb

# Abrir el volumen especificando el header externo
sudo cryptsetup luksOpen \
    --header /ruta/segura/header.img \
    /dev/sdb disco_cifrado

# Sin el header, /dev/sdb parece completamente aleatorio
# No hay ninguna firma LUKS que confirme que es un volumen cifrado
# El disco puede destruirse o perderse sin revelar la existencia del cifrado

VeraCrypt con volúmenes ocultos: VeraCrypt permite crear un volumen externo con una passphrase y un volumen oculto dentro del espacio libre del externo con otra passphrase distinta. Si te obligan a revelar la clave, das la del volumen externo — que contiene datos inocuos. Los datos reales en el volumen oculto son indetectables.

bash — crear volumen oculto con VeraCrypt

# Instalar VeraCrypt (descargar desde veracrypt.fr y verificar firma GPG)
sudo dpkg -i veracrypt-*.deb

# Crear un volumen con volumen oculto por línea de comandos
# Paso 1: crear el volumen externo (con datos señuelo)
veracrypt --text --create /ruta/volumen.vc \
    --size 500M \
    --volume-type normal \
    --encryption AES \
    --hash SHA-512 \
    --filesystem FAT \
    --password "clave_señuelo"

# Paso 2: crear el volumen oculto dentro del anterior
veracrypt --text --create /ruta/volumen.vc \
    --size 300M \
    --volume-type hidden \
    --encryption AES \
    --hash SHA-512 \
    --filesystem FAT \
    --password "clave_real_secreta"

# Montar el volumen oculto (usando la clave real)
veracrypt --text /ruta/volumen.vc /mnt/vc \
    --password "clave_real_secreta"

# Desmontar
veracrypt --text -d /mnt/vc

FileVault y BitLocker

Sistema	Plataforma	Consideraciones OPSEC
FileVault 2	macOS	La clave de recuperación puede subirse a iCloud — desactivar esta opción. La clave se deriva de tu contraseña de usuario, que Apple podría verse forzada a resetear bajo presión legal.
BitLocker sin TPM	Windows	Por defecto requiere TPM que guarda la clave automáticamente. Para mayor seguridad: Directiva de grupo → Requerir PIN de arranque adicional. Sin PIN, si el portátil arranca hasta la pantalla de login el disco ya está descifrado.
BitLocker + TPM + PIN	Windows	La combinación TPM + PIN es la configuración correcta: el TPM aporta protección contra ataques offline y el PIN protege contra acceso físico con el equipo apagado.

2.2.3 Encrypted /boot y Secure Boot personalizado

Cuando cifras el disco con LUKS pero dejas /boot sin cifrar, hay una superficie de ataque que la mayoría ignora: el evil maid attack. Si alguien tiene acceso físico a tu equipo mientras está apagado, puede modificar el kernel o el initramfs en /boot para capturar tu passphrase cuando la escribas al arrancar. Cifrar /boot y personalizar Secure Boot cierra este vector.

Cifrar /boot con GRUB y LUKS

Desde GRUB 2.06, es posible tener /boot completamente dentro del volumen LUKS. GRUB pedirá la passphrase antes de leer el kernel, eliminando el vector del evil maid attack.

bash — configurar /boot cifrado en Debian/Ubuntu

# Este proceso debe hacerse durante la instalación del sistema
# o desde un live USB con el sistema sin montar

# La estructura de particiones recomendada:
# /dev/sda1 → EFI System Partition (ESP), sin cifrar (~512 MB, FAT32)
# /dev/sda2 → Volumen LUKS con /boot, / y swap dentro

# 1. Cifrar la partición principal
sudo cryptsetup luksFormat --type luks2 /dev/sda2
sudo cryptsetup luksOpen /dev/sda2 sistema

# 2. Crear LVM encima del volumen cifrado
sudo pvcreate /dev/mapper/sistema
sudo vgcreate vg0 /dev/mapper/sistema
sudo lvcreate -L 1G -n boot vg0
sudo lvcreate -L 4G -n swap vg0
sudo lvcreate -l 100%FREE -n root vg0

# 3. Formatear los volúmenes lógicos
sudo mkfs.ext4 /dev/vg0/boot
sudo mkswap /dev/vg0/swap
sudo mkfs.ext4 /dev/vg0/root

# 4. Configurar GRUB para descifrar LUKS antes de arrancar
# En /etc/default/grub añadir:
GRUB_ENABLE_CRYPTODISK=y
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:sistema root=/dev/vg0/root"

# 5. Reinstalar GRUB y actualizar
sudo grub-install /dev/sda
sudo update-grub

💡

Doble passphrase al arrancar: Con esta configuración GRUB pedirá la passphrase LUKS dos veces — una para descifrar /boot y leer el kernel, y otra para que el initramfs monte el sistema raíz. Puedes evitar la segunda petición añadiendo un keyfile al initramfs, pero esto reduce la seguridad. Para máxima seguridad, las dos peticiones son el comportamiento correcto.

Secure Boot personalizado

Secure Boot verifica criptográficamente que el bootloader y el kernel están firmados con una clave de confianza antes de ejecutarlos. El problema con el Secure Boot de fábrica es que la clave de confianza la controla Microsoft — cualquier software firmado por Microsoft puede arrancar en tu equipo.

La solución para OPSEC real es generar tus propias claves y reemplazar las de Microsoft. Solo arrancará software que tú hayas firmado.

bash — Secure Boot con claves propias usando sbctl

# sbctl es la herramienta más limpia para gestionar Secure Boot en Linux
sudo apt install -y sbctl

# 1. Verificar el estado actual de Secure Boot
sudo sbctl status
# Secure Boot: disabled
# Setup Mode: enabled  ← necesario para instalar claves propias

# Si no está en Setup Mode, entrar en la UEFI y borrar las claves existentes
# (opción "Reset to Setup Mode" o similar)

# 2. Crear las claves propias
sudo sbctl create-keys

# 3. Instalar las claves en el firmware UEFI
sudo sbctl enroll-keys --microsoft
# --microsoft incluye las claves de Microsoft además de las propias
# Omitir --microsoft para solo permitir tus binarios (más seguro pero puede
# romper arranque dual con Windows o algunos firmwares)

# 4. Firmar los binarios necesarios para arrancar
sudo sbctl sign -s /boot/vmlinuz-$(uname -r)
sudo sbctl sign -s /boot/initrd.img-$(uname -r)
sudo sbctl sign -s /boot/efi/EFI/debian/grubx64.efi

# 5. Verificar qué binarios están firmados
sudo sbctl verify

# 6. Activar Secure Boot en la UEFI y reiniciar
# Ahora solo arrancará software firmado con tus claves

2.2.4 Cold boot attacks y contramedidas: TRESOR, RAM encryption

El cold boot attack explota una propiedad física de la RAM: los datos no desaparecen instantáneamente al cortar la alimentación. Los módulos DRAM retienen su contenido durante varios segundos a temperatura normal — y durante minutos si se enfrían con spray de aire comprimido invertido o nitrógeno líquido. Un atacante con acceso físico inmediato puede volcar toda la RAM y recuperar claves criptográficas, claves de LUKS, contraseñas en memoria y cualquier otro dato sensible.

TRESOR: claves criptográficas en registros del CPU

TRESOR (TRESOR Runs Encryption Securely Outside RAM) es un parche del kernel Linux que almacena las claves AES en los registros de depuración del procesador (DR0-DR3) en lugar de en la RAM. Los registros del CPU no son accesibles desde RAM — no pueden volcarse con un cold boot attack.

bash — instalar TRESOR (requiere compilar kernel personalizado)

# TRESOR requiere aplicar el parche al kernel y recompilarlo
# Solo disponible para Intel x86 (no AMD, no ARM)

# 1. Descargar el kernel y el parche TRESOR
wget https://www.kernel.org/pub/linux/kernel/v6.x/linux-6.1.tar.xz
wget http://www1.informatik.uni-erlangen.de/tresor  # parche oficial

# 2. Aplicar el parche y compilar
tar xf linux-6.1.tar.xz
cd linux-6.1
patch -p1 < tresor.patch

# 3. Configurar el kernel activando TRESOR
make menuconfig
# Cryptographic API → TRESOR (AES in CPU registers)

# 4. Compilar e instalar
make -j$(nproc)
sudo make modules_install install

# Al arrancar con el kernel TRESOR, las claves AES nunca tocan la RAM

⚠️

TRESOR tiene limitaciones importantes: Funciona solo con AES en Intel x86. No protege todas las claves en memoria — solo las que usen la implementación TRESOR de AES. El kernel sigue teniendo otros datos sensibles en RAM. Para la mayoría de casos, las contramedidas físicas y de comportamiento (ver más abajo) son más prácticas que compilar un kernel personalizado.

Contramedidas prácticas

Más accesibles que TRESOR para la mayoría de operadores:

bash — contramedidas contra cold boot en Linux

# 1. Borrado de RAM al apagar con systemd
# El script de apagado sobreescribe la RAM antes de cortar la alimentación
sudo apt install -y cryptsetup-initramfs

# 2. Activar el borrado de memoria en el kernel
# Añadir a /etc/default/grub:
GRUB_CMDLINE_LINUX="... page_poison=1 slub_debug=P init_on_alloc=1 init_on_free=1"
# page_poison=1 y init_on_free=1 sobreescriben páginas de memoria al liberar

# 3. Deshabilitar arranque desde USB/DVD en la UEFI
# Y proteger la UEFI con contraseña
# Un cold boot attack requiere arrancar un SO de volcado desde USB
# Sin arranque USB, el atacante necesita más tiempo y herramientas

# 4. Deshabilitar la hibernación (ver también 2.2.7)
# La hibernación vuelca la RAM al disco — exactamente lo que queremos evitar
sudo systemctl mask hibernate.target hybrid-sleep.target

# 5. Configurar bloqueo automático de pantalla rápido
# Un equipo bloqueado pero encendido sigue siendo vulnerable
# Minimiza la ventana temporal en que el equipo está desbloqueado
gsettings set org.gnome.desktop.session idle-delay 60
gsettings set org.gnome.desktop.screensaver lock-enabled true

La contramedida más efectiva: el comportamiento

Ninguna contramedida técnica es tan efectiva como no dejar el equipo desatendido encendido. Las reglas operacionales que reducen el riesgo de cold boot son simples:

Apagado completo al alejarte del equipo — no suspensión. Suspendido, la RAM mantiene su estado indefinidamente con alimentación.
Apagado brusco si hay riesgo inminente — quitar la batería o el cable de alimentación. El apagado ordenado tarda demasiado si alguien entra por la puerta.
RAM soldada — los equipos con RAM soldada (no extraíble) complican enormemente el cold boot attack porque el atacante no puede mover los módulos a otro equipo para analizarlos.

2.2.5 Evitar leaks de escritorio: resoluciones únicas, fuentes instaladas, temas

Tu navegador revela más de lo que crees sobre tu sistema operativo y configuración, aunque uses Tor o una VPN. El browser fingerprinting recopila docenas de características del sistema — resolución de pantalla, lista de fuentes instaladas, configuración del canvas, zona horaria, idioma, plugins — para construir un identificador único que correlaciona tus visitas aunque cambies de IP.

Fuentes instaladas: el vector más revelador

La lista de fuentes instaladas en tu sistema es altamente identificativa. JavaScript puede enumerar qué fuentes tiene disponibles el navegador midiendo el renderizado de texto. Si tienes fuentes corporativas, fuentes de aplicaciones específicas o una combinación inusual de fuentes, ese perfil puede ser único.

bash — auditar y controlar fuentes instaladas

# Ver todas las fuentes instaladas en el sistema
fc-list | sort

# Ver cuántas fuentes tiene instaladas el sistema
fc-list | wc -l

# Cada fuente extra instalada hace tu perfil más único
# Lo ideal para anonimato: solo las fuentes base del sistema
# sin ninguna adicional instalada manualmente

# Ver qué paquetes de fuentes están instalados
dpkg -l '*font*' | grep "^ii"

# Eliminar fuentes no esenciales (ejemplo)
sudo apt remove --purge fonts-liberation fonts-noto-extra

# Desactivar la enumeración de fuentes del sistema en Firefox
# En about:config:
# layout.css.font-visibility.private    → 1 (solo fuentes del SO, no del usuario)
# layout.css.font-visibility.trackingprotection → 1

Resolución de pantalla y zoom

La resolución de pantalla que ve el navegador, combinada con el nivel de zoom y el tamaño de la ventana, es otro vector de fingerprinting. Resoluciones inusuales (ultrawide, muy altas, proporciones no estándar) son especialmente identificativas.

bash — verificar resolución y configurarla para reducir unicidad

# Ver la resolución actual
xrandr | grep " connected"

# Las resoluciones más comunes (máxima población, mínima unicidad):
# 1920x1080 (Full HD) → la más común en escritorio
# 1366x768 → la más común en portátiles de gama media
# 1280x720 → común, poca unicidad

# Establecer una resolución estándar temporalmente
xrandr --output eDP-1 --mode 1920x1080

# En Tor Browser la resolución del canvas ya está normalizada
# pero la resolución de pantalla sigue siendo visible
# Usar la ventana de Tor Browser sin maximizar es la recomendación oficial

Canvas fingerprint y WebGL

El canvas fingerprint aprovecha que el renderizado gráfico varía ligeramente entre combinaciones de GPU, driver y SO. Una pequeña diferencia en cómo se renderizan sombras o texto produce un hash único. WebGL expone información aún más detallada sobre la GPU y sus capacidades.

texto — configuración de Firefox para canvas y WebGL

# En about:config (Firefox)

# Canvas: añadir ruido al fingerprint (no bloquear, que levanta sospechas)
privacy.resistFingerprinting            → true
# Con RFP activo, Firefox normaliza el canvas y añade ruido aleatorio

# WebGL: desactivar si no se necesita
webgl.disabled                          → true
webgl.enable-webgl2                     → false

# WebRTC: deshabilitar para evitar fugas de IP local
media.peerconnection.enabled            → false

# Zona horaria: ocultarla
privacy.resistFingerprinting            → true
# RFP también normaliza la zona horaria a UTC

# Verificar tu fingerprint en:
# https://coveryourtracks.eff.org
# https://amiunique.org

2.2.6 Navegador anónimo real: Firefox user.js hardening, Tor Browser, fingerprinting

No existe el "navegador anónimo" que funcione sin configuración. Incluso Tor Browser puede romper el anonimato si se configura mal o si las expectativas sobre lo que protege son incorrectas. Este apartado trata de qué protege realmente cada opción y cómo configurarla correctamente.

Tor Browser: qué protege y qué no

Tor Browser protege contra	Tor Browser NO protege contra
Tu ISP viendo qué sitios visitas	Iniciar sesión en tu cuenta real (Google, etc.)
El sitio web viendo tu IP real	Descargar archivos y abrirlos con aplicaciones del SO
Rastreo entre sitios (sin cookies)	JavaScript que explota el navegador (breakout)
Canvas y WebGL fingerprinting (normalizado)	Correlación de tráfico (si el adversario ve entrada y salida de Tor)
Fugas de DNS	Plugins y extensiones que hagas llamadas directas

🚫

Nunca maximices la ventana de Tor Browser: El proyecto Tor recomienda explícitamente no maximizar la ventana porque la resolución real de la pantalla se filtra al sitio web y puede ser un vector de fingerprinting. Usa Tor Browser en su tamaño por defecto.

Firefox con arkenfox user.js

Arkenfox (anteriormente ghacks user.js) es un archivo de configuración de Firefox que aplica cientos de ajustes de seguridad y privacidad. Es el estándar de referencia para endurecer Firefox más allá de sus valores por defecto.

bash — instalar arkenfox user.js en Firefox

# 1. Encontrar el directorio del perfil de Firefox
# Abrir Firefox y visitar: about:profiles
# Copiar la ruta del "Root Directory" del perfil activo
PERFIL="~/.mozilla/firefox/xxxxxxxx.default"

# 2. Descargar arkenfox user.js
wget https://raw.githubusercontent.com/arkenfox/user.js/master/user.js \
    -O "${PERFIL}/user.js"

# 3. Crear user-overrides.js para tus personalizaciones
# (no modificar user.js directamente para facilitar actualizaciones)
cat > "${PERFIL}/user-overrides.js" << 'EOF'
// Ajustes personalizados que sobreescriben arkenfox
// Activar JavaScript (arkenfox lo desactiva por defecto en alguna versión)
user_pref("javascript.enabled", true);
// Idioma: inglés para reducir unicidad
user_pref("intl.accept_languages", "en-US, en");
EOF

# 4. Ejecutar el script de actualización de arkenfox
wget https://raw.githubusercontent.com/arkenfox/user.js/master/updater.sh
chmod +x updater.sh
./updater.sh
# Mantener arkenfox actualizado es importante — se actualiza frecuentemente

Configuraciones clave de about:config

texto — ajustes críticos de Firefox en about:config

## Telemetría y recopilación de datos (desactivar todo)
datareporting.healthreport.uploadEnabled          → false
datareporting.policy.dataSubmissionEnabled        → false
toolkit.telemetry.unified                         → false
browser.ping-centre.telemetry                     → false

## Resistencia a fingerprinting
privacy.resistFingerprinting                      → true
privacy.fingerprintingProtection                  → true

## DNS sobre HTTPS (usar Cloudflare o tu propio resolver)
network.trr.mode                                  → 3  (DoH exclusivo)
network.trr.uri                                   → https://1.1.1.1/dns-query

## Cookies y rastreo
network.cookie.cookieBehavior                     → 5  (solo cookies del mismo sitio)
privacy.trackingprotection.enabled                → true
privacy.trackingprotection.socialtracking.enabled → true

## Historial: no guardar nada
places.history.enabled                            → false
browser.formfill.enable                           → false
signon.rememberSignons                            → false

## WebRTC: deshabilitar para evitar fugas de IP local
media.peerconnection.enabled                      → false

## Prefetch y especulación (hacen peticiones en tu nombre)
network.prefetch-next                             → false
network.dns.disablePrefetch                       → true
network.predictor.enabled                         → false

2.2.7 Swap y volcados de memoria: swap cifrada, volcado de núcleo desactivado

La swap y los volcados de memoria son dos lugares donde el sistema operativo escribe datos sensibles en disco sin que el usuario lo pida o lo note. Claves criptográficas, contraseñas que pasaron por memoria, fragmentos de archivos abiertos — todo puede acabar en swap o en un core dump en texto plano, incluso si tienes el disco cifrado con LUKS.

⚠️

El cifrado LUKS no protege automáticamente la swap: Si tienes una partición swap separada del volumen LUKS cifrado, esa swap está en texto plano. Linux puede escribir claves de LUKS en swap cuando hay presión de memoria — y esas claves quedan en disco hasta que se sobrescriben. El cifrado del disco raíz no implica que la swap esté cifrada.

Cifrar la swap

bash — swap cifrada con clave aleatoria (la opción más segura)

# Opción 1: swap cifrada con clave aleatoria en cada arranque
# La swap se recifra con una clave nueva en cada arranque
# No permite hibernación pero es la opción más segura

# 1. Editar /etc/crypttab para definir el volumen de swap cifrado
sudo nano /etc/crypttab

# Añadir esta línea (sustituir /dev/sdaX por tu partición swap):
# swap  /dev/sdaX  /dev/urandom  swap,cipher=aes-xts-plain64,size=256

# 2. Editar /etc/fstab para usar el mapper de la swap cifrada
sudo nano /etc/fstab

# Cambiar la línea de swap para que use /dev/mapper/swap:
# /dev/mapper/swap  none  swap  sw  0  0
# (eliminar la línea que apuntaba directamente a la partición)

# 3. Reiniciar para aplicar los cambios
sudo reboot

# 4. Verificar que la swap está activa y cifrada
swapon --show
sudo dmsetup status swap
# Debe mostrar el mapper de swap como un dispositivo dm-crypt

# Opción 2: usar un swapfile en el sistema de archivos raíz ya cifrado
# Si / está en LUKS, un swapfile dentro de / hereda el cifrado
# 1. Crear el swapfile
sudo dd if=/dev/zero of=/swapfile bs=1G count=4
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
# 2. Añadir a /etc/fstab para que persista
echo "/swapfile none swap sw 0 0" | sudo tee -a /etc/fstab

Desactivar volcados de núcleo (core dumps)

Cuando un proceso falla con una señal como SIGSEGV o SIGABRT, el kernel puede escribir el contenido completo de su memoria en un archivo. Ese archivo puede contener claves privadas, contraseñas, fragmentos de documentos abiertos y cualquier otro dato que el proceso tuviera en memoria.

bash — desactivar core dumps

# 1. Desactivar core dumps para todos los usuarios
# Añadir a /etc/security/limits.conf:
echo "* hard core 0" | sudo tee -a /etc/security/limits.conf
echo "* soft core 0" | sudo tee -a /etc/security/limits.conf

# 2. Desactivar en systemd
sudo mkdir -p /etc/systemd/coredump.conf.d/
cat > /etc/systemd/coredump.conf.d/disable.conf << 'EOF'
[Coredump]
Storage=none
ProcessSizeMax=0
EOF

# 3. Desactivar en sysctl
echo "kernel.core_pattern=|/bin/false" | sudo tee -a /etc/sysctl.d/disable-coredump.conf
sudo sysctl -p /etc/sysctl.d/disable-coredump.conf

# 4. Verificar que los core dumps están desactivados
ulimit -c
# Debe devolver 0

# 5. Desactivar crash reports automáticos (Ubuntu/Debian)
sudo systemctl disable apport 2>/dev/null
sudo systemctl mask apport 2>/dev/null
echo "enabled=0" | sudo tee /etc/default/apport

Hibernación: el volcado de RAM al disco

La hibernación escribe el contenido completo de la RAM en la partición swap o en un archivo de hibernación en disco. Si el disco no está cifrado — o si la swap no está dentro del volumen cifrado — la hibernación expone todo lo que había en memoria.

bash — desactivar hibernación completamente

# Desactivar las unidades de systemd relacionadas con hibernación
sudo systemctl mask hibernate.target
sudo systemctl mask hybrid-sleep.target
sudo systemctl mask suspend-then-hibernate.target

# Verificar que están maskeadas (no se pueden activar)
systemctl status hibernate.target
# Loaded: masked

# Desactivar también en el kernel (impide que el botón de hibernación funcione)
echo "HandleHibernateKey=ignore" | sudo tee -a /etc/systemd/logind.conf
echo "HibernateMode=invalid" | sudo tee -a /etc/systemd/sleep.conf

# Si usas LUKS con swap cifrada y quieres hibernación segura:
# necesitas que la swap esté dentro del volumen LUKS (no clave aleatoria)
# y añadir el parámetro "resume=/dev/mapper/swap" al kernel