7.1 Principios de Seguridad

tutorial.getReady

Entenderás el Principio del Privilegio Mínimo. - Sabrás por qué iniciar sesión como root está prohibido corporativamente. - Aprenderás la técnica LFCS para asegurar físicamente el servidor poniéndole candado a GRUB.

¡Excelente material! Vamos a refinar y desarrollar esta sección sobre Principios de Seguridad, aplicando la misma filosofía de mejora: más profundidad conceptual, ejemplos prácticos y checks más equilibrados.

7.1 Principios de Seguridad (Versión Mejorada)

1. La Filosofía “Zero Trust” (Confianza Cero)

El modelo de seguridad tradicional se basaba en un perímetro defensivo: un firewall robusto en el borde de la red, y todo lo que estuviera dentro de ese perímetro se consideraba “confiable”. Este modelo, conocido como seguridad de castillo y foso, asume que los atacantes están fuera y que los usuarios internos son benevolentes.

El problema en el mundo moderno:

Amenazas internas: Un empleado descontento o descuidado puede causar daños desde dentro.
Acceso remoto: VPNs, equipos personales y dispositivos móviles difuminan el perímetro.
Ataques avanzados: Un atacante puede comprometer un sistema interno (ej: mediante phishing) y moverse lateralmente, explotando la confianza ciega que los sistemas tienen entre sí.

Zero Trust se basa en el principio de “nunca confiar, siempre verificar”. No importa si una conexión proviene de la red interna o externa; cada solicitud de acceso debe ser autenticada, autorizada y continuamente validada.

Aplicación práctica en tu servidor Debian:

Segmentación: Aislar servicios en diferentes servidores o contenedores.
Autenticación continua: No basta con loguearse una vez; las sesiones deben re-autenticarse para acciones críticas (ej: usar sudo).
Mínimo privilegio: Dar solo los permisos estrictamente necesarios.
Registro y monitoreo: Asumir que las brechas ocurrirán; hay que detectarlas rápido.

2. El Principio del Mínimo Privilegio (PoLP - Principle of Least Privilege)

Este principio dicta que un usuario, proceso o sistema debe tener solo los permisos necesarios para realizar su función, y nada más.

Ejemplo práctico en un servidor web:

Usuario www-data: Debe poder leer los archivos del sitio web (/var/www/html/), pero no debería poder escribir en ellos (para prevenir modificaciones maliciosas).
Usuario de backups (backup_user): Debe poder leer archivos para hacer copias, pero no modificar datos ni ejecutar comandos del sistema.
Usuario de logs (log_reader): Debe poder leer /var/log/nginx/access.log, pero no debería poder leer /var/log/auth.log (que contiene información sensible de autenticación).

El error común de “privilegios excesivos”:

# MALA PRÁCTICA: Dar permisos de root o acceso total por comodidad
sudo usermod -aG sudo developer_user  # El desarrollador ahora tiene poder total
sudo chmod 777 /var/www/html/         # El servidor web ahora puede escribir y ejecutar todo

# BUENA PRÁCTICA: Conceder permisos granulares y específicos
sudo setfacl -m u:developer_user:rx /var/www/html/   # Solo lectura/ejecución
sudo setfacl -m u:deploy_user:rwx /var/www/html/     # Solo para el usuario de despliegue

¿Por qué es tan importante?

Contención de brechas: Si un atacante compromete una cuenta con mínimos privilegios, el daño está limitado.
Cumplimiento normativo: Regulaciones como GDPR, ISO 27001 o PCI-DSS exigen el control de acceso basado en el principio de mínimo privilegio.
Reducción de errores humanos: Un usuario con menos permisos tiene menos capacidad de cometer errores catastróficos (ej: borrar archivos críticos).

3. La Muerte del Inicio de Sesión Root

Tradicionalmente, los administradores de sistemas usaban la cuenta root para todo: acceder al servidor, instalar paquetes, modificar archivos del sistema, etc. Esto es extremadamente peligroso por varias razones:

1. Ataques de fuerza bruta SSH:

Los atacantes automáticos (bots) escanean Internet en busca de servidores SSH.
Saben que el usuario root existe en casi todos los sistemas Linux.
Sus diccionarios de contraseñas se centran en adivinar la contraseña de root. Si la adivinan, tienen control total inmediato.

2. Registro y auditoría:

Cuando usas sudo, todas tus acciones quedan registradas en /var/log/auth.log o journalctl con tu nombre de usuario. Esto permite auditar quién hizo qué.
Con root, todas las acciones se atribuyen a la misma cuenta anónima, dificultando la trazabilidad forense.

