Hardening del Kernel Linux 2026: sysctl, KASLR, Lockdown LSM y Secure Boot
Guía práctica de hardening del kernel Linux en 2026: parámetros sysctl, KASLR, KPTI, Lockdown LSM en modo confidentiality, Secure Boot con claves propias y restricción de io_uring y user namespaces, con auditoría CIS.
El hardening del kernel Linux consiste en reducir la superficie de ataque del núcleo del sistema operativo mediante parámetros sysctl restrictivos, mitigaciones como KASLR y SMEP/SMAP, el módulo Lockdown LSM y arranque verificado con Secure Boot. En 2026, con vulnerabilidades como Spectre-BHI, Inception y los recientes fallos en el subsistema io_uring, configurar correctamente el kernel ya no es opcional para servidores en producción. Honestamente, esta guía recoge los ajustes que aplico habitualmente en despliegues que deben cumplir CIS Benchmarks y STIG (y que me han ahorrado más de un susto en auditorías).
Endurece el kernel con al menos 18 parámetros sysctl de seguridad agrupados en /etc/sysctl.d/99-hardening.conf y aplicados con sysctl --system.
KASLR está activo por defecto en Linux 6.x, pero KPTI, SMEP, SMAP y mitigaciones de Spectre/Meltdown deben verificarse explícitamente en /sys/devices/system/cpu/vulnerabilities/.
El módulo Lockdown LSM en modo confidentiality bloquea /dev/mem, kexec sin firma y la carga de módulos no firmados, incluso para root.
Secure Boot con claves propias (MOK) garantiza que solo bootloaders, kernels e initramfs firmados por ti se carguen, mitigando rootkits de bajo nivel.
Deshabilitar io_uring (kernel.io_uring_disabled=2) y restringir user namespaces elimina dos de las superficies de explotación más activas en 2025-2026.
El kernel es el componente más privilegiado de cualquier sistema Linux: una vulnerabilidad explotable allí significa compromiso total, sin que SELinux, contenedores o usuarios sin privilegios puedan contenerla. Durante 2024 y 2025 se publicaron más de 40 CVE críticos en subsistemas como io_uring, nf_tables, perf_events y los user namespaces, varios de ellos con exploits públicos que escalaban de usuario no privilegiado a root en segundos. El proyecto Kernel Self Protection Project (KSPP) mantiene una lista de configuraciones recomendadas, aunque la mayoría de distribuciones no las aplica por defecto por motivos de compatibilidad.
El hardening del kernel persigue tres objetivos concretos. Primero, reducir la superficie expuesta deshabilitando funcionalidad que tu carga de trabajo no necesita. Segundo, elevar el coste de explotación con randomización (KASLR), separación de espacios (KPTI) y comprobaciones SMEP/SMAP. Y tercero, romper la cadena de persistencia con Secure Boot y módulos firmados, para que un atacante con root no pueda instalar un rootkit residente entre reinicios. Estos tres pilares son complementarios: KASLR sin Lockdown se neutraliza leyendo /dev/kmem, y Lockdown sin Secure Boot se evita reemplazando el kernel.
Parámetros sysctl esenciales para seguridad
Los parámetros sysctl ajustan el comportamiento del kernel en runtime. Crea el archivo /etc/sysctl.d/99-hardening.conf con los siguientes valores; cada uno aborda una clase de ataque concreta. Aplícalos con sudo sysctl --system y verifica con sysctl -a | grep <clave>.
# /etc/sysctl.d/99-hardening.conf — perfil de hardening para servidores 2026
# --- Ocultar información del kernel ---
kernel.kptr_restrict = 2 # Oculta direcciones del kernel en /proc
kernel.dmesg_restrict = 1 # Solo root lee dmesg (mitiga info-leaks)
kernel.printk = 3 3 3 3 # Reduce verbosidad de logs del kernel
kernel.kexec_load_disabled = 1 # Bloquea kexec tras el arranque
# --- Restricción de ptrace y core dumps ---
kernel.yama.ptrace_scope = 2 # Solo root puede usar ptrace (mitiga GDB-as-attacker)
fs.suid_dumpable = 0 # SUID no genera core dumps (evita fugas)
kernel.core_pattern = |/bin/false # Descarta core dumps por completo
# --- Restricción de BPF y perf ---
kernel.unprivileged_bpf_disabled = 1
net.core.bpf_jit_harden = 2
kernel.perf_event_paranoid = 3 # Solo root usa perf_event_open
# --- Restricción de user namespaces (rootless containers + exploits) ---
kernel.unprivileged_userns_clone = 0 # Debian/Ubuntu
user.max_user_namespaces = 0 # RHEL/Fedora con podman: usa >0 según necesidad
# --- io_uring (vector de exploits 2023-2025) ---
kernel.io_uring_disabled = 2 # 0=permitido, 1=opt-in, 2=deshabilitado total
# --- Red: anti-spoofing y SYN flood ---
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
# --- IPv6 equivalentes ---
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_ra = 0
# --- Memoria: ASLR máximo y protección de enlaces ---
kernel.randomize_va_space = 2
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_fifos = 2
fs.protected_regular = 2
KASLR, KPTI y mitigaciones de CPU
KASLR (Kernel Address Space Layout Randomization) aleatoriza la dirección base donde se carga el kernel en cada arranque, dificultando exploits que dependen de offsets fijos. En Linux 6.x está activo por defecto, pero conviene verificarlo y combinarlo con KPTI (Kernel Page Table Isolation, la mitigación de Meltdown) y las protecciones contra Spectre v1, v2, v4 y BHI. La documentación oficial del kernel sobre vulnerabilidades de hardware enumera los flags cmdline relevantes.
Verifica el estado actual leyendo /sys/devices/system/cpu/vulnerabilities/:
En entornos donde el rendimiento importa menos que la seguridad (sistemas de compliance, hosts de bastión, gestores de secretos), endurece la línea de comandos del kernel editando /etc/default/grub y añadiendo a GRUB_CMDLINE_LINUX:
La opción nosmt deshabilita Hyper-Threading. Es la única mitigación completa contra ataques de canal lateral cross-thread como L1TF y MDS, a costa de aproximadamente un 20-30% de throughput en workloads paralelos. En servidores multi-tenant o con datos sensibles, desactivar SMT es la opción correcta. Sí, duele un poco al ver los benchmarks; también vas a dormir mejor.
Activar Lockdown LSM en modo confidentiality
El módulo Lockdown es un LSM (Linux Security Module) introducido en kernel 5.4 que restringe operaciones que, aunque legítimas para root, comprometen la integridad o confidencialidad del kernel en ejecución. Tiene tres modos: none (deshabilitado), integrity (bloquea modificación del kernel en runtime: kexec sin firma, escritura a /dev/mem, BPF para sondear memoria del kernel) y confidentiality (todo lo anterior más lectura: bloquea kprobes, lectura de /proc/kcore, dump de claves del kernel).
Para activarlo de forma persistente, añade lockdown=confidentiality a la línea de comandos del kernel (ya incluido en el ejemplo anterior) y verifica:
$ cat /sys/kernel/security/lockdown
none [integrity] confidentiality # el valor entre corchetes es el activo
# Si compilas tu propio kernel, asegúrate de tener:
# CONFIG_SECURITY_LOCKDOWN_LSM=y
# CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y
# CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY=y
# Comprobar LSMs activos en orden
$ cat /sys/kernel/security/lsm
lockdown,capability,yama,apparmor,bpf
Configurar Secure Boot con claves propias
Secure Boot es una característica UEFI que verifica criptográficamente cada componente de la cadena de arranque (bootloader, kernel, initramfs) antes de ejecutarlo. Por defecto, los sistemas vienen con las claves de Microsoft pre-cargadas, lo que técnicamente permite a cualquier binario firmado por Microsoft (incluyendo el bootloader de Windows y, por shim, distribuciones Linux mayoritarias) ejecutarse. Para hardening serio, conviene reemplazar las claves del fabricante por las tuyas propias, un proceso documentado en la guía de Secure Boot del Arch Wiki.
El flujo completo para usar tus propias claves implica: (1) generar PK, KEK y db con openssl; (2) entrar al setup UEFI y borrar las claves del fabricante (poniendo el sistema en Setup Mode); (3) cargar tus claves con efi-updatevar; (4) firmar el bootloader (shimx64.efi o systemd-boot) y cada kernel nuevo con sbsign. Para automatizar la firma tras cada actualización, instala el paquete sbsigntool y configura un hook de dpkg o dnf:
# Generar claves (ejecutar UNA vez)
$ openssl req -new -x509 -newkey rsa:2048 -keyout db.key -out db.crt \
-days 7300 -nodes -sha256 -subj "/CN=Mi clave de firma kernel/"
# Firmar el kernel actual
$ sudo sbsign --key db.key --cert db.crt \
--output /boot/vmlinuz-6.8.0-45-generic.signed \
/boot/vmlinuz-6.8.0-45-generic
# Verificar firma
$ sbverify --cert db.crt /boot/vmlinuz-6.8.0-45-generic.signed
Signature verification OK
Una vez en producción, combina Secure Boot con cifrado LUKS2 vinculado al TPM 2.0: el TPM solo libera la clave de descifrado si el PCR que mide el bootloader y el kernel coincide con los valores esperados. Esto convierte cualquier modificación de la cadena de arranque en un fallo de descifrado. El atacante puede sustituir el kernel, pero el disco permanece inaccesible.
Restringir io_uring y user namespaces
io_uring es una interfaz de I/O asíncrono introducida en Linux 5.1 que ofrece un rendimiento excepcional, pero ha sido la fuente de docenas de CVE críticos entre 2022 y 2025. Google, ChromeOS y Android lo deshabilitaron en sus kernels por defecto. Desde Linux 6.6 existe kernel.io_uring_disabled: el valor 2 lo desactiva completamente, 1 requiere capability CAP_SYS_ADMIN y 0 permite uso sin restricciones. Si tu carga de trabajo no usa explícitamente io_uring (la mayoría no lo hace), ponerlo a 2 elimina toda una clase de exploits.
Los user namespaces sin privilegios permiten a un usuario normal crear un namespace donde tiene capabilities root simuladas, la base de Podman rootless, sandboxes de navegadores y herramientas como bubblewrap. También han sido vector recurrente de escaladas de privilegios (CVE-2023-32233 en nftables, CVE-2024-1086, varios en io_uring). Si no usas contenedores rootless en el host, deshabilítalos:
Aplicar configuraciones es la mitad del trabajo; la otra mitad es verificar que siguen aplicadas tras actualizaciones, despliegues de Ansible o cambios manuales. Tres herramientas cubren el grueso de la verificación: kernel-hardening-checker (antiguo kconfig-hardened-check), Lynis y OpenSCAP con el perfil CIS Linux Server.
# 1. kernel-hardening-checker: revisa CONFIG_* y cmdline contra KSPP
$ pip install --user kernel-hardening-checker
$ kernel-hardening-checker -c /boot/config-$(uname -r) \
-l /proc/cmdline -s /etc/sysctl.d/99-hardening.conf
# 2. Lynis: auditoría general que incluye chequeos de kernel
$ sudo lynis audit system --tests-from-group "kernel,authentication,malware"
# 3. OpenSCAP con perfil CIS para RHEL/Ubuntu
$ sudo oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis \
--results /tmp/cis-results.xml --report /tmp/cis-report.html \
/usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
Integra estos chequeos en tu pipeline de CI/CD para detectar drift. Un job semanal que ejecute lynis y publique el hardening index (un número entre 0 y 100) en tu dashboard de seguridad evidencia regresiones antes de que un auditor las encuentre. En la práctica, ese único número me ha servido para defender presupuestos de seguridad ante dirección mejor que cualquier informe largo. Si ya tienes una capa MAC con SELinux o AppArmor, añadir estas verificaciones contra una imagen base es trivial y aporta una señal de calidad continua sobre tu plataforma.
Preguntas frecuentes
¿Cómo verifico si KASLR está activo en mi servidor Linux?
Ejecuta sudo dmesg | grep -i kaslr tras el arranque; deberías ver "KASLR enabled". Alternativamente, compara la dirección de _text en /proc/kallsyms entre dos arranques: si cambia, KASLR funciona. Si el parámetro nokaslr aparece en /proc/cmdline, está desactivado.
¿Qué diferencia hay entre Lockdown integrity y confidentiality?
El modo integrity bloquea operaciones que modifican el kernel en ejecución (kexec sin firma, escritura a /dev/mem, módulos sin firmar). El modo confidentiality añade el bloqueo de lectura de memoria del kernel: kprobes, /proc/kcore y volcado de claves. Para servidores de producción, usa siempre confidentiality.
¿Es seguro deshabilitar io_uring en un servidor en producción?
Sí, salvo que tu aplicación lo use explícitamente (PostgreSQL 16+ opcionalmente, algunos proxies de alto rendimiento, ScyllaDB). La mayoría de cargas web, bases de datos y contenedores usan APIs tradicionales (epoll, aio) y no notan ninguna diferencia. Verifica con strace -e io_uring_setup -p <PID> antes de deshabilitarlo.
¿Puedo activar Secure Boot sin perder el dual-boot con Windows?
Sí, usando shim firmado por Microsoft (la opción por defecto en Ubuntu, Fedora y openSUSE). Para mantener tus propias claves y seguir arrancando Windows, mantén la clave de Microsoft en la KEK y db; perderás parte del beneficio de seguridad pero conservarás compatibilidad. La solución más limpia es separar Windows en otra máquina o VM.
¿Qué parámetros sysctl no debería tocar nunca en producción?
Evita modificar net.ipv4.tcp_* agresivamente sin medir (afecta a latencia y throughput), no pongas vm.swappiness=0 en sistemas con poca RAM (puede causar OOM kills), y no deshabilites kernel.unprivileged_userns_clone si usas Podman rootless, sandbox de Chrome o Snap. Cambia un parámetro a la vez y monitoriza al menos 24 horas antes de aplicarlo en flota.
Aprende a aplicar sandboxing declarativo a tus unidades systemd con ProtectSystem, NoNewPrivileges, SystemCallFilter y DynamicUser. Mide el impacto con systemd-analyze security y endurece un servicio real de 9.6 (UNSAFE) a 1.4 (SAFE).
Guía práctica de cifrado de disco con LUKS2 en Linux 2026: Argon2id como KDF, desbloqueo automático con TPM 2.0 y systemd-cryptenroll, NBDE con Clevis/Tang, rotación de claves y backups del header LUKS.
Guía práctica de SELinux y AppArmor para servidores Linux en 2026. Aprende a configurar políticas MAC personalizadas, diagnosticar denegaciones y automatizar con Ansible — con ejemplos reales para Nginx, PostgreSQL y contenedores.
