Hardening de Linux en 2026: la guía threat-model-first

La mayoría de las guías de hardening de Linux son listas de verificación. Te dicen qué parámetros sysctl establecer, qué servicios deshabilitar, qué módulos del kernel poner en lista negra. Raramente responden a la pregunta previa: ¿contra qué amenaza te estás defendiendo realmente?

La respuesta cambia el trabajo. Un periodista que protege a sus fuentes frente a malware dirigido necesita medidas muy distintas de las de un administrador de sistemas que reduce la superficie de ataque de un servidor sin amenazas físicas. Esta guía va del modelo de amenaza a la medida, no de la medida a su justificación.

Está arraigada en el linaje de seguridad de este dominio - el mismo pensamiento operacional que impulsó la lista de correo Secure Desktops (2015-2017), donde los desarrolladores de Qubes OS, Tails y Subgraph discutían hardening práctico sin el marketing.

Dos capas que conviene combinar con los pasos siguientes: entender qué hace realmente un cortafuegos, y el sandboxing de aplicaciones con Firejail para confinar programas de riesgo.

Paso cero: define tu modelo de amenaza

Antes de tocar un solo archivo de configuración, responde estas cuatro preguntas:

1. ¿Quién es el adversario? ¿Oportunista casual, criminal organizado, investigador corporativo, Estado-nación?
2. ¿Qué buscan? ¿Archivos en disco, comunicaciones, credenciales, tu identidad, tus contactos?
3. ¿Cómo entrarán? ¿Exploit de red, acceso físico, cadena de suministro, ingeniería social?
4. ¿Qué recursos tienen? ¿Tiempo, dinero, zero-days, autoridad legal?

Las medidas de esta guía están agrupadas por la amenaza que abordan. Aplica solo las capas que se correspondan con tus respuestas. Aplicar un hardening excesivo a una estación de trabajo genera fricción sin una ganancia de seguridad proporcional, y la fricción hace que la gente termine esquivando los controles.

Lo que el endurecimiento no cubre

Todo lo anterior reduce lo que un proceso comprometido puede alcanzar en esta máquina. No dice nada de los caminos que nunca pasan por ella: una contraseña repetida en un servicio que sufrió una fuga, una sesión que sigue abierta en un aparato que ya no lleva encima, una cuenta capaz de restablecer todas las demás porque es la que recibe los enlaces de recuperación.

Sitúe su propia superficie de ataque, 10 preguntas, unos tres minutos, sin cuenta, sin correo, y no se guarda nada. El resultado nombra el gesto que más reduce su exposición, y rara vez es otro ajuste del núcleo.

Hardening del kernel: parámetros sysctl

Los siguientes parámetros son apropiados para la mayoría de instalaciones de escritorio y servidor con hardening. No requieren hardware especializado y no tienen impacto significativo en el rendimiento.

# /etc/sysctl.d/99-hardening.conf

# Restrict kernel pointers from userspace (defeats certain info-leak attacks)
kernel.kptr_restrict=2

# Restrict dmesg access to root (prevents attackers reading kernel memory addresses)
kernel.dmesg_restrict=1

# Disable SysRq key (prevents certain physical-access attacks)
kernel.sysrq=0

# Restrict ptrace to processes with CAP_SYS_PTRACE (limits debug attach)
kernel.yama.ptrace_scope=2

# Disable unprivileged user namespaces (large attack surface, rarely needed on desktops)
kernel.unprivileged_userns_clone=0

# Disable unprivileged eBPF (significant attack surface for CVE exploitation)
kernel.unprivileged_bpf_disabled=1

# Enable TCP SYN cookies (basic DoS resistance)
net.ipv4.tcp_syncookies=1

# Disable ICMP redirects (routing manipulation attacks)
net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.default.accept_redirects=0
net.ipv6.conf.all.accept_redirects=0

# Disable source routing (rarely legitimate, used in spoofing attacks)
net.ipv4.conf.all.accept_source_route=0

# Enable reverse path filtering (defeats IP spoofing)
net.ipv4.conf.all.rp_filter=1

# Disable core dumps (prevents memory exposure of crashed processes)
fs.suid_dumpable=0

# Restrict symlink and hardlink following (prevents certain privilege escalation attacks)
fs.protected_symlinks=1
fs.protected_hardlinks=1

Aplicar inmediatamente sin reiniciar:

sudo sysctl -p /etc/sysctl.d/99-hardening.conf

Contra qué no protegen: son ajustes a nivel de kernel, no defensas de la capa de aplicación. Un exploit de navegador que no necesite ptrace, espacios de nombres de usuario ni eBPF no se ve afectado por los parámetros correspondientes. Son una capa de apoyo, no un sustituto del aislamiento de aplicaciones (mira Qubes OS si el aislamiento es tu requisito principal).