3. Riesgo de errores:

# Si estás logueado como root, un error tipográfico puede ser desastroso
rm -rf / var/log/  # (ESPACIO accidental entre / y var) - ¡BORRA TODO EL SISTEMA!
# En cambio, con sudo:
sudo rm -rf / var/log/  # También peligroso, pero al menos tienes que confirmar con sudo

La práctica recomendada (LFCS):

Deshabilitar el inicio de sesión root por SSH:

sudo nano /etc/ssh/sshd_config
# Buscar la línea: PermitRootLogin yes
# Cambiar a: PermitRootLogin no
sudo systemctl restart sshd

Crear usuarios normales con sudo:

sudo adduser <nombre usuario>
sudo usermod -aG sudo <nombre usuario>  # En Debian/Ubuntu, el grupo sudo da permisos de administración

Configurar sudo para requerir contraseña (ya es el comportamiento por defecto):
- Cada vez que ejecutes sudo, se te pedirá tu contraseña (la del usuario, no la de root).
- Esto añade una capa de autenticación y evita que un atacante ejecute comandos críticos sin saber tu contraseña.

4. Defensa Física Extrema: Candado a GRUB (Seguridad en el Arranque)

En el Módulo 4: Arranque, aprendiste una técnica de rescate: en el menú de GRUB, presionar e para editar los parámetros de arranque, añadir init=/bin/bash y obtener una shell de root sin contraseña. Esta es una herramienta salvavidas para administradores, pero también un grave vector de ataque físico.

El riesgo físico:

Un empleado despedido, un atacante con acceso físico o incluso un técnico de mantenimiento malicioso puede:
1. Reiniciar el servidor.
2. Interrumpir el arranque y presionar e.
3. Añadir init=/bin/bash o rd.break (en RHEL/CentOS).
4. Obtener una shell de root sin autenticación.
5. Modificar archivos, instalar backdoors, robar datos o destruir el sistema.

La solución (según el examen LFCS): Proteger GRUB con una contraseña.

Paso a Paso para Proteger GRUB (Guía Práctica)

1. Generar el Hash de la Contraseña:

El comando grub-mkpasswd-pbkdf2 genera un hash irrompible (PBKDF2) de tu contraseña.

grub-mkpasswd-pbkdf2
# Introduce la contraseña: (escribe tu contraseña, no se ve)
# Confirmar contraseña: (repítela)
# Salida: grub.pbkdf2.sha512.10000.9F9E5B2B... (COPIA ESTA CADENA COMPLETA)

2. Modificar el Archivo de Configuración de GRUB:

sudo nano /etc/grub.d/40_custom

Añade estas líneas al final del archivo:

set superusers="admin"  # Es el nombre de usuario que usarás para desbloquear GRUB
password_pbkdf2 admin grub.pbkdf2.sha512.10000.9F9E5B2B...  # Pega aquí tu hash

3. Asegurar que los Cambios se Apliquen al Arranque:

Editar el archivo de configuración no es suficiente; hay que generar el nuevo binario de arranque.

sudo update-grub

4. Verificar la Protección (Opcional pero Recomendado):

Reinicia el servidor y, en el menú de GRUB, presiona e para intentar editar una entrada. Verás que se te solicita:

Usuario: admin
Contraseña: (la que configuraste)

Sin estas credenciales, no podrás modificar los parámetros de arranque.

¿Qué pasa si se me olvida la contraseña de GRUB?

Desde el sistema (si ya estás dentro): Puedes regenerar el hash y modificar el archivo de nuevo.
Desde un Live CD/USB: Arranca desde un medio externo, monta la partición raíz, edita /etc/grub.d/40_custom y ejecuta update-grub desde el entorno chroot.
Medidas de emergencia: Algunos sistemas tienen un “superusuario” de GRUB con una contraseña de respaldo, pero esto es poco común.

Matices y Advertencias Importantes

set superusers="admin" vs set superusers="root": Puedes usar cualquier nombre de usuario. Usar root puede ser confuso porque es el mismo nombre que el usuario del sistema, pero son entidades completamente separadas (GRUB es un entorno previo al arranque del kernel).
Actualizaciones del kernel: Después de update-grub, el sistema seguirá arrancando normalmente, pero cualquier intento de editar el menú de GRUB requerirá autenticación.
¿Protege contra todo acceso físico?: No, si un atacante tiene acceso físico al servidor y puede abrir la carcasa, podría conectar un dispositivo de depuración (ej: JTAG) o extraer el disco duro. La protección de GRUB es una capa más en la defensa en profundidad.

