1. Fundamentos del control de acceso y modelos de identidad

El control de acceso constituye uno de los pilares fundamentales de la seguridad del sistema operativo Linux. En un entorno multiusuario, cada acción, proceso o recurso está asociado a una identidad digital representada por un usuario. Estos usuarios pueden ser personas, servicios o procesos del sistema.

Linux gestiona el acceso a recursos bajo el principio DAC (Discretionary Access Control) o Control de Acceso Discrecional, en el cual el propietario de un objeto (archivo, directorio, dispositivo, etc.) decide qué permisos se otorgan a otros usuarios o grupos. Este modelo es flexible, pero puede ser peligroso si no se combina con políticas estrictas de seguridad.

Principio de mínimo privilegio

Todo usuario o proceso debe tener únicamente los permisos necesarios para realizar su función, y nada más. Este principio limita el impacto de un error o compromiso de cuenta.

1.1. Tipos de usuarios en Linux

En Linux, los usuarios se clasifican en tres grandes grupos:

  1. Superusuario o root (UID 0): Tiene acceso total al sistema. Puede leer, modificar o eliminar cualquier archivo, y ejecutar cualquier comando sin restricciones.

    • El UID 0 identifica al superusuario.

    • Cualquier cuenta de usuario que tenga el UID 0 tiene los mismos privilegios que root, aunque se llame distinto. Por ejemplo, admin con UID 0.

    • Es un comportamiento programado a nivel de kernel: por defecto, un proceso con UID 0 recibe todas las capabilities y no está sujeto a las comprobaciones de permisos DAC. Este poder solo puede restringirse con mecanismos adicionales como la reducción de capabilities, los módulos de control de acceso obligatorio (SELinux, AppArmor) o los espacios de nombres de usuario.

    • Es recomendable evitar el acceso directo en el sistema como root y usar sudo para tareas administrativas puntuales.

  2. Usuarios del sistema (UID 1-999): Estos usuarios son creados automáticamente por el sistema o por servicios instalados como mysql, www-data o daemon.

    • No tienen acceso interactivo, por lo tanto, su shell suele ser /usr/sbin/nologin.

    • Se usan para aislar procesos y evitar que un servicio comprometido afecte a todo el sistema.

    • En Debian, los UID 1-99 se asignan de forma estática (paquete base-passwd) y los UID 100-999 se asignan dinámicamente a los servicios que se instalan. Este rango se define con los parámetros SYS_UID_MIN y SYS_UID_MAX de /etc/login.defs.

    • Existe una excepción conocida: el usuario nobody (UID 65534), que es una cuenta sin privilegios usada por algunos servicios aunque su UID sea mayor que 1000.

    • Aunque la convención actual es reservar los UID entre 0 y 999 para el sistema, cada distribución puede utilizar un rango diferente. A continuación se muestra una tabla de los valores utilizados en algunas distribuciones.

Distribución / Familia Rango de UID reservados para el sistema Descripción

Debian / Ubuntu

0 - 999

A partir de UID 1000 son usuarios normales.

Red Hat / CentOS / Fedora

0 - 999

Desde RHEL 7. En versiones antiguas (RHEL ≤ 6) el rango era 0 - 499 y los usuarios normales empezaban en el UID 500.

Arch Linux / Manjaro

0 - 999

Siguen la convención moderna.

SUSE / openSUSE

0 - 999

Igual que Debian.

Unix BSD / Solaris antiguos

0 - 99 o 0 - 499

Varía según versión. Algunos sistemas usan 100 para empezar los usuarios normales.

  1. Usuarios normales (UID ≥ 1000): Son las cuentas de personas que interactúan con el sistema.

    • Disponen de un directorio personal (/home/usuario).

    • Solo pueden acceder y modificar los recursos que les pertenecen.

    • Pueden hacer uso de un shell interactivo como /bin/bash o /bin/zsh.

    • Tienen un grupo principal con el mismo nombre que el usuario y, normalmente, un GID igual al UID (siempre que ese GID esté libre).

    • No tienen privilegios administrativos a menos que se les otorgue mediante sudo.

Los valores de UID_MIN y UID_MAX se configuran en el archivo /etc/login.defs. Puede consultar cuáles son los valores actuales del sistema con el siguiente comando:

grep -E '^UID_(MIN|MAX)' /etc/login.defs

El parámetro -E permite usar expresiones regulares con grep. En este caso, usamos el operador OR lógico | para buscar dos patrones.

En Ubuntu 24.04 LTS, la salida del comando anterior devolvería los siguientes valores:

UID_MIN 1000
UID_MAX 60000

1.2. El modelo User Private Groups (UPG)

En los sistemas UNIX tradicionales, existía un modelo en el que todos los usuarios comunes pertenecían por defecto al mismo grupo principal compartido, comúnmente llamado users, con GID 100. Este esquema planteaba problemas de privacidad, ya que si un usuario otorgaba permisos de lectura o escritura a su grupo en un archivo, cualquier otro usuario del sistema podía acceder a él o modificarlo.

Para solventar esta debilidad, las distribuciones Linux modernas implementan de forma predeterminada el esquema UPG (User Private Group), que consiste en:

  1. Grupo exclusivo por usuario: Cada vez que se crea un nuevo usuario, el sistema crea automáticamente un grupo privado con su mismo nombre y, si está disponible, un GID idéntico a su UID.

  2. Aislamiento por defecto: El usuario es el único miembro de su grupo principal, garantizando que sus archivos personales nunca queden expuestos inadvertidamente a otros usuarios a través del grupo.

  3. Flexibilidad para el trabajo en equipo: Si varios usuarios necesitan colaborar en un proyecto compartido, el administrador no necesita alterar sus grupos principales, basta con crear un grupo secundario específico y asignarles acceso a un directorio de trabajo común.

En el siguiente bloque (Permisos y control de acceso básico) se estudiará en detalle cómo se configuran los permisos de grupo, la máscara umask y el permiso especial SetGID para habilitar el trabajo colaborativo en carpetas compartidas.

Este comportamiento está regulado en /etc/login.defs mediante la directiva:

USERGROUPS_ENAB yes

Si esta opción está establecida en yes, cuando se elimina un usuario con el comando userdel, el sistema también eliminará automáticamente su grupo privado si este no tiene más miembros.

2. Archivos esenciales de cuentas y seguridad de credenciales

Linux utiliza varios archivos de texto plano ubicados en el directorio /etc que constituyen la base de la autenticación local:

Archivo Función principal Permisos recomendados

/etc/passwd

Contiene información básica sobre las cuentas (nombre, UID, GID principal, directorio personal y shell).

644 (root:root)

/etc/shadow

Almacena los hashes de las contraseñas y las directivas temporales de caducidad.

640 (root:shadow)

/etc/group

Define los grupos del sistema y sus listas de miembros secundarios.

644 (root:root)

/etc/gshadow

Almacena las contraseñas de grupo y los administradores delegados de cada grupo.

640 (root:shadow)

2.1. Archivo /etc/passwd

Es un archivo de texto plano accesible por todos los usuarios del sistema (permisos 644), ya que muchas herramientas y utilidades necesitan traducir UIDs numéricos a nombres de usuario legibles.

2.1.1. Estructura

Cada línea representa una cuenta de usuario y está dividida en siete campos separados por dos puntos (:):

usuario:contraseña:UID:GID:descripción:directorio_personal:shell

2.1.2. Campos principales

Campo Descripción Ejemplo Explicación técnica

usuario

Nombre de la cuenta

maria

Identificador de inicio de sesión (login). En sistemas modernos sigue las convenciones POSIX (minúsculas, dígitos, guion y guion bajo).

contraseña

Puntero de autenticación

x

En sistemas con contraseñas ocultas (shadow passwords), este campo siempre contiene una x. Indica que el hash real de la contraseña reside en /etc/shadow.

UID

Identificador numérico de usuario

1001

Número único asignado al usuario. El valor 0 está reservado a root.

GID

Identificador del grupo principal

1001

GID numérico del grupo principal del usuario, definido en /etc/group. Con UPG suele coincidir con el UID.

descripción

Campo de información GECOS

Maria Garcia

Campo de texto libre para el nombre real, departamento, teléfono o ubicación. Puede modificarse con chfn.

directorio_personal

Ruta del directorio personal

/home/maria

Directorio de inicio del usuario tras autenticarse con éxito. Las cuentas de servicio suelen apuntar a /var/lib/…​ o /nonexistent.

shell

Intérprete de comandos

/bin/bash

Programa ejecutado al iniciar sesión interactiva. Si contiene /usr/sbin/nologin o /bin/false, el usuario no puede iniciar sesión interactiva.

2.1.3. Ejemplo

Podemos inspeccionar una entrada de /etc/passwd mediante grep:

grep '^maria:' /etc/passwd
maria:x:1001:1001:Maria Garcia:/home/maria:/bin/bash       (1) (2) (3) (4) (5) (6) (7)
1 Nombre de usuario.
2 Contraseña delegada en /etc/shadow.
3 UID del usuario.
4 GID de su grupo principal.
5 Comentario o campo GECOS.
6 Directorio personal asignado.
7 Intérprete de comandos inicial.

2.2. Archivo /etc/shadow y seguridad de credenciales

Históricamente, los hashes de las contraseñas se almacenaban en el segundo campo de /etc/passwd. Dado que este fichero debe ser legible por cualquier proceso, cualquier usuario local podía extraer los hashes e intentar descifrarlos mediante ataques de fuerza bruta o diccionario. Para resolver este riesgo se introdujo /etc/shadow, accesible únicamente por el superusuario y por procesos autorizados.

Hash no es lo mismo que cifrado

Es habitual leer que las contraseñas se guardan “cifradas”, pero técnicamente no es correcto:

  • Cifrado: Es una transformación reversible. Con la clave adecuada se recupera el texto original.

  • Hash: Es una función criptográfica unidireccional. No existe ninguna clave que permita recuperar la contraseña original a partir del resultado.

