Conceptos

Hardening de sistemas Linux

Actualizada el Jan 21, 2026

#auth#crypto#defense#endpoint#logging

Linux hardening es el conjunto de prácticas para reducir superficie de ataque, limitar el impacto de un compromiso y mejorar la detectabilidad en sistemas Linux mediante controles en capas…

Definición

Linux hardening es el conjunto de prácticas para reducir superficie de ataque, limitar el impacto de un compromiso y mejorar la detectabilidad en sistemas Linux mediante controles en capas: físico/arranque, cifrado, firewall, acceso remoto, cuentas/privilegios, servicios, actualizaciones y logging.

Contexto

Linux suele ser una opción robusta y costo-eficiente en servidores, pero no es “seguro por defecto”: hay que endurecerlo.
Principio guía: Defensa en profundidad. Si una capa falla, otra frena/detecta.
Objetivo práctico: que un atacante con acceso limitado (o un servicio expuesto) no pueda escalar fácilmente a root, moverse lateralmente o persistir sin dejar trazas.

Desarrollo (MIT-style)

1) Seguridad física y cadena de arranque

Por qué importa: con acceso físico se habilitan ataques de bajo coste y alto impacto (robo de discos, manipulación del arranque). En el RAW aparece la idea: “acceso al arranque = acceso root”.

Controles recomendados:

Control de acceso físico (rack/CPD, inventario, cadena de custodia).
Contraseña en BIOS/UEFI (útil en equipos personales; en servidores puede ser impráctico si requiere presencia física).
Contraseña en GRUB para bloquear edición de parámetros de arranque y evitar resets triviales de root.

GRUB password (práctico)

Herramienta: grub2-mkpasswd-pbkdf2 genera un hash PBKDF2.
El hash se añade a la configuración de GRUB según distro (ver referencias de Fedora/Ubuntu).

Limitaciones importantes:

En cloud/VMs gestionadas, GRUB password suele no aportar (no hay consola física en el mismo sentido).

2) Cifrado del sistema de archivos (LUKS)

Objetivo: que el robo de un disco/VM snapshot no equivalga a acceso a datos.

LUKS (resumen operativo):

Usa una clave maestra para cifrar datos.
La clave maestra se protege con slots de claves: cada slot guarda la master key cifrada con una passphrase distinta.
La passphrase se endurece con funciones de derivación (PBKDF2/Argon2id), lo que hace más costoso el brute force.

Buenas prácticas:

Diseñar la gestión de claves (quién conoce la passphrase, rotación, recuperación).
Considerar backups: cifrar backups y proteger llaves.
Evitar pérdidas operativas: si pierdes la clave, pierdes el dato.

Comandos típicos (alto nivel; laboratorio/controlado):

cryptsetup luksFormat /dev/<partition> (destructivo)
cryptsetup luksOpen /dev/<partition> <name>
cryptsetup luksDump /dev/<partition> (validación)

Conexión con criptografía:

Ver Cryptography Basics (PBKDF2, cifrado en bloque, modos).

3) Firewall en Linux: netfilter + frontends

Objetivo: controlar qué puede entrar y salir del host. Esto reduce exposición, dificulta backdoors (listeners) y limita C2.

En Linux, el filtrado lo soporta el kernel vía netfilter; se administra con frontends como:

iptables (clásico)
nftables (moderno, escalable)
ufw / firewalld (interfaces más simples)

Relacionado (nivel red): Secure Network Architecture and Segmentation.

Reglas típicas se basan en:

IP origen/destino
Puerto origen/destino
Estado de conexión (firewalls con estado)

Limitación destacada en el RAW:

Por defecto, el firewall decide por puerto, no por “aplicación”. Para granularidad por proceso/binario se complementa con SELinux/AppArmor (MAC).

Política (lo que hace que no sea “solo reglas”):

Default deny (bloquear todo y permitir excepciones) suele ser más seguro.
Default allow (permitir todo y bloquear excepciones) suele ser más cómodo, pero más riesgoso.

4) Acceso remoto seguro (SSH) y credenciales