5. Resumen de Buenas Prácticas de Seguridad LFCS

Práctica	Implementación	Beneficio
Zero Trust	Segmentación de red, autenticación continua, monitoreo constante	Limita el movimiento lateral de atacantes, incluso si comprometen un sistema interno.
Mínimo Privilegio	Usar `setfacl`, grupos específicos, evitar `chmod 777`	Contiene el daño en caso de compromiso de cuenta o proceso.
No Root por SSH	`PermitRootLogin no` en `/etc/ssh/sshd_config`	Obliga a los atacantes a adivinar dos credenciales (usuario + contraseña) en lugar de una sola.
Protección de GRUB	Configurar `superusers` y `password_pbkdf2` en `/etc/grub.d/40_custom` + `update-grub`	Previene ataques de escalada de privilegios mediante acceso físico al servidor.
Auditoría y Logs	Monitorear `/var/log/auth.log`, configurar `sudo` para registrar todas las acciones	Permite rastrear quién hizo qué y detectar actividades sospechosas.
Mantener el Sistema Actualizado	`sudo apt update && sudo apt upgrade` (o `unattended-upgrades` para automatizar)	Cierra vulnerabilidades conocidas en paquetes y el kernel.

Comprueba tus conocimientos (Versión Mejorada)

Contexto: Tu empresa ha adoptado una arquitectura de microservicios. Cada servicio se ejecuta en su propio contenedor, y todos los contenedores se comunican entre sí a través de una red interna. Un desarrollador propone que, para simplificar, todos los contenedores compartan el mismo usuario y permisos de archivo. ¿Cuál es tu objeción basada en los principios de seguridad modernos?
1. Esto viola el Principio del Mínimo Privilegio y la filosofía Zero Trust. Si un contenedor es comprometido (ej: a través de una vulnerabilidad en la aplicación), el atacante podría moverse lateralmente a otros contenedores que comparten los mismos permisos. Cada contenedor debe tener su propio usuario y permisos granulares.
2. Es aceptable si todos los contenedores están en la misma VLAN y el firewall de la red está bien configurado. La seguridad a nivel de red es suficiente para este escenario.
3. Es correcto, siempre que se use chroot dentro de cada contenedor para aislar el sistema de archivos. El aislamiento a nivel de sistema de archivos es la única capa de seguridad necesaria.
Contexto: Has seguido todos los pasos para proteger GRUB con contraseña: generaste el hash, lo añadiste a /etc/grub.d/40_custom y te fuiste a casa satisfecho. A la mañana siguiente, un técnico de mantenimiento intenta acceder al servidor en modo de recuperación presionando e en el menú de GRUB, y descubre que puede editar los parámetros sin que se le pida ninguna contraseña. ¿Qué ha fallado en tu procedimiento?
1. El hash generado con grub-mkpasswd-pbkdf2 es incompatible con la versión de GRUB instalada. Debes usar el algoritmo MD5 en su lugar.
2. Has olvidado ejecutar sudo update-grub después de editar el archivo de configuración. La edición del archivo de texto no modifica automáticamente el binario de arranque que GRUB lee al inicio. Sin ejecutar update-grub, los cambios no se aplican.
3. Debes reiniciar el servidor dos veces para que los cambios de GRUB se apliquen correctamente. Un solo reinicio no es suficiente para que el cargador de arranque lea la nueva configuración.
Contexto: Un nuevo administrador junior te dice: “Para facilitar el trabajo del equipo de desarrollo, he añadido a todos los desarrolladores al grupo sudo y he configurado sudo para que no pida contraseña. Así pueden instalar paquetes y reiniciar servicios sin interrupciones.” Según las prácticas de seguridad LFCS, ¿cómo evalúas esta decisión?
1. Es una violación grave del Principio del Mínimo Privilegio. Dar acceso sudo sin contraseña elimina cualquier barrera de autenticación para comandos críticos. Cualquier error tipográfico (o acción maliciosa) podría ser catastrófico. Además, la falta de solicitud de contraseña impide la auditoría efectiva de quién ejecutó qué comando.
2. Es aceptable en entornos de desarrollo, donde la agilidad es más importante que la seguridad. En producción, se puede revertir la configuración.
3. Es una buena práctica porque reduce la fricción para el equipo de desarrollo y mejora su productividad. El riesgo es mínimo si todos los desarrolladores son de confianza.