Para verificar una contraseña en el inicio de sesión, el sistema aplica la misma función de hashing con la sal almacenada a lo que escribe el usuario y compara el resultado con el hash de /etc/shadow. Si coinciden, el acceso se concede.

La sal (salt) es una cadena aleatoria generada por el sistema que se concatena a la contraseña antes de calcular el hash. Cumple dos objetivos de seguridad vitales:

  1. Impide el uso de tablas precalculadas (rainbow tables), ya que el atacante tendría que calcular una tabla distinta para cada sal posible.

  2. Garantiza que dos usuarios con la misma contraseña tengan hashes completamente distintos en el archivo.

Lecturas recomendadas

Los siguientes artículos permiten profundizar en el concepto de sal criptográfica y en las directrices de almacenamiento seguro de contraseñas:

2.2.1. Estructura de /etc/shadow

Cada línea contiene nueve campos separados por dos puntos (:):

usuario:contraseña:lastchange:min:max:warn:inactive:expire:reserved
Campo Descripción Ejemplo Explicación técnica

usuario

Nombre de la cuenta

maria

Debe coincidir exactamente con una entrada existente en /etc/passwd.

contraseña

Hash de la contraseña

$y$j9T$WOMmh…​

Contiene el algoritmo, la sal y el hash. Si contiene ! o *, la autenticación por contraseña está deshabilitada (ver apartado 3.6).

lastchange

Fecha del último cambio

20378

Número de días transcurridos desde el 1 de enero de 1970 (epoch time). Puede convertirse a fecha legible con date -d "1970-01-01 +20378 days".

min

Días mínimos entre cambios

7

Días que deben transcurrir antes de que el usuario pueda cambiar su contraseña de nuevo. Evita que un usuario burle el historial de contraseñas cambiándola muchas veces seguidas.

max

Días máximos de validez

90

Periodo máximo tras el cual la contraseña debe renovarse obligatoriamente.

warn

Días de aviso previo

14

Antelación con la que el sistema comienza a advertir al usuario de la inminente expiración al iniciar sesión.

inactive

Días de inactividad tras expiración

30

Días de gracia tras expirar la contraseña antes de desactivar la cuenta por completo.

expire

Fecha de expiración absoluta

20999

Fecha en formato de días desde 1970 en que la cuenta deja de funcionar, independientemente de la contraseña.

reserved

Campo reservado

vacío

Reservado para usos futuros.

2.2.2. Formato de registro y prefijos de algoritmos de hash

El campo de contraseña contiene el hash y los metadatos del algoritmo utilizado conforme a la estructura general:

$id$params$salt$hash

Donde cada segmento cumple un propósito específico:

  • $id: Identifica el algoritmo de hash empleado en la derivación.

  • $params: Parámetros de coste del algoritmo. Aparecen de forma obligatoria en yescrypt para fijar la dificultad de CPU y memoria, y de forma opcional en SHA-256 o SHA-512 mediante la directiva rounds=N para incrementar las iteraciones sobre el valor estándar de 5000.

  • $salt: Cadena aleatoria única que individualiza el cálculo y evita la reutilización de ataques precalculados.

  • $hash: Cadena final resultante de aplicar la función criptográfica unidireccional.

La familia de algoritmos bcrypt emplea una variante de este formato ($2b$coste$<sal+hash>), en la que tras el coste se sitúan 53 caracteres consecutivos: los 22 primeros corresponden a la sal y los restantes al hash, sin un delimitador explícito entre ambos.

En las funciones de hashing para contraseñas, la rapidez de cómputo constituye una debilidad. Cuanto más veloz es el cálculo de un hash, mayor es la cantidad de combinaciones por segundo que un atacante puede evaluar en ataques de fuerza bruta o diccionario. Por este motivo, los algoritmos modernos se diseñan deliberadamente para ser lentos y demandantes de recursos del sistema.

A continuación se resumen los prefijos más habituales que identifican al algoritmo en el segundo campo de /etc/shadow:

Prefijo Algoritmo Estado de seguridad

$y$

yescrypt

Recomendado por defecto en Debian 11, Debian 12 (Bookworm), Ubuntu 22.04 LTS y distribuciones recientes de Fedora. Resistente a ataques masivos con GPU (ver apartado 6.1).

$6$

SHA-512

Estándar robusto anterior. Seguro, aunque más vulnerable a aceleración por hardware que yescrypt.

$5$

SHA-256

Seguro, sustituido progresivamente por SHA-512 y yescrypt.

$2b$ / $2y$

bcrypt

Muy seguro, basado en el cifrador Blowfish. Habitual en entornos BSD y aplicaciones web.

$1$

MD5

Obsoleto e inseguro. Vulnerable a colisiones y ataques de fuerza bruta ultrarrápidos.

Vacío (::)

Sin contraseña

Riesgo crítico. Permite el inicio de sesión local sin ninguna autenticación.

2.2.3. Herramientas relacionadas con /etc/shadow

Comando Descripción Ejemplo de auditoría o configuración

passwd

Cambia o consulta el estado de contraseñas.

sudo passwd -S maria

pwck -r

Comprueba la coherencia y permisos de /etc/passwd y /etc/shadow en modo solo lectura.

sudo pwck -r

vipw -s

Edita de forma segura /etc/shadow bloqueándolo para impedir accesos simultáneos que corrompan el fichero.

sudo vipw -s

2.3. Archivos de grupos: /etc/group y /etc/gshadow

Los grupos permiten organizar a los usuarios por funciones, departamentos o niveles de acceso a recursos:

grupo:contraseña:GID:miembros

  1. /etc/group (permisos 644 root:root):

    • grupo: Nombre del grupo (ej. soporte).

    • contraseña: Marcador x que indica delegación en /etc/gshadow.

    • GID: Identificador numérico del grupo.

    • miembros: Lista de usuarios secundarios separados por comas. El usuario cuyo grupo principal coincide con el GID no necesita figurar en esta lista.

  2. /etc/gshadow (permisos 640 root:shadow):

    • Contiene contraseñas de grupo y la lista de administradores de grupo que pueden gestionar miembros con gpasswd sin necesidad de privilegios de root (ver apartado 4.2).

    • Se edita de forma segura mediante sudo vigr -s.

2.4. Permisos críticos y copias de seguridad (CIS)

Las utilidades de cuentas (useradd, usermod, passwd, etc.) crean copias de seguridad automáticas con sufijo de guion (-) al efectuar cambios. El CIS Benchmark exige que estas copias se protejan con el mismo rigor que los archivos originales:

sudo chmod 644 /etc/passwd /etc/passwd- /etc/group /etc/group-
sudo chown root:root /etc/passwd /etc/passwd- /etc/group /etc/group-
sudo chmod 640 /etc/shadow /etc/shadow- /etc/gshadow /etc/gshadow-
sudo chown root:shadow /etc/shadow /etc/shadow- /etc/gshadow /etc/gshadow-

Con los conceptos explicados en este capítulo sobre los archivos de cuentas, formatos de hash, sal y algoritmos, ya puede realizar:

3. Ciclo de vida y bastionado de cuentas de usuario

La administración segura de identidades abarca el ciclo de vida completo de cada cuenta: creación controlada, asignación de plantillas, auditoría de permisos, mantenimiento de atributos, políticas de caducidad y baja segura sin dejar rastros residuales.

3.1. Creación de usuarios: bajo y alto nivel

En sistemas GNU/Linux coexisten dos herramientas principales para dar de alta cuentas:

  • useradd (bajo nivel): Binario estándar disponible en todas las distribuciones Linux. Es ideal para scripts y automatizaciones porque opera exactamente según los parámetros especificados, sin formular preguntas interactivas. En Debian y Ubuntu no crea el directorio personal salvo que se indique explícitamente con la opción -m.

  • adduser (alto nivel): Script interactivo presente en Debian, Ubuntu y derivadas. Guía al administrador paso a paso, solicita la contraseña, crea el directorio personal con permisos seguros y aplica la plantilla /etc/skel de forma automática. En Red Hat y Fedora, adduser es simplemente un enlace simbólico a useradd.

3.1.1. Opciones principales de useradd

Parámetro Función Ejemplo de uso

-m

Crea el directorio personal si no existe.

sudo useradd -m juan

-s

Define el intérprete de comandos (shell).

sudo useradd -s /bin/bash juan

-c

Añade información en el campo GECOS o comentario.

sudo useradd -c "Auditor Externo" juan

-d

Especifica una ruta personalizada para el directorio personal.

sudo useradd -d /var/www/app juan

-e

Fija una fecha de expiración absoluta (AAAA-MM-DD).

sudo useradd -e 2027-06-30 juan

-f

Días de gracia tras caducar la clave antes de desactivar la cuenta.

sudo useradd -f 30 juan

-r

Crea una cuenta del sistema (UID en rango SYS_UID_MIN-SYS_UID_MAX).

sudo useradd -r appsvc

-M

Fuerza a no crear el directorio personal (útil en servicios).

sudo useradd -r -M appsvc

3.1.2. Creación segura de cuentas de servicio

Las cuentas que ejecutan servicios del sistema (como bases de datos o servidores web) nunca deben tener acceso interactivo ni directorios innecesarios:

sudo useradd -r -M -d /var/lib/appsvc -s /usr/sbin/nologin -c "Servicio de aplicacion" appsvc

Esta directiva garantiza que el UID pertenezca al rango de sistema, que no se cree un directorio en /home y que el intérprete impida el inicio de sesión interactivo con el mensaje «This account is currently not available».

3.2. Valores predeterminados y plantillas globales

Cuando useradd se invoca sin parámetros específicos, aplica la configuración por defecto definida en /etc/default/useradd y en /etc/login.defs:

useradd -D

Salida de ejemplo:

GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/sh
SKEL=/etc/skel
CREATE_MAIL_SPOOL=no

Para modificar estas directivas de forma persistente, el administrador puede utilizar useradd -D acompañado de las banderas correspondientes, por ejemplo: sudo useradd -D -f 30 para fijar 30 días de inactividad máxima tras expiración de contraseña.