Control de acceso obligatorio: AppArmor vs SELinux

Tanto AppArmor como SELinux implementan el control de acceso obligatorio (MAC): una capa de políticas que restringe lo que los procesos pueden hacer, con independencia de los permisos de archivo. El MAC impone el principio de mínimo privilegio a nivel de kernel. Si no estás seguro de cuál habilitar, nuestra comparación AppArmor vs SELinux detalla la diferencia entre el diseño basado en rutas y el basado en etiquetas, el coste de mantenimiento y a qué modelos de amenaza se adapta cada uno.

AppArmor (predeterminado en Ubuntu, Debian, SUSE)

AppArmor utiliza perfiles basados en rutas. Cada aplicación recibe un perfil que especifica qué archivos puede leer, escribir o ejecutar, qué capacidades puede usar y qué operaciones de red están permitidas. Los perfiles funcionan en dos modos: enforce (las violaciones se bloquean y se registran) y complain (las violaciones se registran pero se permiten - útil durante el desarrollo).

# Check AppArmor status
sudo apparmor_status

# List all loaded profiles
sudo aa-status

# Put a profile into enforce mode
sudo aa-enforce /etc/apparmor.d/usr.bin.firefox

# Generate a new profile for an application
sudo aa-genprof /usr/bin/myapp

Los repositorios de Ubuntu y Debian incluyen perfiles preescritos para aplicaciones comunes. Instálalos:

sudo apt install apparmor-profiles apparmor-profiles-extra

Recomendación práctica: en un sistema Ubuntu o Debian, asegúrate de que AppArmor esté habilitado en el arranque (verifícalo con sudo apparmor_status | grep "profiles are in enforce mode") y de que Firefox, Chromium y cualquier proceso de servidor (nginx, sshd, cups) se ejecuten con perfiles en modo enforce.

SELinux (predeterminado en Fedora, RHEL, CentOS)

SELinux utiliza políticas basadas en etiquetas. Cada proceso, archivo, socket y usuario recibe un contexto de seguridad (una etiqueta), y las reglas de política definen qué contextos pueden interactuar entre sí. Esto es más granular que AppArmor, pero significativamente más complejo de mantener.

En Fedora, SELinux está habilitado en modo Enforcing de forma predeterminada. Verifícalo:

getenforce
# Should output: Enforcing

No deshabilites SELinux. Una respuesta habitual y equivocada ante las denegaciones de SELinux es setenforce 0. En su lugar, diagnostica la denegación:

sudo ausearch -m avc -ts recent | audit2allow -a

La herramienta audit2allow sugiere módulos de política que permitirían la acción denegada. Revísalos antes de aplicarlos - el objetivo es entender por qué se produjo la denegación, no permitirla de forma indiscriminada.

Parámetros de arranque del kernel

Los parámetros de arranque (definidos en la configuración de GRUB) se aplican antes que sysctl en el proceso de arranque y abordan superficies de ataque diferentes.

Añádelos a GRUB_CMDLINE_LINUX en /etc/default/grub y después ejecuta sudo update-grub:

# Disable SMT if you have a high-threat CPU side-channel model (Spectre, MDS)
# Performance cost: significant (up to 30-50% on multi-threaded workloads)
# Only appropriate for threat models involving local co-tenancy or targeted CPU attacks
# mitigations=auto,nosmt

# Enable all CPU vulnerability mitigations (default on most distros, worth verifying)
mitigations=auto

# Randomize page allocation (increases difficulty of certain heap exploitation)
page_alloc.shuffle=1

# Enable kernel lockdown (Integrity or Confidentiality mode)
# Locks down several features used by rootkits; may break some functionality
lockdown=integrity

# Disable old IPv4 network protocols rarely used (reduce attack surface)
ipv6.disable=0   # Keep IPv6 enabled; disable if genuinely unused

# Disable Firewire DMA (physical access attack vector on older hardware)
module.sig_enforce=1

Nota sobre lockdown=confidentiality: este modo impide que incluso root lea la memoria del kernel a través de /dev/mem e interfaces similares. Rompe algunos usos legítimos (ciertos controladores, kexec, la hibernación). Usa el modo integrity salvo que tengas una razón concreta para confidentiality.

Hardening del sistema de archivos y de los servicios

Opciones de montaje

En /etc/fstab, añade opciones de montaje de seguridad donde corresponda:

# /tmp: no execution, no device files, no SUID bits
tmpfs /tmp tmpfs defaults,noexec,nodev,nosuid 0 0

