Guía de Hardening en Linux

1. Kernel y Boot

Si la seguridad del arranque falla, el resto no importa: un atacante con control del bootloader o del kernel evita todas las capas superiores. La defensa de esta fase se cubre en la sección Seguridad a nivel de kernel (Secure Boot, Lockdown, parámetros sysctl, kernel hardened).

2. Access Control y MAC

MAC (Mandatory Access Control) busca separar privilegios incluso para procesos root, restringiendo lo que un proceso (aunque corra con UID 0) puede hacer. Se implementa mediante módulos de seguridad del kernel de Linux (LSM):

• AppArmor — perfiles por aplicación basados en rutas; notación simple.
• SELinux — política de etiquetas (type enforcement) sobre todo el sistema.

La elección depende de la distribución (AppArmor: Debian/Ubuntu/SUSE; SELinux: RHEL/Fedora/CentOS).

3. Servicios y Aplicaciones en Red

Proteger los servicios expuestos a cualquier red (Internet o LAN):

• SSH: fail2ban + oscuridad (puerto distinto de 22) + parámetros de seguridad (AllowUsers, MaxAuthTries, etc.) + deshabilitar login de root.
• Bases de datos: bindear al localhost (bind-address = 127.0.0.1) para no exponer el puerto.
• Web servers / proxies: security headers, eliminar funcionalidades que delatan la tecnología, rate limiting, restricción de métodos HTTP, TLS fuerte.
• Containers: nunca correr como root; parámetros de seguridad de Docker; escaneo de seguridad de las imágenes.

Otros:

• Fail2ban: protección contra bruteforce (ban por IP tras N fallos).
• Firehol: interfaz wrapper sobre iptables.

4. Cifrado por Niveles y Protección de Datos en Reposo

Niveles de cifrado:

• De bloque: LUKS (disco completo o la partición home).
• De archivos o directorios específicos: fscrypt, gocrypt.
• Archivos sueltos: GPG simétrico (gpg -c).
• Copias de seguridad / backup: cifrarlas — borg, restic.

5. Autenticación y Cuentas de Usuario

• Políticas de contraseñas (longitud, expiración vía pam_pwquality/chage).
• 2FA (TOTP con libpam-google-authenticator, WebAuthn).
• Restricción de su y sudo (grupo wheel/sudo en PAM, secure_path en sudoers).
• Protección contra bruteforce local (fail2ban, pam_faillock).

6. Red y Perímetro Local

Cortafuegos:

• Estático: solo abrir lo necesario (p.ej. SSH y HTTP) — iptables, nftables.
• Dinámico: respuesta adaptativa a tráfico malicioso — firehol, fail2ban, crowdsec.
• Protección de red a nivel de kernel (sysctl: net.ipv4.conf.*, rp_filter, SYN cookies).

7. Monitorización, Auditoría, Detección

• Monitorizar archivos críticos: /etc/passwd, /etc/shadow, claves SSH.
• aide (Advanced Intrusion Detection Environment): verificador de integridad de archivos/directorios.
• tripwire: monitorización de integridad.
• Centralización de logs: rsyslog, syslog-ng, logrotate.
• Herramientas modernas: osquery, wazuh, chkrootkit, rkhunter.

8. Aplicaciones y Entornos Específicos

Proteger lo que corre sobre los servicios, según la tecnología:

• Node.js: sin dependencias vulnerables (npm audit), no correr como root, usar cabeceras de seguridad.
• PHP: deshabilitar funciones de ejecución (exec, system, passthru y similares en php.ini).
• React/SPA: sanitizar entradas, CSP estricto.
• WordPress y CMS: actualización, plugins mínimos, hardening de wp-config.php.

9. Gestión de Actualizaciones

• AUR (Arch): solo paquetes confiables; revisar PKGBUILD y .install manualmente.
• Aplicar parches de seguridad de forma sistemática en el resto de distribuciones (unattended-upgrades en Debian/Ubuntu, dnf-automatic en RHEL).

Resumen

• Kernel / Boot: sysctl, linux-hardened, Secure Boot.
• Access control: AppArmor.
• Servicios de red.
• Cifrado de datos por niveles.
• Auth y cuentas de usuarios.
• Red y perímetro: firehol, iptables.
• Monitorización.
• Actualizaciones.

---

Seguridad a Nivel de Kernel

Glosario

1. UEFI
2. Firmware
3. Bootloader
4. Kernel — 1. Módulo del kernel
5. PKI (criptografía de clave pública)
6. Rootkit
7. Bootkit
8. LSM (Linux Security Module)
9. Spoofing (acto de pretender ser alguien)
10. SYN flood (inundación de paquetes SYN)
11. Evil maid attack