3.2.1. El directorio plantilla /etc/skel

Cuando se crea un nuevo usuario con la opción -m, el sistema copia en su directorio personal todos los archivos y carpetas contenidos en /etc/skel, asignándoles como propietario al nuevo usuario. Permite estandarizar configuraciones de inicio (.bashrc, .profile) y definir máscaras de creación restrictivas (umask 027).

/etc/skel no impone políticas globales ni es retroactivo

  1. Sus archivos solo se copian al crear la cuenta: modificar /etc/skel no afecta a las cuentas ya existentes.

  2. Los archivos copiados pertenecen al usuario, quien puede modificarlos o eliminarlos libremente desde su terminal.

Para imponer directivas obligatorias e inmutables que los usuarios no puedan eludir, deben emplearse mecanismos globales del sistema: la directiva UMASK de /etc/login.defs o scripts de solo lectura en /etc/profile.d/ (ver apartado 7.2).

3.3. Permisos del directorio personal (/home) y directivas CIS

Uno de los fallos de configuración más frecuentes en auditorías de seguridad radica en los permisos asignados a los directorios de los usuarios en /home.

3.3.1. El riesgo del modo permisivo 755

Históricamente, muchas distribuciones creaban los directorios personales con modo 755 (drwxr-xr-x). Con esta configuración, cualquier usuario local no privilegiado puede ingresar al directorio de otro usuario y leer sus archivos personales, proyectos y documentos confidenciales si estos conservan permisos de lectura global.

3.3.2. Configuración segura según CIS Benchmark (750 o 700)

Las directrices del CIS Benchmark exigen que los directorios personales no otorguen permisos de acceso a “otros”:

  • Modo 750 (drwxr-x---): Solo el propietario y los miembros de su grupo pueden acceder; el resto de usuarios del sistema tiene el acceso totalmente denegado.

  • Modo 700 (drwx------): Acceso exclusivo para el propietario.

Bajo el modelo UPG (ver apartado 1.2), el grupo principal de cada usuario solo lo contiene a él mismo, por lo que en la práctica 750 y 700 proporcionan idéntico nivel de aislamiento entre usuarios normales.

Para garantizar que todos los nuevos usuarios se creen con permisos restrictivos, se deben configurar las siguientes directivas:

  1. En /etc/login.defs (para useradd):

    HOME_MODE 0750

  2. En /etc/adduser.conf (para adduser en Debian y Ubuntu):

    DIR_MODE=0750

3.3.3. Auditoría y remediación de directorios existentes

Para auditar y corregir directorios personales preexistentes que presenten permisos demasiado permisivos:

# Auditar directorios accesibles por el grupo o por otros
sudo find /home -maxdepth 1 -mindepth 1 -type d -perm /027 -ls

# Corregir permisos masivamente a 750
sudo find /home -maxdepth 1 -mindepth 1 -type d -exec chmod 750 {} +

3.4. Modificación de cuentas y control de intérpretes