Riesgos típicos:

Robo de contraseñas (protocolos sin cifrar: Telnet).
Adivinación/bruteforce contra SSH.
Explotación de servicios expuestos.

Controles recomendados (del RAW + buenas prácticas):

Evitar protocolos heredados (Telnet, TFTP) y usar alternativas seguras (SSH, SFTP).
En SSH:
- Deshabilitar login remoto de root (PermitRootLogin no).
- Preferir autenticación por clave pública (y deshabilitar password auth si el entorno lo permite).
- Mantener sshd actualizado.
Monitorizar intentos en logs (/var/log/auth.log o /var/log/secure).

5) Privilegios: sudo y root

Usa sudo para elevar privilegios con trazabilidad (quién hizo qué y cuándo).
Reduce exposición de root:
- Deshabilitar login interactivo directo (especialmente remoto).
- Minimizar cuentas con privilegios.

6) Política de contraseñas y cuentas

Objetivo: resistir guessing y reutilización.

Controles:

Política de contraseñas (ej.: pwquality.conf): longitud mínima, clases de caracteres, reintentos, etc.
Deshabilitar cuentas no usadas (cambiar shell a /sbin/nologin cuando corresponda).
En cuentas de servicio, usar shells no interactivos por defecto.

7) Superficie de ataque: software, servicios y puertos

Instalar solo lo necesario (menos paquetes = menos CVEs potenciales).
Deshabilitar servicios innecesarios.
Bloquear puertos innecesarios a nivel host firewall.
Evitar protocolos heredados.
Reducir información de fingerprinting (banners/version strings) cuando aplique.

8) Parches y ciclo de vida

Mantener paquetes al día (apt, dnf, yum).
Elegir distros con soporte prolongado:
- Ubuntu LTS (5 años + ESM).
- RHEL con ventanas largas de soporte.
No olvidar el kernel (ej.: vulnerabilidades tipo Dirty COW muestran que kernel desactualizado = riesgo de root).
Considerar actualizaciones automáticas en distros orientadas a estabilidad (evaluando impacto).

9) Auditoría y logging

Logs típicos en Linux (RAW):

/var/log/messages, /var/log/auth.log, /var/log/secure, /var/log/kern.log, /var/log/boot.log, etc.

Prácticas operativas:

Revisar y centralizar logs (SIEM si aplica).
Usar tail para últimas líneas y grep para buscar indicadores.
Proteger integridad/retención de logs.

Ejemplos

Ejemplo 1 — Endurecer SSH en un servidor expuesto

PermitRootLogin no
Deshabilitar password auth si usas llaves
Firewall: permitir solo 22/tcp desde IPs/admin networks (cuando sea posible)
Logging: alertas por intentos fallidos repetidos

Ejemplo 2 — Cifrar un disco extraíble con LUKS

Preparar partición
cryptsetup luksFormat (ojo: borra datos)
cryptsetup luksOpen + mkfs + mount
Verificar con cryptsetup luksDump

Pitfalls / Errores comunes

Confiar solo en “Linux es seguro” sin hardening.
Romper acceso remoto por reglas firewall mal probadas (no tener consola/plan de rollback).
Activar GRUB password sin proceso de recuperación.
Cifrar sin plan de gestión de claves (pérdida irreversible de datos).
Deshabilitar servicios sin entender dependencias (downtime).
Dejar logs sin revisar/centralizar (cero detección).
No actualizar kernel/paquetes (exposición a escaladas locales conocidas).

Diagrama

flowchart TD
  A[Seguridad física] --> B[Arranque/GRUB]
  B --> C[Cifrado LUKS]
  C --> D[Firewall host]
  D --> E[Acceso remoto seguro (SSH)]
  E --> F[Cuentas/privilegios (sudo)]
  F --> G[Servicios mínimos]
  G --> H[Parches + ciclo de vida]
  H --> I[Logging + auditoría]

  I -->|detección + respuesta| J[Mejora continua]

Checklist (si aplica)

Linux Hardening Checklist