1. Secure Boot

Cada componente del proceso de arranque tiene una firma criptográfica; Secure Boot verifica esas firmas antes de ejecutar el componente — principalmente el bootloader y el kernel:

• Si la firma coincide → lo ejecuta.
• Si no coincide → no lo ejecuta.

Microsoft: la UEFI de la mayoría de equipos viene configurada con las "claves" de Microsoft y del fabricante, es decir, solo arrancan sistemas que ellos hayan aprobado.

Linux: esto es un problema para kernels personalizados, porque cualquier actualización del kernel requiere que las entidades anteriores lo autoricen.

Solución:

1. "Enrollar" tus propias claves UEFI (MOK).
2. Firmar tú mismo el bootloader y el kernel.

Para qué:

• Controlar completamente qué puede arrancar en la máquina.
• Protegerte de bootkits y rootkits de arranque que modifiquen GRUB o el kernel, y de Evil Maid Attacks que reemplacen el bootloader por otro.

Qué no te permite: protección contra malware con persistencia dentro del SO, contra firmware UEFI comprometido, ni contra un atacante con acceso físico prolongado capaz de reflashear el firmware o cambiar la configuración de UEFI si esta no está protegida por contraseña.

2. Parámetros del Kernel de Linux

El kernel expone parámetros como archivos virtuales y la interfaz para configurarlos es sysctl. Algunos ajustes tienen implicaciones directas en seguridad:

• Protecciones de manejo de red a bajo nivel, antes de que ninguna aplicación o firewall de usuario los procese.
• Protecciones de memoria contra exploits que abusan de la gestión de memoria del kernel.
  • ASLR (Address Space Layout Randomization).
  • ROP (Return-Oriented Programming).
  • Information leak: fuga de información desde logs del kernel.
  • ptrace: syscall que permite a un proceso inspeccionar y controlar a otro — legítima para debuggers, vector para inyección.

Ejemplos de endurecimiento sysctl:

# Restringir dmesg y punteros del kernel
kernel.dmesg_restrict=1
kernel.kptr_restrict=2

# Protecciones de red (SYN cookies, rp_filter)
net.ipv4.tcp_syncookies=1
net.ipv4.conf.all.rp_filter=1

sysctl -w net.ipv4.tcp_syncookies=1        # cambio temporal
# persistente: /etc/sysctl.conf + sysctl -p

3. Deshabilitación de Módulos que Abren Vectores de Ataque

Thunderbolt, uvcvideo, Bluetooth y otros módulos que habilitan acceso DMA (Direct Memory Access) al sistema. Un periférico malicioso puede leer memoria física; si no se usa el hardware, se bloquea el módulo:

echo "blacklist thunderbolt" > /etc/modprobe.d/block-dma.conf
echo "blacklist uvcvideo"    >> /etc/modprobe.d/block-dma.conf

4. Utilizar el Kernel Linux Hardened en Lugar del Mainline

Este kernel inclina el balance entre seguridad, rendimiento y compatibilidad hacia la seguridad. Trae el módulo Lockdown configurado por defecto, entre otros endurecimientos.

5. Utilizar Lockdown (Linux Security Module)

Restringe los permisos de root para que, una vez comprometido y escalado un dispositivo, el atacante no comprometa el sistema de forma más profunda (limita acceso a /dev/mem, módulos del kernel, kexec, etc.).

6. Restringir dmesg

dmesg muestra mensajes del kernel que incluyen hardware detectado, módulos cargados, errores y, lo más importante, direcciones de memoria que los exploits pueden usar para evadir ASLR.

# Restricción efectiva
kernel.dmesg_restrict=1
# Verificación
sysctl kernel.dmesg_restrict

Práctica de Endurecimiento (checklist mínimo)

1. Activar Secure Boot con claves propias (MOK) y firmar bootloader/kernel.
2. Aplicar sysctl de endurecimiento (dmesg_restrict, kptr_restrict, SYN cookies, rp_filter).
3. Bloquear módulos con acceso DMA no utilizados (thunderbolt, uvcvideo, Bluetooth).
4. Evaluar kernel linux-hardened + Lockdown.
5. Elegir e implementar un LSM (AppArmor o SELinux) y perfilar los servicios.
6. Endurecer SSH, bindear bases de datos a localhost y aplicar cabeceras/TLS en web.
7. Cifrar por niveles: LUKS (bloque) → fscrypt/gocrypt (archivos) → GPG (sueltos) → borg/restic (backups).
8. Desplegar fail2ban/firehol/crowdsec y monitorización (aide, rsyslog, osquery/wazuh).
9. Mantener un régimen de actualizaciones (revisar PKGBUILD en AUR, parcheo automático en el resto).