El comando usermod permite actualizar cualquier atributo de una cuenta existente sin necesidad de recrearla:

  • Modificar directorio personal y mover contenido: bash sudo usermod -d /home/nuevo -m usuario

  • Cambiar el nombre de usuario (login): bash sudo usermod -l nuevo_nombre antiguo_nombre

  • Añadir a grupos secundarios: ```bash sudo usermod -aG docker,soporte usuario ````

Atención al modificar grupos con usermod

Es imprescindible incluir la opción -a (append) junto con -G. Si se ejecuta usermod -G grupo usuario omitiendo -a, el usuario será eliminado de todos los grupos secundarios a los que perteneciera previamente y que no figuren en la nueva lista.

3.4.1. Cambio de intérprete y seguridad de /etc/shells

El comando chsh (change shell) permite a los usuarios modificar su propia shell. Sin embargo, los usuarios sin privilegios solo pueden elegir intérpretes que figuren explícitamente en el archivo /etc/shells.

Riesgo de seguridad en /etc/shells

Bajo ninguna circunstancia deben añadirse /usr/sbin/nologin ni /bin/false a /etc/shells. Servicios como servidores FTP (vsftpd) o módulos PAM consultan /etc/shells para autorizar el acceso. Si se incluye nologin en la lista de shells válidas, una cuenta bloqueada para acceso interactivo pero con contraseña válida podría autenticarse indebidamente en dichos servicios de red.

3.5. Políticas de caducidad y expiración con chage

La herramienta chage (change age) gestiona la vigencia de las contraseñas y la expiración automática de las cuentas:

Parámetro Propósito Ejemplo práctico Descripción

-l

Listar estado

sudo chage -l maria

Muestra la configuración completa de caducidad y expiración.

-M

Días máximos de validez

sudo chage -M 90 maria

Establece el periodo máximo tras el cual la contraseña debe cambiarse.

-m

Días mínimos entre cambios

sudo chage -m 1 maria

Impide cambios consecutivos en menos de 24 horas para eludir historiales de claves.

-W

Aviso previo

sudo chage -W 7 maria

Días previos a la expiración en que el usuario recibe alertas al iniciar sesión.

-I

Inactividad postcaducidad

sudo chage -I 30 maria

Días de gracia tras expirar la contraseña antes de desactivar la cuenta por completo.

-E

Fecha de expiración de cuenta

sudo chage -E 2027-06-30 maria

Fija la fecha en que la cuenta queda bloqueada de forma absoluta. Con -E -1 se elimina la expiración.

-d 0

Forzar cambio inmediato

sudo chage -d 0 maria

Marca la fecha de último cambio a 0, forzando a cambiar la clave en el próximo inicio de sesión.

Políticas corporativas: CIS frente a NIST SP 800-63B

El CIS Benchmark exige tradicionalmente rotación periódica forzada de contraseñas, por ejemplo, cada 90 o 365 días. Sin embargo, la guía NIST SP 800-63B desaconseja la rotación periódica arbitraria, ya que induce a los usuarios a seleccionar patrones previsibles (Verano2025!, Verano2026!). NIST recomienda priorizar la longitud (mínimo 15 caracteres), verificar contraseñas contra listas de credenciales comprometidas y forzar el cambio únicamente ante indicios reales de compromiso.

3.6. Bloqueo integral y baja segura de usuarios

El procedimiento para deshabilitar o eliminar una cuenta debe seguir pautas estrictas para no dejar brechas de acceso ni recursos huérfanos.

3.6.1. Bloqueo parcial frente a bloqueo completo

Existen dos niveles de bloqueo que conviene diferenciar claramente:

# Bloqueo parcial (solo contraseña)
sudo passwd -l maria

# Bloqueo completo de cuenta (CIS Benchmark)
sudo usermod -L -e 1 maria

La trampa del bloqueo con passwd -l

El comando passwd -l (o usermod -L) se limita a anteponer un carácter de exclamación (!) al hash en /etc/shadow. Esto deshabilita la autenticación por contraseña, pero no bloquea la cuenta. Si el usuario dispone de claves públicas configuradas en ~/.ssh/authorized_keys, en Debian y Ubuntu (UsePAM yes) podrá seguir iniciando sesión por SSH sin ningún impedimento.

Para revocar el acceso de forma absoluta se debe hacer expirar la cuenta con usermod -L -e 1 (estableciendo la fecha de expiración en el 2 de enero de 1970). Con este parámetro, PAM rechaza cualquier método de autenticación, incluidas las llaves SSH, con el mensaje «Your account has expired».
Comparativa de mecanismos: Bloqueo parcial frente a Bloqueo integral
Figura 1. Comparativa de mecanismos: Bloqueo parcial frente a Bloqueo integral

Para reactivar una cuenta completamente bloqueada:

sudo usermod -U -e "" maria
Auditoría de cuentas bloqueadas o deshabilitadas con awk

Para auditar y detectar las cuentas del sistema que se encuentran deshabilitadas o bloqueadas en /etc/shadow, el administrador puede utilizar el siguiente comando:

sudo awk -F: '$2 ~ /^(\*|!)/ {print $1 " -> Cuenta bloqueada"}' /etc/shadow

A continuación se detalla la función técnica de cada uno de los elementos que componen el comando anterior:

Elemento Significado y función técnica

sudo

Ejecuta el comando con privilegios administrativos, indispensables para acceder a /etc/shadow.

awk

Herramienta de procesamiento y filtrado de texto estructurado por columnas.

-F:

Establece los dos puntos (:) como delimitador de campos en la lectura de registros.

$2

Apunta al segundo campo de cada registro, correspondiente al hash o al estado de la contraseña.

~

Operador de correspondencia que evalúa si el valor coincide con el patrón de la expresión regular (expresión ~ /patrón/).

/^(\*|!)/

Expresión regular que detecta si el campo comienza por asterisco (*) o signo de exclamación (!), identificando cuentas de servicio deshabilitadas (*, !, !!) o contraseñas bloqueadas con passwd -l cuyo hash comienza por !.

{print $1 " -> Cuenta bloqueada"}

Bloque de acción que imprime el nombre de usuario ($1) junto con el texto descriptivo si se cumple el patrón.

/etc/shadow

Archivo del sistema sobre el que se efectúa la consulta.

Referencias

En los siguientes enlaces puede encontrar más información sobre la utilidad awk y expresiones regulares:

3.6.2. Procedimiento de baja segura y prevención de archivos huérfanos

Antes de invocar userdel, el administrador debe ejecutar las siguientes comprobaciones preventivas:

  1. Terminar procesos y sesiones activas:

    who | grep maria
pgrep -u maria
sudo pkill -u maria
sudo crontab -u maria -r 2>/dev/null

  2. Hacer copia de seguridad y rastrear archivos:

    sudo tar -czvf /backup/maria_backup.tar.gz /home/maria
sudo find / -xdev -user maria -ls 2>/dev/null

  3. Eliminar la cuenta y su directorio:

    sudo userdel -r maria

Peligro de reutilización de UID y archivos huérfanos

Al eliminar una cuenta con userdel, los archivos que pertenecieran al usuario fuera de /home conservan su UID numérico, pero quedan como archivos huérfanos al no existir ya ese UID en /etc/passwd.

El comando useradd asigna por defecto el siguiente UID correlativo libre. Por consiguiente, el próximo usuario que reciba el UID del usuario eliminado se convertirá automáticamente en propietario de todos sus archivos huérfanos. Por este motivo es imperativo rastrear y reasignar o eliminar los archivos huérfanos antes de asignar ese UID a otra persona:

sudo find / -xdev \( -nouser -o -nogroup \) -ls 2>/dev/null

Con los procedimientos del ciclo de vida de usuarios explicados en este capítulo, ya puede realizar:

4. Gestión de grupos y colaboración

La administración de grupos permite organizar usuarios por departamentos, proyectos o niveles de acceso sin necesidad de compartir cuentas.

4.1. Ciclo de vida de grupos: creación, modificación y borrado

4.1.1. Crear grupos: groupadd

sudo groupadd proyectos
sudo groupadd -g 1050 desarrollo

  • -g: Asigna un GID numérico específico.

  • -r: Crea un grupo del sistema (GID inferior a 1000).

En Debian y Ubuntu también está disponible el script addgroup soporte.

4.1.2. Modificar grupos: groupmod

Permite actualizar las propiedades de un grupo existente:

# Cambiar el nombre del grupo
sudo groupmod -n seguridad proyectos

# Cambiar el GID
sudo groupmod -g 1100 seguridad

Atención al modificar el GID

El comando groupmod -g actualiza /etc/group, pero no altera los archivos existentes en el sistema de ficheros. Los archivos que pertenecían al grupo conservan el GID antiguo y quedan huérfanos de grupo. El administrador debe actualizar manualmente la propiedad con find:

sudo find / -xdev -gid 1050 -exec chgrp seguridad {} +

4.1.3. Eliminar grupos: groupdel

sudo groupdel seguridad

El comando groupdel no permite eliminar el grupo principal de ningún usuario existente (groupdel: cannot remove the primary group of user '…​'). Para poder borrarlo, primero se debe reasignar el grupo principal del usuario afectado (con usermod -g) o dar de baja a dicho usuario.

4.2. Delegación administrativa con gpasswd

El comando gpasswd es la utilidad asociada a /etc/gshadow. Permite gestionar membresías y delegar la administración de un grupo en usuarios específicos sin otorgarles privilegios de root:

Comando Acción realizada

sudo gpasswd -a usuario grupo

Añade un usuario al grupo secundario.

sudo gpasswd -d usuario grupo

Elimina a un usuario del grupo (revocación inmediata).

sudo gpasswd -M u1,u2,u3 grupo

Define la lista completa de miembros, sustituyendo la anterior.

sudo gpasswd -A usuario grupo

Nombra a un usuario administrador del grupo en /etc/gshadow.

sudo gpasswd -r grupo

Elimina la contraseña del grupo.

Un usuario nombrado administrador de un grupo con gpasswd -A puede ejecutar gpasswd -a y gpasswd -d sobre su propio grupo sin invocar sudo. Esto permite que responsables de proyecto gestionen quién accede a sus carpetas compartidas sin comprometer la seguridad global del sistema.

Las contraseñas de grupo permitían antiguamente que un usuario se uniera temporalmente a un grupo con newgrp mediante una clave compartida. Hoy se consideran una mala práctica contraria a la trazabilidad y están en desuso.

4.3. Trabajo colaborativo y consistencia de grupos

Para consultar las membresías de un usuario se utilizan las utilidades estándar:

id juan
groups juan

Los cambios de grupo no afectan a las sesiones abiertas

La lista de grupos de un proceso se calcula en el momento exacto de iniciar sesión. Si se añade o retira a un usuario de un grupo, el cambio no tendrá efecto en sus terminales activas. El usuario debe cerrar su sesión y volver a entrar (o ejecutar newgrp nombre_grupo) para que el kernel actualice los privilegios de su proceso. Del mismo modo, si se revoca la membresía de un usuario, sus sesiones abiertas conservarán los permisos hasta que se cierren.

Con las operaciones de administración de grupos y delegación con gpasswd, ya puede realizar:

5. Privilegios administrativos y delegación con sudo

El principio de mínimo privilegio exige erradicar el trabajo cotidiano mediante la cuenta directa de root. La delegación controlada con sudo (superuser do) permite conceder permisos granulares y auditar de forma fehaciente quién ejecuta qué acción en el sistema.

5.1. El riesgo del superusuario directo

Iniciar sesión directamente como root presenta graves deficiencias de seguridad:

  • Pérdida de trazabilidad e imputabilidad: Si varias personas conocen la contraseña de root, es imposible determinar quién ejecutó una acción indebida o destructiva.

  • Impacto catastrófico de errores: Cualquier error tipográfico en comandos con privilegios totales puede corromper el sistema de ficheros de forma irreversible.

  • Violación de cumplimiento: Normativas como PCI-DSS, ISO 27001 y el Esquema Nacional de Seguridad (ENS) prohíben el uso compartido de cuentas con privilegios de superusuario.

5.2. Auditoría exhaustiva de grupos privilegiados

La asignación de grupos secundarios en Linux requiere un control riguroso. Determinados grupos conceden control administrativo total sobre el sistema, mientras que otros proporcionan acceso a información confidencial que puede facilitar vectores de ataque indirectos o auditorías no autorizadas.

5.2.1. Grupos con acceso administrativo total o escalada directa a root

Pertenecer a estos grupos permite tomar el control completo del sistema o ejecutar comandos con privilegios de superusuario:

Grupo Mecanismo y vector de riesgo

sudo / wheel

Concede privilegios de superusuario a través del comando sudo, siempre que esté habilitada la directiva correspondiente en /etc/sudoers (%sudo en Debian y Ubuntu; %wheel en la familia Red Hat). A diferencia de otros mecanismos, exige autenticación por defecto y registra los comandos ejecutados.

docker

En la instalación tradicional con demonio centralizado (rootful), el demonio se ejecuta como root. Pertenecer al grupo docker permite comunicarse con /var/run/docker.sock y desplegar contenedores que monten la raíz del anfitrión (por ejemplo: docker run -v /:/mnt --rm -it alpine chroot /mnt /bin/sh), lo que concede acceso total al sistema de ficheros sin solicitar contraseña ni registrarse en sudo. Este riesgo no aplica si Docker está configurado en modo rootless (ver apartado 6.2), ya que en ese caso no se emplea el grupo del sistema y las operaciones quedan contenidas en el espacio de nombres del usuario.

lxd / incus-admin

Concede control sobre el demonio de contenedores a través de su socket local. Permite crear contenedores privilegiados (security.privileged=true) y montar el sistema de ficheros del anfitrión en el contenedor. En Incus, el grupo administrativo es incus-admin, mientras que el grupo incus está restringido a proyectos delegados.

disk

Otorga acceso directo de lectura y escritura a los dispositivos de almacenamiento en bloque (/dev/sd*, /dev/nvme*, /dev/vd*). Permite eludir todos los permisos DAC del sistema de ficheros, leer cualquier dato en crudo o alterar particiones mediante utilidades como debugfs.

staff

En distribuciones Debian y Ubuntu, otorga permisos de escritura en /usr/local/bin y /usr/local/sbin. Dado que estas rutas suelen figurar antes que /usr/bin en la variable PATH del superusuario, un miembro de este grupo puede suplantar binarios del sistema para que root los ejecute inadvertidamente.

5.2.2. Grupos con acceso a información confidencial y auditoría

Estos grupos no permiten la ejecución directa de comandos administrativos, pero exponen datos sensibles que comprometen la confidencialidad del sistema:

Grupo Información expuesta y riesgo operacional

shadow

Permite la lectura de /etc/shadow y /etc/gshadow. Expone los hashes de las contraseñas de todas las cuentas del sistema, facilitando ataques de descifrado fuera de línea (offline cracking).

adm

Otorga permisos de lectura sobre los archivos de registro tradicionales en /var/log (como syslog o auth.log). Puede revelar información sensible, direcciones IP de origen, nombres de cuenta o credenciales registradas accidentalmente por aplicaciones.

systemd-journal

Permite consultar la totalidad de los registros del diario de systemd mediante journalctl, exponiendo eventos de auditoría y mensajes de los servicios del sistema.

input

Concede acceso de lectura a los dispositivos de eventos en /dev/input/event*, lo que permite capturar eventos de teclado a modo de keylogger local para interceptar credenciales en texto plano.

Alternativa segura al grupo docker: adopción de Podman o modo rootless

Añadir una cuenta de usuario al grupo del sistema docker en su arquitectura tradicional (rootful) equivale a concederle privilegios absolutos de superusuario sin control ni registro en las políticas de auditoría de sudo. Dado que el demonio dockerd se ejecuta con privilegios de root y escucha en /var/run/docker.sock, cualquier miembro de dicho grupo puede desplegar un contenedor privilegiado y montar la raíz del sistema de ficheros del anfitrión.

Para mitigar este vector crítico en entornos donde los usuarios deban ejecutar contenedores, existen dos soluciones de bastionado:

  1. Adopción de Podman: Diseñado con una arquitectura sin demonio (daemonless), Podman ejecuta los contenedores directamente como procesos subordinados al usuario que los invoca, prescindiendo de sockets con privilegios de root y apoyándose de forma nativa en los espacios de nombres de usuario configurados en /etc/subuid y /etc/subgid. No requiere que el usuario pertenezca a ningún grupo especial, eliminando de raíz la superficie de escalada de privilegios.

  2. Docker en modo rootless: Reconfigura el demonio de Docker para que se ejecute en el espacio de usuario (ver apartado 6.2), evitando el uso del grupo docker del sistema.

5.3. Ficheros de configuración y visudo

  • /etc/sudoers: Archivo de configuración principal. Nunca se debe editar con un editor de texto convencional, sino mediante sudo visudo, el cual bloquea el archivo para evitar concurrencia y valida la sintaxis antes de guardar. Un único fallo sintáctico en este fichero puede dejar el sistema bloqueado sin posibilidad de elevación administrativa.

  • /etc/sudoers.d/: Directorio para reglas modulares en archivos independientes. Es la práctica recomendada porque facilita la automatización y previene sobrescrituras durante las actualizaciones de paquetes. Se edita con sudo visudo -f /etc/sudoers.d/nombre.

Sintaxis fundamental de una directiva:

quién dónde=(como_quién) qué_comandos

Ejemplo de delegación con mínimo privilegio: permitir que los miembros de soporte reinicien el servicio SSH sin contraseña pero sin concederles ningún otro permiso de root:

%soporte ALL=(root) /usr/bin/systemctl restart ssh

Configuraciones peligrosas en sudoers

  • NOPASSWD: Suprime la solicitud de contraseña. Si la sesión del usuario se ve comprometida, el atacante obtiene root inmediatamente.

  • Binarios con escape a intérprete de comandos: Conceder permisos sudo sobre herramientas como vim, less, find, awk, tar o python equivale a otorgar una shell de root, ya que todas disponen de comandos internos para invocar intérpretes interactivos. El proyecto GTFOBins documenta cientos de binarios con estas características.

  • Uso de comodines (*) en argumentos: Permiten inyecciones de parámetros imprevistos que desbordan la intención de la regla.

5.4. Comandos de auditoría y trazabilidad

Comando Utilidad técnica

sudo -l

Lista los comandos que el usuario actual puede invocar mediante sudo.

sudo -l -U usuario

Permite al administrador inspeccionar los privilegios concedidos a otra cuenta.

sudo visudo -c

Verifica la integridad sintáctica de /etc/sudoers y de /etc/sudoers.d/*.

journalctl _COMM=sudo

Muestra el registro inmutable de todos los comandos ejecutados a través de sudo.

Con los conceptos de privilegios administrativos, reglas de sudoers y riesgos de grupos privilegiados, ya puede realizar:

6. Mecanismos avanzados y resolución de identidades

Una vez asimilada la administración cotidiana de usuarios y grupos locales, resulta indispensable comprender los mecanismos de arquitectura interna que gobiernan la criptografía de contraseñas, la virtualización sin privilegios y la integración con directorios empresariales.

6.1. Criptografía avanzada de contraseñas: yescrypt

A lo largo de la historia de los sistemas UNIX y Linux, los algoritmos de almacenamiento de credenciales han evolucionado para contrarrestar el incremento exponencial en la capacidad de cómputo de los atacantes:

\[\text{DES} \longrightarrow \text{MD5 (\$1\$)} \longrightarrow \text{SHA-256 (\$5\$)} \longrightarrow \text{SHA-512 (\$6\$)} \longrightarrow \text{yescrypt (\$y\$)}\]

En sistemas modernos como Debian 11, Debian 12 (Bookworm), Ubuntu 22.04 LTS y versiones recientes de Fedora, el algoritmo predeterminado es yescrypt (prefijo $y$).

6.1.1. Anatomía de una contraseña yescrypt

$y$j9T$WOMmh5En0h210kQG0eK...$bK8kU0oG10Wb0X1z9V4f6D...    (1) (2) (3) (4)
1 Identificador del algoritmo ($y$ identifica yescrypt).
2 Parámetros de configuración y dificultad (cost settings).
3 Sal criptográfica aleatoria que individualiza el hash.
4 Hash final derivado tras aplicar la función criptográfica.
Desglose de los parámetros de configuración y coste (j9T)

En el ejemplo anterior, la cadena j9T situada entre el identificador del algoritmo ($y$) y la sal codifica los parámetros de configuración y dificultad (cost settings):

  • j (Modo de operación y banderas): Selecciona la configuración estándar recomendada YESCRYPT_DEFAULTS, la cual habilita el modo nativo de 64 bits con memoria de lectura y escritura (memory-hard).

  • 9 (Coste computacional en CPU y memoria \(N\)): Representa un factor de coste exponencial \(N = 4096\), equivalente a \(2^{12}\) iteraciones.

  • T (Tamaño de bloque de memoria \(r\)): Corresponde a un tamaño de bloque \(r = 32\), medido en unidades de 128 bytes.

6.1.2. Funciones resistentes a memoria (Memory-Hard)

Los algoritmos tradicionales como SHA-512 son muy rápidos y no demandan casi memoria RAM para calcularse. Esto beneficia al atacante, quien puede desplegar granjas de tarjetas gráficas (GPU) o chips ASIC capaces de calcular miles de millones de hashes SHA-512 por segundo en ataques de fuerza bruta.

En contraste, yescrypt es una función diseñada expresamente con memoria-dura (memory-hard). Cada verificación de contraseña exige al procesador acceder constantemente a un búfer de aproximadamente 16 MiB de memoria RAM:

\[\text{Memoria requerida} = 128 \times r \times N \text{ bytes} = 128 \times 32 \times 4096 \text{ bytes} = 16.777.216 \text{ bytes} \approx 16 \text{ MiB}\]

Para un usuario legítimo que inicia sesión una sola vez, 16 MiB de RAM representan una fracción imperceptible de tiempo. Para un atacante que intenta evaluar millones de combinaciones por segundo, la exigencia de 16 MiB por hilo satura de inmediato el ancho de banda del bus de memoria y la memoria física disponible en dispositivos aceleradores como GPU, matrices de puertas lógicas programables en campo (FPGA) o circuitos integrados para aplicaciones específicas (ASIC), neutralizando la viabilidad económica y técnica del ataque.

6.1.3. Configuración de yescrypt en el sistema

El algoritmo de hash del sistema se gestiona en dos ubicaciones complementarias:

  1. En PAM (/etc/pam.d/common-password en Debian y Ubuntu): Se configura mediante una opción del módulo pam_unix.so. Es la directiva prioritaria utilizada por el comando passwd en las operaciones interactivas cotidianas:

    password [success=1 default=ignore] pam_unix.so obscure yescrypt

  2. En /etc/login.defs: Gobierna el comportamiento de las herramientas administrativas que no invocan a PAM, tales como chpasswd o newusers:

    ENCRYPT_METHOD YESCRYPT
YESCRYPT_COST_FACTOR 5

    La directiva YESCRYPT_COST_FACTOR permite graduar el coste entre los niveles 1 y 11, siendo 5 el valor asignado por defecto en las distribuciones actuales.

La modificación del algoritmo o del factor de coste no altera retroactivamente las contraseñas preexistentes en /etc/shadow. Cada registro conservará su algoritmo original hasta que el usuario realice un nuevo cambio de contraseña, momento en el cual el sistema recalculará y almacenará el hash conforme a la nueva directiva configurada.

6.1.4. Detección y migración de algoritmos heredados (Legacy)

En auditorías de bastionado sobre servidores actualizados a lo largo del tiempo o procedentes de migraciones anteriores, es muy frecuente encontrar cuentas cuyas contraseñas continúan almacenadas con algoritmos obsoletos o vulnerables, tales como MD5 ($1$), SHA-256 ($5$) o SHA-512 sin parámetros de memoria ($6$).

Dado que la actualización de las directivas en PAM o en /etc/login.defs para activar yescrypt no recalcula automáticamente los registros existentes en /etc/shadow, el administrador debe identificar activamente estas cuentas y forzar su renovación controlada.

Auditoría de contraseñas con algoritmos heredados

Para auditar e identificar qué cuentas del sistema utilizan funciones de hashing previas a yescrypt, se puede filtrar /etc/shadow por los prefijos de los algoritmos clásicos:

# Listar usuarios con hashes MD5 ($1$), SHA-256 ($5$) o SHA-512 ($6$)
sudo awk -F: '$2 ~ /^\$([156])\$/ {print $1, substr($2,1,3)}' /etc/shadow
Procedimiento de remediación y rotación forzada

Para garantizar una transición segura hacia algoritmos modernos, se aplican dos procedimientos según el tipo de cuenta:

  1. Cuentas interactivas de usuarios:
    La estrategia más segura consiste en marcar la contraseña como caducada forzando su actualización en el siguiente inicio de sesión:

    sudo chage -d 0 maria

    Cuando la usuaria inicie sesión, la pila PAM interceptará la solicitud a través de pam_unix.so, validará la credencial actual y exigirá introducir una nueva contraseña, la cual será procesada y almacenada bajo el algoritmo configurado en ese momento (yescrypt con su sal correspondiente).

    Para automatizar este requisito sobre la totalidad de cuentas identificadas con algoritmos antiguos:

    for usuario in $(sudo awk -F: '$2 ~ /^\$([156])\$/ {print $1}' /etc/shadow); do
    sudo chage -d 0 "$usuario"
done

  2. Cuentas de servicio o despliegues automatizados:
    En entornos desatendidos donde se dispone de las contraseñas gestionadas de forma centralizada, se puede actualizar la clave de forma masiva con chpasswd, la cual aplicará inmediatamente el algoritmo fijado en /etc/login.defs:

    echo "servicio_backup:ClaveComplejaGenerada2026!" | sudo chpasswd

6.2. Contenedores sin privilegios: /etc/subuid y /etc/subgid (Rootless)

En distribuciones modernas, al dar de alta un usuario normal se generan automáticamente entradas en los archivos /etc/subuid y /etc/subgid:

maria:100000:65536

Formato del registro:

usuario:UID_INICIAL:CANTIDAD

Esto indica que a la usuaria maria se le asigna un rango de 65.536 identificadores subordinados a partir del UID 100000.

6.2.1. Propósito de seguridad

Estos ficheros habilitan los espacios de nombres de usuario (User Namespaces) para tecnologías de contenedores sin privilegios (Rootless Docker o Podman):

  • El usuario puede actuar como root (UID 0) dentro del contenedor.

  • En el sistema anfitrión real, todos sus procesos se ejecutan bajo su UID subordinado sin privilegios (ej. UID 100000).

Si un atacante logra escapar del contenedor, aterriza en el anfitrión como un usuario sin privilegios y no como root, impidiendo la toma del sistema físico.

6.3. Fuentes de identidades híbridas: NSS y getent

Los archivos /etc/passwd y /etc/group representan la base de identidades local, pero no la única. En redes corporativas, los usuarios y grupos proceden habitualmente de directorios centralizados como LDAP, FreeIPA o Active Directory mediante SSSD.

El orden de consulta lo determina el NSS (Name Service Switch) a través de /etc/nsswitch.conf:

passwd:         files systemd sss
group:          files systemd sss
shadow:         files sss

El sistema consulta primero en los ficheros locales (files), luego en los servicios dinámicos de systemd y finalmente en SSSD (sss).

Arquitectura de resolución de identidades: Name Service Switch (NSS) y getent
Figura 2. Arquitectura de resolución de identidades: Name Service Switch (NSS) y getent

Por este motivo, al auditar cuentas debe emplearse getent en lugar de leer directamente los archivos planos:

getent passwd maria
getent group sudo

Un grep sobre /etc/passwd omitiría cualquier usuario procedente de un directorio empresarial en red, mientras que getent consulta a través de la capa NSS completa.

6.4. Arquitectura de autenticación: la pasarela entre las cuentas locales y PAM

A lo largo de este bloque formativo se han analizado las estructuras estáticas donde residen las cuentas, sus contraseñas y sus parámetros temporales (/etc/passwd, /etc/shadow, /etc/group y /etc/gshadow). Sin embargo, en los sistemas GNU/Linux existe una estricta separación de responsabilidades entre el almacén de datos y la lógica de autenticación:

  • Los ficheros locales y NSS constituyen el almacén pasivo: Conservan los registros, los hashes criptográficos con su sal y las fechas de expiración.

  • PAM (Pluggable Authentication Modules) implementa el motor de decisión dinámico: Es la infraestructura modular encargada de consultar dicho almacén, evaluar las políticas de acceso y autorizar o denegar las peticiones de los usuarios.

Pasarela de autenticación: Interacción entre la pila PAM y /etc/shadow
Figura 3. Pasarela de autenticación: Interacción entre la pila PAM y /etc/shadow

6.4.1. Correspondencia funcional entre /etc/shadow y los grupos de PAM

Cuando una aplicación del sistema (como login, sshd, su, sudo o passwd) requiere validar o actualizar una identidad, invoca a la pila PAM dividida en cuatro grupos de gestión:

  1. Grupo auth (Autenticación de identidad):

    • El módulo pam_unix.so lee el campo 2 de /etc/shadow, extrae la sal y el algoritmo, calcula el hash de la clave introducida y verifica si coinciden.

    • Módulos complementarios como pam_faillock.so (sucesor moderno de pam_tally2) mantienen un registro independiente de intentos fallidos para mitigar ataques de fuerza bruta, bloqueando temporalmente la cuenta sin necesidad de corromper o alterar el registro en /etc/shadow.

  2. Grupo account (Validación del estado de la cuenta):

    • El módulo pam_unix.so evalúa los campos 4 a 8 de /etc/shadow: comprueba si la fecha de último cambio más el tiempo máximo de validez ha expirado (max), si se ha superado el periodo de gracia por inactividad (inactive) o si la fecha de caducidad absoluta ha llegado (expire). Si la cuenta expiró, la autenticación se interrumpe de inmediato emitiendo el mensaje «Your account has expired», neutralizando incluso accesos basados en llaves SSH.

  3. Grupo password (Actualización de credenciales):

    • Antes de modificar el archivo de contraseñas, el módulo pam_pwquality.so evalúa la longitud, la entropía y la presencia en diccionarios de la nueva clave elegida por el usuario.

    • Una vez validada su robustez, pam_unix.so genera una nueva sal aleatoria de 16 bytes, deriva el hash utilizando el algoritmo configurado (habitualmente yescrypt) y reescribe el campo 2 de /etc/shadow, actualizando además la fecha del último cambio en el campo 3 con el número de días transcurridos desde el inicio de la época UNIX.

  4. Grupo session (Configuración del entorno de ejecución):

    • Tras superar las fases anteriores, módulos como pam_umask.so aplican la máscara de permisos predeterminada (por ejemplo 027), mientras pam_limits.so impone topes a los recursos del sistema definidos en /etc/security/limits.conf.

Esta arquitectura desacoplada permite sustituir o robustecer cualquier mecanismo de seguridad sin tener que reprogramar las utilidades de administración de cuentas. En el Bloque 3: Módulos de autenticación conectables (PAM) se abordará en profundidad la sintaxis de las reglas de control, el apilamiento de módulos y el bastionado avanzado mediante pam_pwquality y pam_faillock.

7. Guía consolidada de bastionado y lista de verificación

Como síntesis de las medidas analizadas en los capítulos anteriores, el administrador de sistemas debe verificar de forma sistemática el siguiente catálogo de directivas técnicas de endurecimiento.

7.1. Matriz de riesgos y medidas técnicas

Vector de amenaza Impacto potencial Medida de bastionado obligatoria Verificación técnica

Cuenta clonada con UID 0

Puerta trasera de administración completa

Exigir unicidad absoluta de UID 0 para root

awk -F: '$3 == 0 {print $1}' /etc/passwd

Cuentas sin contraseña

Acceso interactivo local no autenticado

Bloquear o asignar contraseñas robustas

awk -F: '$2 == "" {print $1}' /etc/shadow

Permisos laxos en /home

Fuga de privacidad entre usuarios normales

Imponer máscara CIS 0750 o 0700

find /home -maxdepth 1 -type d -perm /027

Sesiones SSH con clave activa

Persistencia tras deshabilitar contraseña

Bloqueo completo de cuenta con expiración

usermod -L -e 1 usuario

Terminales desatendidas

Acceso físico o lateral no autorizado

Cierre forzado de shell por inactividad

Variable inmutable readonly TMOUT=900

Pertenencia a docker

Escalada a superusuario sin auditoría

Migrar a Docker rootless o Podman

getent group docker

Ficheros huérfanos postbaja

Apropiación de ficheros por nuevo UID

Rastrear huérfanos antes de reasignar UIDs

find / -xdev \( -nouser -o -nogroup \)

7.2. Lista de verificación de bastionado (Checklist CIS)

  1. Asegurar que únicamente root tenga UID 0 y remediar cuentas clandestinas:

    awk -F: '$3 == 0 {print $1}' /etc/passwd

    La salida debe devolver únicamente root. Si aparece cualquier otra cuenta (por ejemplo toor o admin), el sistema contiene una puerta trasera con privilegios absolutos de administración.

    Precaución operacional al eliminar cuentas con UID 0

    Si se detecta una cuenta clandestina con UID 0, la ejecución directa de userdel fallará si el atacante mantiene sesiones interactivas abiertas o procesos en segundo plano. Para remediar la intrusión de forma segura:

    1. Interrumpir procesos y sesiones activas: Terminar de inmediato cualquier proceso vinculado a la identidad clandestina antes de intentar su borrado:

      sudo pkill -9 -u toor
# O en sistemas con systemd:
sudo loginctl terminate-user toor

    2. Bloquear la cuenta preventivamente: Desactivar la caducidad y el acceso por contraseña mientras se analiza el incidente:

      sudo usermod -L -e 1 toor

    3. Eliminar la cuenta sin tocar el directorio raíz: Ejecutar el borrado de la cuenta con sudo userdel toor (o forzándolo con sudo userdel -f toor si fuera necesario). Bajo ninguna circunstancia utilice la bandera -r (userdel -r), puesto que si la cuenta compartía el directorio /root con el superusuario legítimo, eliminaría el directorio de trabajo del administrador real.

  2. Desactivar el intérprete interactivo en cuentas de servicio: Las cuentas de sistema (UID 1 a 999) deben utilizar /usr/sbin/nologin como shell en /etc/passwd.

  3. Configurar el cierre automático de sesión por inactividad (TMOUT): {#sec7-2-tmout} Para evitar que una terminal desatendida quede expuesta, se define el cierre automático a los 15 minutos (900 segundos) de inactividad de forma obligatoria e inmutable en /etc/profile.d/timeout.sh:

    sudo tee /etc/profile.d/timeout.sh << 'EOF'
readonly TMOUT=900
export TMOUT
EOF
sudo chmod 644 /etc/profile.d/timeout.sh

  4. Identificar cuentas con contraseña vacía:

    sudo awk -F: '$2 == "" {print $1}' /etc/shadow

    La salida debe ser estrictamente vacía.

  5. Auditar identificadores duplicados (UIDs y GIDs):

    cut -d: -f3 /etc/passwd | sort -n | uniq -d
cut -d: -f3 /etc/group | sort -n | uniq -d

  6. Auditar nombres duplicados de usuario y grupo:

    cut -d: -f1 /etc/passwd | sort | uniq -d
cut -d: -f1 /etc/group | sort | uniq -d

  7. Elevación segura con su -: Al cambiar a superusuario, utilice siempre su - o sudo -i en lugar de su. El guion inicializa un entorno de inicio de sesión limpio y evita heredar variables manipuladas o rutas relativas en el PATH.

  8. Auditar ficheros de inicio ocultos y eliminar ficheros peligrosos:

    • Comprobar que los archivos de inicio (.bashrc, .profile) en /home no tengan permisos de escritura para otros:

      sudo find /home -maxdepth 2 -name ".*" -perm /022 -ls

    • Asegurar que no existan archivos de credenciales obsoletos o inseguros:

      sudo find /home \( -name ".netrc" -o -name ".rhosts" -o -name ".forward" \) -ls

  9. Verificar que el grupo shadow no tenga miembros interactivos:

    grep '^shadow:' /etc/group

    El cuarto campo debe estar vacío. Si contiene usuarios, estos pueden leer los hashes sin necesidad de sudo.

  10. Proteger la cuenta root: En sistemas administrados con sudo, la contraseña de root debe permanecer bloqueada (estado L en sudo passwd -S root) y su grupo principal debe ser GID 0.

7.3. Diagnóstico automatizado de integridad: pwck y grpck

Las utilidades pwck y grpck analizan la integridad sintáctica y referencial de los archivos de cuentas. Es imprescindible ejecutarlas en modo de solo lectura (-r) en tareas de auditoría para no aplicar cambios imprevistos en los ficheros del sistema:

sudo pwck -r
sudo grpck -r

Estas herramientas comprueban que no existan campos omitidos, delimitadores faltantes, directorios personales inaccesibles, formatos corruptos ni GIDs inexistentes asignados a usuarios.

7.3.1. Automatización periódica con Cron y registro en el diario del sistema

En un entorno corporativo bastionado, confiar únicamente en revisiones manuales puntuales resulta insuficiente. Un atacante o un error de administración podría introducir una inconsistencia que pasaría inadvertida hasta la siguiente auditoría manual.

Para garantizar la supervisión continua, se debe configurar una tarea periódica diaria en /etc/cron.daily/audit-account-integrity que ejecute las comprobaciones y registre cualquier anomalía en syslog o en el diario de systemd mediante la utilidad logger:

sudo tee /etc/cron.daily/audit-account-integrity << 'EOF'
#!/bin/bash
# Auditoría diaria de integridad de cuentas y grupos (CIS Benchmark)

LOG_TAG="audit-account-integrity"

# Ejecutar validaciones en modo solo lectura
PWCK_OUTPUT=$(pwck -r 2>&1)
PWCK_STATUS=$?

GRPCK_OUTPUT=$(grpck -r 2>&1)
GRPCK_STATUS=$?

# Evaluar resultados y alertar en el diario si se detectan anomalías
if [ $PWCK_STATUS -ne 0 ]; then
    logger -t "$LOG_TAG" -p auth.alert "ALERTA: Se detectaron inconsistencias en /etc/passwd o /etc/shadow: $PWCK_OUTPUT"
fi

if [ $GRPCK_STATUS -ne 0 ]; then
    logger -t "$LOG_TAG" -p auth.alert "ALERTA: Se detectaron inconsistencias en /etc/group o /etc/gshadow: $GRPCK_OUTPUT"
fi

exit $((PWCK_STATUS + GRPCK_STATUS))
EOF
sudo chmod 750 /etc/cron.daily/audit-account-integrity

Para verificar el funcionamiento de la tarea programada y auditar las alertas registradas en el diario:

# Probar la ejecución manual del script
sudo /etc/cron.daily/audit-account-integrity

# Consultar si existen incidencias registradas en el diario
journalctl -t audit-account-integrity

Una vez estudiadas todas las medidas de bastionado del ciclo de vida de usuarios y grupos, puede consolidar sus competencias completando:

8. Ejercicios prácticos

Los ejercicios están diseñados para realizarse en orden sobre una máquina virtual Ubuntu/Debian de pruebas, ya que algunos reutilizan usuarios y grupos creados en ejercicios anteriores. El último ejercicio deja el sistema en su estado original.

No realice estos ejercicios en un servidor en producción. Algunos pasos simulan configuraciones inseguras de forma deliberada.
Nº Ejercicio Competencia que desarrolla

1

Exploración de los ficheros de cuentas

Interpretar passwd, shadow y group, sus permisos y su relación

2

Hash y sal de las contraseñas

Comprender cómo se almacenan las contraseñas y el papel de la sal

3

Alta segura de cuentas interactivas y de servicio

Crear cuentas con los atributos adecuados a su función

4

Modificación y renombrado de cuentas

Gestionar cambios en cuentas existentes sin inconsistencias

5

Bloqueo parcial frente a bloqueo completo

Diferenciar el bloqueo de contraseña del bloqueo real de la cuenta

6

Caducidad de contraseñas y cuentas temporales

Aplicar políticas de caducidad, expiración e inactividad

7

Valores por defecto: login.defs, useradd -D y /etc/skel

Configurar cómo nacen las nuevas cuentas

8

Grupos, gpasswd y directorio compartido

Organizar usuarios por funciones y delegar la gestión de grupos

9

Auditoría de grupos privilegiados y sudo

Detectar privilegios excesivos y delegar con mínimo privilegio

10

Detección de una puerta trasera con UID 0

Identificar técnicas de persistencia basadas en cuentas

11

Baja segura y reutilización de UID

Eliminar cuentas sin dejar riesgos residuales

12

Controles CIS y script de auditoría

Automatizar la verificación del bastionado de cuentas

13

Limpieza del entorno

Revertir los cambios realizados durante la práctica

8.1. Ejercicio 1. Exploración de los ficheros de cuentas

En un sistema multiusuario, la seguridad comienza por conocer quién existe en el sistema, qué privilegios tiene cada cuenta y cómo se protege su información.

Realice los siguientes pasos:

  1. Muestra las primeras 10 líneas del archivo /etc/passwd e identifica los siete campos de una de ellas.

  2. Lista todos los usuarios con UID menor que 1000 junto con su shell asignado (campo 7).

  3. Audita si existe alguna cuenta de sistema (UID entre 1 y 999) que disponga indebidamente de un shell interactivo (distinto de nologin, false o sync).

  4. Comprueba los permisos, propietario y grupo de /etc/passwd, /etc/shadow, /etc/group y /etc/gshadow, e interpreta el resultado.

  5. Intenta visualizar /etc/shadow sin privilegios de superusuario (deberías obtener “Permiso denegado”) y después con sudo.

  6. Identifica qué algoritmo de hash se ha usado para la contraseña de tu propio usuario, a partir del prefijo del segundo campo de /etc/shadow.

  7. Convierte el campo lastchange de tu usuario en una fecha legible.

  8. Muestra tu grupo principal y tus grupos secundarios, y comprueba que tu entrada se obtiene igual con grep que con getent. Explica en qué situación ambos comandos darían resultados distintos.

8.2. Ejercicio 2. Hash y sal de las contraseñas

Las contraseñas no se almacenan cifradas, sino como hash con sal. En este ejercicio comprobará experimentalmente para qué sirve la sal.

Realice los siguientes pasos:

  1. Genera dos veces el hash SHA-512 de la contraseña Bastionado2026 con openssl passwd -6. ¿Son iguales los resultados? ¿Por qué?

  2. Repite la operación fijando manualmente la sal abcdefgh. ¿Qué ocurre ahora?

  3. Instala el paquete whois y genera un hash yescrypt con mkpasswd. Identifica en el resultado el identificador del algoritmo, los parámetros de coste y la sal.

  4. Comprueba qué algoritmo utiliza el sistema para las nuevas contraseñas, tanto en PAM como en /etc/login.defs. ¿Cuál de los dos tiene prioridad al usar passwd?

  5. Explica por qué la sal impide que un atacante use tablas precalculadas (rainbow tables) y por qué yescrypt es más resistente que SHA-512 a los ataques con GPU.

8.3. Ejercicio 3. Alta segura de cuentas interactivas y de servicio

Cada cuenta debe crearse con los atributos adecuados a su función: una persona necesita una shell y un directorio personal, pero un servicio no.

Realice los siguientes pasos:

  1. Crea el usuario interactivo prueba1 con directorio personal, shell /bin/bash y el comentario Usuario de prueba.

  2. Comprueba qué contiene el campo de contraseña de prueba1 en /etc/shadow antes de asignarle una contraseña. ¿Puede iniciar sesión?

  3. Asígnale una contraseña y obliga a que la cambie en su primer inicio de sesión.

  4. Inicia sesión como prueba1 con su - y verifica que el sistema obliga a cambiar la contraseña.

  5. Crea la cuenta de servicio appsvc como cuenta del sistema, sin directorio personal creado, con directorio /var/lib/appsvc y shell /usr/sbin/nologin.

  6. Comprueba que su UID está por debajo de 1000 y que no tiene grupo privado con UID ≥ 1000.

  7. Verifica que la cuenta appsvc no permite una sesión interactiva, pero que sí puede ejecutar procesos (como haría un servicio).

8.4. Ejercicio 4. Valores por defecto: login.defs, useradd -D y /etc/skel

Garantizar que las nuevas cuentas nazcan con una configuración segura es más eficaz que corregirlas una a una después.

Realice los siguientes pasos:

  1. Haz una copia de seguridad de /etc/login.defs y de /etc/skel/.profile.

  2. Consulta los valores actuales de PASS_MAX_DAYS, PASS_MIN_DAYS, PASS_WARN_AGE, HOME_MODE, UMASK y ENCRYPT_METHOD.

  3. Modifica /etc/login.defs para que PASS_MAX_DAYS valga 365 y PASS_MIN_DAYS valga 1 (valores CIS). Si HOME_MODE no está definido, añade HOME_MODE 0750.

  4. Consulta los valores por defecto de useradd y configura que las cuentas se desactiven 30 días después de caducar su contraseña.

  5. Inspecciona los archivos ocultos de /etc/skel y añade al final de /etc/skel/.profile la directiva umask 027.

  6. Crea el usuario auditor y verifica: permisos de su directorio personal, su umask al iniciar sesión y su política de caducidad.

  7. Compara la salida de sudo chage -l auditor con la de sudo chage -l prueba1. ¿Por qué los cambios en login.defs no han afectado a prueba1?

  8. Reflexiona: ¿puede auditor eliminar la línea umask 027 de su .profile? ¿Qué mecanismo usarías para imponer la máscara a todos los usuarios de forma obligatoria?

8.5. Ejercicio 5. Modificación y renombrado de cuentas

En ocasiones es necesario ajustar cuentas existentes sin recrearlas, por ejemplo, al cambiar el nombre de un usuario. Hay que hacerlo con cuidado para no dejar inconsistencias.

Realice los siguientes pasos:

  1. Crea el usuario seguridad con directorio personal, shell /bin/bash y contraseña.

  2. Renombra el usuario seguridad a analista.

  3. Cambia su directorio personal a /home/analista moviendo su contenido.

  4. Ejecuta id analista. ¿Cómo se llama su grupo principal? Corrige la inconsistencia.

  5. Verifica los cambios en /etc/passwd y comprueba el propietario, el grupo y los permisos de /home/analista.

  6. Cambia la shell de analista a /bin/sh con chsh y después restáurala a /bin/bash. ¿Qué requisito debe cumplir la shell elegida?

8.6. Ejercicio 6. Caducidad de contraseñas y cuentas temporales

Las cuentas temporales (becarios, auditores externos, contratistas) deben caducar automáticamente para que no queden habilitadas cuando ya no se necesitan.

Realice los siguientes pasos:

  1. Aplica al usuario analista una caducidad de contraseña de 45 días con aviso 5 días antes, y verifica la configuración.

  2. Crea el usuario temporal becario de forma que su cuenta expire dentro de 90 días y se desactive 15 días después de que caduque su contraseña.

  3. Asígnale una contraseña, fuerza el cambio en el primer inicio de sesión y verifica todos sus parámetros.

  4. Localiza los campos correspondientes en la línea de becario de /etc/shadow y relaciona cada uno con la salida de chage -l.

  5. Reflexiona: según NIST SP 800-63B, ¿tiene sentido obligar a cambiar la contraseña cada 45 días? ¿Y fijar una fecha de expiración para la cuenta del becario?

8.7. Ejercicio 7. Bloqueo parcial frente a bloqueo completo

Un error habitual es pensar que passwd -l impide por completo el acceso a una cuenta. En este ejercicio comprobará la diferencia entre deshabilitar la contraseña y bloquear la cuenta.

Realice los siguientes pasos:

  1. Bloquea la contraseña de analista con passwd -l y comprueba su estado con passwd -S.

  2. Desde tu usuario, intenta iniciar sesión como analista con su -. ¿Qué ocurre?

  3. Explica por qué este bloqueo no impide el acceso por SSH con clave pública en la configuración por defecto de Debian/Ubuntu.

    +

Ampliación (si dispone de servidor SSH): antes del paso 1, copie una clave pública al usuario con ssh-copy-id analista@localhost y compruebe que, tras passwd -l, ssh analista@localhost sigue funcionando.

  1. Aplica ahora un bloqueo completo haciendo que la cuenta haya expirado, y comprueba el resultado con chage -l.

  2. Intenta de nuevo su - analista (y, si hiciste la ampliación, ssh analista@localhost). ¿Qué mensaje aparece ahora?

  3. Desbloquea completamente la cuenta.

8.8. Ejercicio 8. Baja segura y reutilización de UID

Eliminar usuarios es parte del mantenimiento seguro del sistema, pero hacerlo sin precauciones puede dejar archivos huérfanos que acaban en manos de otro usuario.

Realice los siguientes pasos:

  1. Crea el usuario usuario3, anota su UID y crea como usuario3 un fichero fuera de su directorio personal.

  2. Bloquea por completo la cuenta antes de eliminarla.

  3. Comprueba que no tiene procesos en ejecución ni tareas programadas.

  4. Localiza todos los archivos del usuario en el sistema y haz una copia de seguridad de su directorio personal en /backup.

  5. Elimina la cuenta y su directorio personal, y comprueba que ya no existe.

  6. Busca archivos huérfanos (sin usuario o sin grupo válido).

  7. Crea un nuevo usuario usuario4, consulta su UID y vuelve a listar /tmp/secreto_usuario3.txt. ¿Qué ha ocurrido? ¿Qué riesgo supone?

  8. Elimina el fichero /tmp/secreto_usuario3.txt.

8.9. Ejercicio 9. Grupos, gpasswd y directorio compartido

En entornos reales se crean grupos para organizar usuarios por departamentos o funciones, y se delega su gestión en los responsables de cada equipo.

Realice los siguientes pasos:

  1. Crea los grupos soporte, redes y tecnicos.

  2. Crea usuario1 (miembro de soporte y tecnicos) y usuario2 (miembro de redes y tecnicos) en un solo comando cada uno.

  3. Nombra a usuario1 administrador del grupo tecnicos y comprueba el cambio en /etc/gshadow.

  4. Actuando como usuario1 (y sin usar sudo para el comando gpasswd), añade a analista al grupo tecnicos.

  5. Crea el directorio compartido /srv/tecnicos, accesible solo para root y los miembros del grupo tecnicos.

  6. Comprueba que usuario1 puede crear un fichero en /srv/tecnicos y que auditor no puede.

  7. Renombra el grupo redes a comunicaciones y verifica que usuario2 sigue perteneciendo a él.

  8. Intenta eliminar el grupo analista. ¿Por qué falla?

8.10. Ejercicio 10. Detección de una puerta trasera con UID 0

Una técnica habitual de persistencia tras comprometer un sistema consiste en crear una cuenta con un nombre aparentemente inofensivo (admin, support, toor…) y UID 0. En este ejercicio simulará el ataque y lo detectará como lo haría un auditor.

Realice los siguientes pasos:

  1. (Simulación del atacante) Crea la cuenta toor con UID 0 y GID 0, usando /root como directorio personal y sin crearlo.

  2. (Auditoría) Lista todas las cuentas con UID 0.

  3. Detecta los UID duplicados del sistema.

  4. Comprueba qué nombre de usuario muestra el sistema para los archivos de root y para tus procesos con sudo. ¿Por qué podría pasar desapercibida la cuenta?

  5. Elimina la cuenta toor sin borrar el directorio /root. Compruebe si tiene procesos asociados, deténgalos y proceda a la eliminación segura.

    +

No utilice nunca userdel -r en este caso: borraría el directorio /root. Además, si el usuario tuviera procesos activos en el sistema, userdel fallará a menos que se hayan terminado previamente sus procesos con pkill o se fuerce la baja con la opción -f.

8.11. Ejercicio 11. Auditoría de grupos privilegiados y sudo

Antes de aplicar medidas de bastionado, el administrador debe saber quién puede convertirse en root, ya sea a través de sudo o de grupos privilegiados.

Realice los siguientes pasos:

  1. Lista los miembros de los grupos privilegiados sudo, adm, docker, lxd, disk y shadow (algunos pueden no existir en tu sistema).

  2. Muestra las reglas activas de /etc/sudoers y de /etc/sudoers.d/, sin comentarios ni líneas vacías.

  3. Consulta qué privilegios sudo tienen tu usuario y analista.

  4. Añade a analista al grupo sudo, comprueba de nuevo sus privilegios y, a continuación, revócalos.

  5. Crea con visudo el fichero /etc/sudoers.d/soporte para que los miembros del grupo soporte solo puedan ejecutar systemctl status ssh como root. Valida la sintaxis.

  6. Comprueba los privilegios resultantes de usuario1 y de usuario2.

  7. Busca en GTFOBins qué ocurriría si la regla anterior permitiera ejecutar /usr/bin/less o /usr/bin/find en lugar de systemctl status ssh.

8.12. Ejercicio 12. Controles CIS y script de auditoría

Las herramientas de verificación del sistema y los controles del CIS Benchmark permiten detectar corrupciones de archivos, identificadores duplicados, cuentas sin contraseña y membresías peligrosas. En este ejercicio los aplicará manualmente y después los automatizará.

Realice los siguientes pasos:

  1. Ejecuta pwck y grpck en modo solo lectura e interpreta los avisos.

  2. Comprueba los permisos de los archivos de cuentas y de sus copias de respaldo.

  3. Verifica que el grupo shadow no tiene miembros y que no existen UID, GID ni nombres duplicados.

  4. (Simulación) Elimina la contraseña de prueba1 con passwd -d, detecta la cuenta sin contraseña con awk y corrige el problema bloqueándola.

  5. Configura el cierre de sesión por inactividad (TMOUT=900, de solo lectura) en /etc/profile.d/timeout.sh. Abre una nueva sesión de login y comprueba que no se puede desactivar con unset TMOUT.

  6. Escribe un script auditoria_cuentas.sh que ejecute los siguientes controles y muestre OK o ALERTA para cada uno:

    • Solo existe una cuenta con UID 0.

    • No hay cuentas sin contraseña.

    • No hay UID, GID ni nombres duplicados.

    • El grupo shadow no tiene miembros.

    • Ninguna cuenta de sistema (UID 1-999) tiene shell interactiva.

    • /etc/shadow y /etc/gshadow tienen permisos 640 o más restrictivos.

    • Ningún directorio de /home es accesible por “otros”.

    • Lista de miembros de los grupos privilegiados.

8.13. Ejercicio 13. Limpieza del entorno

Para terminar, revierta los cambios realizados durante la práctica.

Realice los siguientes pasos:

  1. Elimina los usuarios creados durante la práctica junto con sus directorios personales: prueba1, appsvc, analista, becario, auditor, usuario1, usuario2 y usuario4.

  2. Elimina los grupos soporte, comunicaciones y tecnicos, el directorio /srv/tecnicos, la regla /etc/sudoers.d/soporte y la copia /backup/usuario3_backup.tar.gz.

  3. Restaura /etc/login.defs y /etc/skel/.profile a partir de las copias de seguridad, y el valor por defecto de INACTIVE de useradd.

  4. Comprueba con pwck, grpck y tu script de auditoría que el sistema queda en un estado coherente. Decide si quieres conservar /etc/profile.d/timeout.sh.

    Con la realización de estos ejercicios prácticos se consolidan los procedimientos esenciales de auditoría, administración segura y bastionado de cuentas y grupos locales en sistemas Linux, asegurando la integridad de los archivos de autenticación y el cumplimiento de las directrices del CIS Benchmark.

9. Licencia

Licencia CC BY-NC-ND 4.0

Esta página forma parte del curso Bastionado de Redes y Sistemas © 2026 de José Juan Sánchez Hernández y su contenido se distribuye bajo una licencia Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International.

Esta licencia exige que quienes reutilicen el material otorguen el debido crédito al autor. Permite copiar y redistribuir el material en cualquier medio o formato, únicamente en su forma original, y solo para fines no comerciales.