# /var/tmp: same
tmpfs /var/tmp tmpfs defaults,noexec,nodev,nosuid 0 0

# /home: no device files, no SUID (noexec breaks some workflows - test first)
/dev/mapper/home /home ext4 defaults,nodev,nosuid 0 2

Deshabilitar servicios no utilizados

Cada servicio en ejecución es una superficie de ataque. En un escritorio:

# List enabled services
systemctl list-unit-files --state=enabled

# Common candidates for disabling on a desktop with no network service requirements:
sudo systemctl disable cups   # Printing - if you never print
sudo systemctl disable avahi-daemon  # mDNS - if you don't need .local resolution
sudo systemctl disable bluetooth  # If not using Bluetooth

En un servidor, el principio es más agresivo: solo deberían ejecutarse los servicios necesarios para la función declarada de la máquina. Todo socket a la escucha debería tener una razón documentada para existir.

Verified Boot y Secure Boot

Secure Boot con tus propias claves inscritas (no solo las claves predeterminadas de Microsoft) protege frente a bootkits que se cargan antes que el sistema operativo. En Fedora y Ubuntu, las distribuciones firman su cargador de arranque y su kernel con claves en las que el firmware UEFI confía de forma predeterminada.

Para una configuración con mayores garantías, sustituye las claves predeterminadas por las tuyas:

1. Genera tu propia Platform Key (PK) y Key Exchange Key (KEK).
2. Inscribe tu clave en el firmware UEFI (el proceso varía según el fabricante).
3. Firma tu cargador de arranque y tus kernels con tu clave mediante sbsign.
4. Deshabilita “Other OS” o “Compatibility Support Module” en el firmware UEFI.

Esto es operacionalmente complejo y, en general, solo resulta apropiado para despliegues de alta amenaza. El proyecto de firmware Heads y proyectos similares van más allá y extienden el arranque medido a una cadena de confianza respaldada por TPM.

Lista de verificación por modelo de amenaza

Oportunista / malware masivo: parámetros sysctl anteriores, AppArmor/SELinux en enforce, disco cifrado (LUKS), actualizaciones regulares. Esto cubre el 95% de las amenazas comunes.

Atacante dirigido con acceso de red: añade minimización de servicios, cortafuegos restrictivo (nftables/ufw), sandboxing de aplicaciones (Firejail o Flatpak), monitorización del tráfico de salida de red.

Adversario con acceso físico y recursos: cifrado completo del disco con frase de contraseña robusta + copia de seguridad del encabezado, Secure Boot con claves personalizadas, Tails OS para operaciones sensibles, considera Qubes OS para la compartimentación. Revisa la carta Secure Desktops para conocer los principios operacionales detrás de estas decisiones.

Nivel estatal / Estado-nación: plantéate si una estación de trabajo Linux con hardening es siquiera la herramienta adecuada. Qubes OS con una arquitectura de qubes cuidadosa se acerca más al instrumento apropiado. Máquinas air-gapped para las operaciones más sensibles. Ningún punto único de fallo para el material criptográfico.

Preguntas frecuentes

P: ¿Deshabilitar los espacios de nombres de usuario sin privilegios rompe algo? R: Rompe aplicaciones que dependen de ellos sin root - notablemente el sandboxing de Chromium en los sistemas que lo usan y ciertos entornos de ejecución de contenedores (Docker/Podman sin root). En Ubuntu/Debian de escritorio, probablemente tendrás que volver a habilitarlos para Chromium. El compromiso está documentado; decide en función de tu modelo de amenaza.

P: ¿Debería usar un kernel con hardening (linux-hardened en Arch, o grsecurity)? R: linux-hardened en Arch Linux aplica un conjunto razonable de parches de hardening de upstream y vale la pena usarlo si estás en Arch. Los parches de grsecurity ya no están disponibles públicamente. El kernel upstream ha absorbido muchas características anteriormente exclusivas de grsecurity (KASLR, stack protector, FORTIFY_SOURCE, etc.) desde finales de la década de 2010.

P: ¿Es Fedora o Ubuntu más seguro por defecto? R: Ambos incluyen MAC en modo enforce (SELinux en Fedora, AppArmor en Ubuntu), valores predeterminados modernos de mitigaciones del kernel y actualizaciones de seguridad automáticas. Fedora suele publicar versiones del kernel más recientes con mayor rapidez. Ubuntu LTS renuncia a lo más puntero a cambio de soporte a largo plazo. Para un escritorio con hardening, ambos son un buen punto de partida; las medidas de esta guía se aplican a los dos.

Lecturas relacionadas: Fail2ban no asegura SSH, y su propio README lo dice · Hardening de servicios systemd · Wayland vs X11