Todo el marco de la lección anterior —sujetos, dominios, matriz de acceso, mínimo privilegio— descansa sobre una palabra que aún no hemos definido: identidad. Un dominio de protección se asigna a un sujeto, y el sujeto se identifica por un número. El núcleo de Linux no conoce a meteora, ni a nuria, ni a carlos: conoce el 990, el 1002 y el 1001. Todo lo demás —el nombre, la contraseña, el grupo, la shell— vive en ficheros de texto de /etc que el núcleo ni siquiera lee.

Eso tiene una consecuencia que conviene interiorizar desde el primer minuto: la identidad en UNIX es una convención de espacio de usuario sostenida sobre un número. Si borras la línea de meteora de /etc/passwd, los 17.280.000 bytes de 2026-08-31.dat siguen perteneciendo al UID 990 y ls -l los muestra como 990. Si creas otro usuario con el 990, ese usuario es el dueño de los datos de Meteora sin haber tocado un solo fichero. El número es la identidad; el nombre es una etiqueta.

Esta lección recorre la cadena completa: los identificadores y por qué cada proceso lleva tres UID —lo que explica del todo el passwd setuid de 04-06—; los tres ficheros de /etc campo a campo; el ciclo de vida de una cuenta y el momento del que más incidentes salen, la baja; la autenticación en sí, con cómo se guarda una contraseña, qué significa el $y$j9T$... de /etc/shadow y qué ataques la amenazan —descritos a nivel conceptual, para poder defenderse—; PAM, la pieza que decide si entras y que casi nadie entiende hasta que la rompe; la autenticación por clave pública de SSH, que es la que usarás de verdad en meteo-01; y la elevación controlada con sudo, con el catálogo defensivo de los errores de configuración que convierten una cuenta normal en root.

1. UID, GID y los tres identificadores de un proceso
2. Grupos suplementarios y la lectura de id, whoami y groups
3. /etc/passwd, /etc/shadow y /etc/group campo a campo
4. Cuentas de sistema frente a cuentas humanas
5. Gestión y ciclo de vida de una cuenta
6. Autenticación: los tres factores
7. Cómo se almacena una contraseña
8. Ataques a credenciales y sus contramedidas
9. PAM: la arquitectura que decide si entras
10. Autenticación por clave pública con SSH
11. Elevación controlada de privilegios: su y sudo
12. Escalada de privilegios: catálogo defensivo y auditoría

Cada proceso lleva un juego de identificadores numéricos que el núcleo consulta en cada comprobación de acceso. Los de usuario son tres, y esa multiplicidad no es un capricho histórico: resuelve un problema concreto.

Recupera el passwd setuid de 04-06 y ahora tendrá sentido completo. El usuario joan (UID 1000) lo ejecuta:

El programa necesita las dos cosas a la vez: euid=0 para escribir en /etc/shadow, y ruid=1000 para saber de quién debe cambiar la contraseña. Si solo existiera el efectivo, passwd no tendría forma fiable de saber quién lo invocó y cualquiera podría cambiar la contraseña de cualquiera. Los tres identificadores existen, en resumen, para que autoridad e identidad puedan ser distintas y ambas estén disponibles.

El guardado habilita el patrón más importante para escribir servicios seguros: soltar el privilegio.

Tres detalles de los que dependen vulnerabilidades reales. El orden es obligatorio: setgroups y setgid van antes de setuid, porque después de perder el UID 0 ya no hay permiso para cambiar los grupos y el proceso conservaría los grupos suplementarios de root. setuid() llamado por root cambia los tres identificadores a la vez, y por eso la bajada es irreversible; con seteuid() el guardado seguiría siendo 0 y un atacante recuperaría root con una llamada. Y la verificación final no es paranoia: comprueba que la bajada fue definitiva, y su ausencia ha causado escaladas documentadas en software muy conocido. Con los GID ocurre lo mismo, y el bit setgid actúa sobre el efectivo igual que setuid sobre el suyo.

Un proceso pertenece a un grupo primario y a varios suplementarios, y para las comprobaciones de 04-06 cualquiera de ellos sirve para entrar en la clase de grupo.

uid=1001(carlos) es el UID efectivo con su nombre traducido; gid=1001 es el grupo primario, que se asigna por defecto a los ficheros que cree —salvo que el directorio tenga setgid, como /var/lib/meteora—; y la lista grupos= son todos sus grupos. Los tres de carlos son tres decisiones de seguridad distintas y conviene que lo sean: adm le da lectura de los registros, sudo le habilita la elevación y meteora el acceso al grupo del servicio. Es separación de privilegios de 05-01 aplicada a una persona.

Un detalle que sorprende: whoami informa del efectivo, no del real. Dentro de un proceso setuid root dice root aunque lo lanzara joan. Para saber quién hay detrás se usa id -ru o, en una sesión interactiva, who am i, que consulta el registro de sesiones y sobrevive a los su encadenados.

Los grupos suplementarios se calculan al iniciar sesión y se heredan por fork. Un usermod -aG meteora carlos no afecta a las sesiones abiertas ni a los procesos arrancados. id mostrará el grupo nuevo porque relee /etc/group, pero el proceso seguirá sin el acceso: el núcleo usa las credenciales que el proceso lleva encima, no el fichero. Hay que reiniciar la sesión o el servicio.

La forma rápida de distinguirlo: id lee el fichero, y grep Groups /proc/<pid>/status muestra los grupos reales del proceso. Si difieren, ese es el problema.

La x del campo 2 es historia viva: hasta principios de los noventa el hash estaba ahí mismo, en un fichero legible por todos porque muchos programas necesitan traducir UID a nombre. Cuando el poder de cómputo hizo viables los ataques por diccionario, los hashes se movieron a /etc/shadow, legible solo por root, y quedó la x como marca. Es un ejemplo perfecto de reducción de superficie: el dato sensible se saca del fichero que todo el mundo necesita leer.

El campo 7, /usr/sbin/nologin, es un programa real que imprime un aviso y sale con error; la diferencia con /bin/false es cosmética, pero dejar el campo vacío sí importa, porque entonces se usa /bin/sh.

Por qué meteora no tiene shell. Es mínimo privilegio aplicado a la identidad: la cuenta existe solo para ser dueña de unos ficheros y ser la identidad de unos procesos que arranca systemd. Si un atacante obtiene una credencial de meteora, no puede usarla para entrar por SSH ni abrir sesión: solo le sirve si ya está dentro. Una capa entera de defensa por una palabra en el campo 7.

Los cuatro valores posibles del campo 2 se confunden constantemente: $y$... es una contraseña válida; ! o !hash es cuenta bloqueada (passwd -l), un bloqueo reversible porque el hash se conserva detrás y passwd -u lo restaura; * significa que nunca ha tenido contraseña ni la tendrá, lo normal en cuentas de paquetes; y vacío significa acceso sin credencial, que es una emergencia. Por eso meteora:!: es lo correcto para una cuenta de servicio.

Y un matiz decisivo para el apartado 5: bloquear la contraseña no bloquea el acceso por clave SSH, porque son mecanismos de autenticación distintos.

Nombre, marcador de contraseña, GID y lista de miembros suplementarios. La sutileza: los miembros cuyo grupo primario es este NO aparecen en la lista. meteora:x:990: está vacío y sin embargo el usuario meteora pertenece al grupo, porque lo tiene como primario en /etc/passwd. Por eso id nuria es más fiable que leer /etc/group: combina las dos fuentes.

Dos reglas al editar estos ficheros. Usa vipw, vipw -s y vigr en lugar del editor a pelo: bloquean contra ediciones simultáneas y validan la sintaxis —un /etc/passwd corrupto deja el sistema sin poder resolver ningún nombre de usuario—. Y valida con pwck y grpck tras cualquier cambio manual.

La separación por rango no es una regla del núcleo: es una convención que aplican useradd y login leyendo /etc/login.defs. Su valor es operativo: permite escribir auditorías del tipo "toda cuenta con UID ≥ 1000 debe tener segundo factor" o "ninguna con UID < 1000 debe tener shell". Así se creó meteora:

Cada opción es una decisión. --system sitúa el UID en el rango de servicios y evita crear un grupo personal. --no-create-home es correcto porque /var/lib/meteora lo crea el paquete con los permisos 2750 de 04-06, no useradd con los suyos. --shell /usr/sbin/nologin cierra el inicio de sesión. Y passwd -l es explícito aunque useradd --system ya deje la cuenta bloqueada: la seguridad se declara, no se supone.

El error clásico está en la línea del cambio de rol: usermod -G sin la -a sustituye toda la lista de grupos suplementarios. Un usermod -G adm carlos bien intencionado lo deja fuera de sudo y de meteora, y el efecto no se nota hasta que alguien necesita esos accesos. La -a significa append, y la regla es no escribir nunca -G sin ella.

Los incidentes se acumulan siempre en los dos mismos puntos.

El cambio de rol y la acumulación de privilegios. Cuando alguien cambia de puesto se le añaden los accesos nuevos y casi nunca se le quitan los viejos; tras cinco años y tres equipos acumula acceso a media empresa sin que nadie lo haya decidido. Es la violación silenciosa del mínimo privilegio, y la única defensa es la revisión periódica de accesos: cada seis meses, comprobar que cada grupo y cada regla de sudo siguen justificados. Es aburrido y funciona.

La baja, que es el mayor riesgo real del ciclo. Una cuenta viva tras la salida de una persona es una credencial válida sin dueño ni supervisión. Y el error habitual no es olvidar la baja, sino hacerla a medias. Tiene cinco bloques y ninguno sustituye a otro: cerrar los cuatro caminos de acceso (contraseña, shell, caducidad de la cuenta y authorized_keys), retirar los privilegios (grupos, reglas de sudo, ACL, tareas de cron), cortar las sesiones vivas, inventariar y reasignar los ficheros, y rotar los secretos que esa persona conocía. El procedimiento completo con sus comandos es el ejercicio 2.

El paso más olvidado es retirar authorized_keys, y es demoledor: usermod -L bloquea la contraseña pero no impide entrar con clave pública, porque SSH ni consulta el hash cuando la autenticación es por clave. El segundo más olvidado es cortar sesiones: bloquear una cuenta no expulsa a quien ya está dentro.

Sobre borrar la cuenta con userdel -r: hazlo solo después de archivar lo necesario. Y ahí llega la advertencia obligada: la retención de datos de personas, los registros de acceso y los plazos de conservación tienen implicaciones legales (RGPD y normativa laboral); antes de fijar una política de borrado, consúltala con el responsable de cumplimiento normativo o con asesoría jurídica. No es una decisión técnica.

Autenticar es demostrar que eres quien dices ser, y todos los métodos caben en tres familias:

La autenticación multifactor (MFA) exige elementos de dos familias distintas: contraseña más pregunta de seguridad no es MFA —ambas son "algo que sabes"—; contraseña más código TOTP sí. Es la separación de privilegios de 05-01 aplicada a la identidad: dos condiciones independientes en vez de una.

La debilidad de la biometría merece énfasis porque suele venderse como la más fuerte: una huella comprometida es un problema permanente. Puedes cambiar una contraseña en diez segundos; no puedes cambiar de dedos. Por eso se usa correctamente como factor local —desbloquear un dispositivo que guarda la clave real— y no como credencial que viaje por la red. Para meteo-01 el objetivo es claro: SSH con clave pública (algo que tienes) protegida por frase de paso (algo que sabes), y segundo factor para el acceso desde fuera de la red de gestión.

Regla sin excepciones: una contraseña nunca se guarda, ni en claro ni cifrada de forma reversible. Se guarda el resultado de pasarla por una función de derivación de clave (KDF), y al autenticar se repite la operación y se comparan los resultados.

Por qué no vale SHA-256: porque está diseñado para ser rápido, y esa velocidad juega a favor del atacante —una GPU calcula miles de millones por segundo—. Una KDF de contraseñas se diseña con tres propiedades opuestas: sal única y aleatoria, que hace que dos usuarios con la misma contraseña produzcan hashes distintos e invalida las tablas precalculadas; coste de trabajo ajustable, para hacerla deliberadamente lenta y subir el coste según mejora el hardware; y coste en memoria, que anula la ventaja de las GPU y los ASIC, con mucho cálculo y poca memoria por unidad.

Y así se lee el campo real de /etc/shadow:

La sal se guarda en claro y está bien que así sea: no es un secreto, su función es garantizar que cada contraseña se ataque por separado, y el sistema la necesita para repetir el cálculo. Al autenticar, el sistema lee la línea, extrae algoritmo, parámetros y sal, recalcula con exactamente esos valores y compara en tiempo constante, para no filtrar información por el tiempo de respuesta.

El factor de coste es la palanca que compensa el avance del hardware: subirlo multiplica el trabajo de cada intento, para el sistema y para el atacante. El criterio práctico es fijarlo para que verificar una contraseña cueste entre 100 y 500 milisegundos en el hardware de producción: imperceptible para quien se autentica una vez, devastador para quien prueba millones. Vale igual para cualquier aplicación propia: nunca implementes tu esquema, usa libxcrypt, bcrypt o argon2 con parámetros revisados.

Descritos a nivel conceptual, para poder defenderse. No hay aquí instrucciones ni herramientas ofensivas: cada fila se cierra con la contramedida, que es lo que nos interesa.

La conclusión cuantitativa que ordena media tabla: la longitud vence a la complejidad. Con 95 caracteres imprimibles, cada carácter adicional multiplica el espacio de búsqueda por 95, mientras que sustituir una a por una @ lo multiplica por menos de dos —y los diccionarios de ataque conocen esa sustitución desde hace décadas—. Una frase de paso de cuatro palabras poco relacionadas es más resistente y mucho más memorable que P@ssw0rd!, que además cumple formalmente cualquier política de complejidad. Por eso las guías modernas recomiendan exigir longitud, no complejidad, y eliminar la caducidad periódica obligatoria, que solo produce incrementos predecibles: es la aceptabilidad psicológica de 05-01 convertida en política.

Tres comentarios que evitan problemas reales. deny=5 con unlock_time=900 convierte la fuerza bruta en inviable: 480 intentos al día frente a los millones por segundo que el ataque necesita. even_deny_root=0 es deliberado: si un atacante puede bloquear root probando contraseñas, ha conseguido una denegación de servicio contra la administración justo cuando más falta hace. Y el desbloqueo temporal es preferible al permanente, porque un bloqueo permanente convierte cualquier pulverización en la parálisis de la organización entera. Se consulta con faillock --user carlos y se limpia con --reset.

Antes de PAM, cada programa que autenticaba —login, su, sshd, passwd— llevaba su propio código, y añadir un método nuevo obligaba a recompilarlos todos. PAM (Pluggable Authentication Modules) mete una indirección: los programas llaman a la biblioteca, y esta consulta un fichero que decide qué módulos ejecutar y en qué orden.

La distinción entre auth y account es la que más cuesta y la más útil: una cuenta caducada se autentica correctamente —la contraseña es válida— y aun así no entra, porque la pila account lo deniega. Son dos decisiones independientes.

required frente a requisite tiene una justificación elegante: required sigue ejecutando la pila aunque ya sepa que va a fallar, para que un atacante no deduzca en qué punto falló midiendo el tiempo de respuesta.

La pila auth tiene truco. [success=1 default=ignore] significa "si pam_unix tiene éxito, salta 1 línea", con lo que se salta authfail y llega a pam_permit.so, que concede el acceso. Si la contraseña falla, no salta: ejecuta authfail —que incrementa el contador— y luego pam_deny.so. Es un salto condicional, y en cuanto lo ves así cualquier fichero de PAM se lee sin dificultad. En account, pam_nologin implementa un mecanismo muy útil: si existe /etc/nologin, nadie salvo root inicia sesión y se muestra su contenido; es la forma estándar de vaciar un servidor antes de una intervención.

Un cambio de política de ejemplo, restringir SSH a unos grupos y a un horario:

access.conf se lee de arriba abajo y la primera línea que casa decide: se permite explícitamente a root, carlos y el grupo admins, y la última deniega todo lo demás. Es exactamente el principio de valores por defecto seguros de 05-01.

Advertencia práctica. Un error en /etc/pam.d/ puede dejarte fuera del sistema de forma irrecuperable, incluido root. Mantén una sesión root abierta, abre otra para verificar el cambio, y ten a mano la consola física o el KVM. Si la nueva falla, la que sigue abierta te permite deshacer.

La criptografía asimétrica, en dos párrafos. Se generan dos claves relacionadas: una privada, que no sale nunca de tu máquina, y una pública, que puedes repartir sin riesgo. Lo que se hace con una solo se deshace con la otra, y —esto es lo esencial— conocer la pública no permite deducir la privada.

Para autenticar, el servidor envía un dato aleatorio y pide que se firme con la privada; quien la tiene produce una firma que el servidor verifica con la pública que ya guarda. La clave privada nunca viaja por la red, ni siquiera cifrada. Compáralo con una contraseña, que sí viaja —protegida por el canal, pero viaja— y que el servidor debe procesar: si el servidor está comprometido, tu contraseña se filtra; tu clave privada, no.

Los puntos que hay que entender. La clave se genera en tu máquina: si la generas en el servidor, la privada ha existido en un sistema que no controlas del todo y ha pasado por sus discos y sus copias. La frase de paso la convierte de facto en un doble factor: quien robe el fichero necesita además conocerla. Los permisos son obligatorios, no una recomendación: sshd rechaza un authorized_keys, un ~/.ssh o incluso un $HOME demasiado abiertos, porque quien pudiera escribir ahí añadiría su propia clave. Y el agente existe por aceptabilidad psicológica: sin él, teclear la frase cincuenta veces al día lleva derecho a eliminarla; -t 8h limita el daño si alguien se deja la sesión abierta.

Cada línea corresponde a un principio de 05-01. PermitRootLogin no es separación de privilegios y trazabilidad: obliga a entrar con la cuenta nominal y elevar con sudo, de modo que cada acción queda atribuida a una persona en lugar de a un root compartido. PasswordAuthentication no elimina de golpe diccionario, fuerza bruta, pulverización y reutilización: si no hay contraseña que probar, no hay ataque de contraseña. AllowGroups es lista blanca. Y AllowAgentForwarding no cierra un riesgo poco conocido: con reenvío activo, alguien con root en el servidor puede usar tu agente para saltar a otras máquinas donde tu clave vale.

Antes de cerrar la sesión: valida con sudo sshd -t, recarga con systemctl reload ssh y abre una segunda sesión para comprobar sin cerrar la primera. Deshabilitar las contraseñas sin haber probado la clave es la forma más común de perder el acceso a un servidor remoto.

Un administrador necesita privilegios de vez en cuando, no todo el día. Trabajar siempre como root viola el mínimo privilegio de la peor manera: un rm -rf mal escrito y no hay red de seguridad. Hay dos formas de subir, y son muy distintas.

La fila decisiva es la del secreto compartido: con su, la contraseña de root la conocen cinco personas y ninguna acción es atribuible; con sudo, la contraseña de root puede no existir siquiera —en Debian está bloqueada por defecto— y retirar el acceso es borrar una línea.

visudo no es opcional. Comprueba la sintaxis antes de guardar y se niega a escribir un fichero inválido; un /etc/sudoers con un error deja el sistema sin sudo, y si además PermitRootLogin no está activo y root no tiene contraseña, has perdido toda vía de administración salvo la consola física. La sintaxis de una regla es quién dónde = (como quién) qué comandos:

Los cuatro elementos importantes. Los Cmnd_Alias agrupan comandos y hacen la política legible, que es economía del mecanismo aplicada a la configuración. env_reset y secure_path son críticos: sin ellos, un usuario podría manipular PATH o variables como LD_PRELOAD para que el comando privilegiado cargue código suyo. timestamp_timeout=5 son los minutos de caché de la contraseña: 0 la pide siempre —seguro y cargante, y ya sabes a dónde lleva eso— y valores altos dejan una ventana si alguien deja el terminal desatendido. Y log_input, log_output graban la sesión completa de los comandos elevados, valiosísimo en una investigación.

Sobre NOPASSWD: su riesgo no es teórico. Convierte cualquier compromiso de la cuenta —una sesión abierta, una clave robada— en privilegio inmediato sin ninguna barrera, eliminando el segundo factor implícito de teclear la contraseña. Úsalo solo para comandos de solo lectura y sin argumentos libres, ejecutados por automatismos que no pueden teclear, y nunca con ALL.

Y la propiedad que hace de sudo una herramienta de seguridad y no solo de comodidad: toda elevación queda registrada, con éxito y con fracaso.

Cada línea contiene quién, desde dónde, como quién y qué. La segunda es justo el evento que debe disparar una alerta. Consulta tus propios permisos con sudo -l, los de otra persona con sudo -l -U nuria, y olvida la contraseña cacheada con sudo -k. El tratamiento sistemático de estos registros es Auditoría, Registros y Respuesta a Incidentes.

Escalada de privilegios es pasar a un dominio de protección con más autoridad —en el vocabulario de 05-01, un cambio de dominio no previsto—. La tratamos exclusivamente desde la defensa: qué configuraciones la hacen posible y cómo detectarlas. No se describen técnicas de explotación.

Cómo se interpreta. Los bloques [1] a [3] deben tener resultados fijos y conocidos; cualquier novedad exige explicación, y una cuenta de sistema con shell es justo lo que un atacante crea para persistir. [4] y [5] son detección por diferencia: no importa la lista completa, sino lo que ha aparecido desde la última vez; el [5] es el que más se olvida y menos ruido hace, porque ls -l no muestra las capabilities. [6] no marca errores sino cosas que revisar: cada NOPASSWD y cada comodín necesita una justificación escrita. [7] busca el patrón más rentable para un atacante: un fichero que él puede escribir y que root ejecuta solo. [8] debe ser lo más corto posible. Y [9] recuerda que un secreto tecleado queda en el historial en claro y para siempre, además de haber sido visible en ps mientras el comando corría.

Ninguna línea basta por sí sola. Juntas convierten un compromiso de la aplicación en un incidente acotado a la aplicación, que es el objetivo: no evitar todos los fallos —imposible— sino que un fallo no se propague.

Recordatorio de responsabilidad. Todo lo anterior sirve para auditar y defender sistemas propios. Cualquier comprobación de seguridad sobre un sistema ajeno requiere autorización expresa y por escrito del responsable; sin ella puede constituir un delito con independencia de la intención. Y las decisiones sobre cuentas, registros de acceso y conservación de datos personales tienen implicaciones de RGPD y de normativa laboral: revísalas con cumplimiento normativo o asesoría jurídica.

Creer que passwd -l cierra una cuenta. Bloquea la contraseña y no toca la autenticación por clave SSH. Una baja completa exige cuatro acciones —contraseña, nologin, caducidad y authorized_keys— más cortar las sesiones vivas.

Usar usermod -G sin -a. Sustituye toda la lista de grupos suplementarios en lugar de añadir, y deja a la persona fuera de sudo y de lo que tuviera. El efecto aparece días después.

Esperar que un cambio de grupo tenga efecto inmediato. Los grupos se fijan al iniciar sesión. id muestra el cambio porque relee el fichero, pero el proceso conserva sus credenciales: compara con /proc/<pid>/status y reinicia la sesión o el servicio.

Editar /etc/sudoers sin visudo. Un error de sintaxis deja el sistema sin sudo, y con root sin contraseña y sin acceso SSH directo has perdido la administración. Usa visudo y ficheros separados en /etc/sudoers.d/.

NOPASSWD: ALL "temporalmente". Elimina la única barrera ante una sesión secuestrada. Si sudo molesta tanto, sube timestamp_timeout; no elimines la contraseña.

Generar la clave SSH en el servidor. La privada debe nacer y morir en tu máquina; si la generas allí, ha existido en un sistema que quizá no controlas y ha pasado por sus copias de seguridad.

Deshabilitar PasswordAuthentication sin haber probado la clave. Es la forma más habitual de quedarse fuera de un servidor remoto. Valida, recarga y abre una segunda sesión antes de cerrar la primera. Lo mismo vale para cualquier cambio en /etc/pam.d/.

Confundir las pilas de PAM. auth responde a "¿es quien dice ser?" y account a "¿puede entrar ahora?". Una cuenta caducada se autentica bien y aun así no entra.

Auditar setuid y olvidar getcap. Un binario con cap_dac_override no muestra ninguna marca en ls -l. Mantén dos listas de referencia y compáralas periódicamente.

Consejo: usa sudo -l como reflejo. Antes de suponer qué puedes hacer, pregúntalo; y como administrador, sudo -l -U usuario es la forma más rápida de auditar los privilegios reales de una persona, incluidos los que le llegan por grupos que ya nadie recuerda.

Sobre tu máquina o una máquina virtual de pruebas: (a) interpreta campo a campo tu línea de /etc/passwd y la de una cuenta de servicio; (b) identifica el algoritmo, los parámetros y la sal de un hash real de /etc/shadow, y explica qué significan !, * y el campo vacío; (c) localiza todas las cuentas con UID 0, las de sistema con shell interactiva y las que no tienen contraseña, explicando por qué importa cada comprobación; (d) demuestra empíricamente que un usermod -aG no afecta a una sesión abierta, comparando id con /proc/$$/status.

La analista nuria deja la empresa. Tenía cuenta con shell, clave SSH instalada, pertenencia a adm, una entrada de ACL sobre /var/lib/meteora/lecturas (04-06), una regla en /etc/sudoers.d/nuria, una tarea de cron diaria, ficheros en /home/nuria y en /var/lib/meteora/export, y conocía la clave de API del proveedor de datos. Escribe el procedimiento completo de baja, ordenado, con el comando exacto de cada paso, la justificación de qué quedaría abierto si se omitiera, la verificación final, y qué decisiones deben consultarse con asesoría jurídica.

Diseña /etc/sudoers.d/meteora para tres perfiles: %meteora-ops, que arranca, para, reinicia y consulta meteo-api, ingestor y agregador y lee sus registros; %meteora-dba, que ejecuta la copia de seguridad y la restauración; y %monitoring, una cuenta automatizada que solo consulta el estado, sin contraseña. Justifica los Defaults. Después explica por qué estas tres reglas alternativas serían peligrosas y qué permitirían exactamente:

Solución 1

(a) carlos:x:1001:1001:Carlos Ruiz,Sistemas,,:/home/carlos:/bin/bash es nombre de sesión; x que remite a /etc/shadow; UID 1001, la identidad real ante el núcleo; GID primario; GECOS descriptivo; $HOME; y shell interactiva. La de servicio, www-data:x:33:33:...:/usr/sbin/nologin, difiere en tres puntos decisivos: UID por debajo de 1000, directorio funcional y nologin, que impide iniciar sesión aunque alguien conociera una credencial.

(b) $y$j9T$FvB2kXqR8mNpL4wZ$3xKm... se descompone por $: y es yescrypt; j9T son los parámetros de coste en tiempo y memoria; FvB2kXqR8mNpL4wZ es la sal, aleatoria por usuario y guardada en claro porque no es un secreto y el sistema la necesita para repetir el cálculo; el resto es el hash. ! es bloqueo reversible con el hash conservado detrás; * es "nunca la tuvo"; y vacío es acceso sin credencial.

(c) Las tres importan por razones distintas. Una segunda cuenta con UID 0 es root con otro nombre —la identidad es el número—, y es una técnica de persistencia que no aparece en ninguna lista de "administradores". Una cuenta de sistema con shell es una vía de inicio de sesión que no debería existir y un patrón habitual de puerta trasera. Y una cuenta sin contraseña entra sin credencial. En un sistema sano la primera devuelve solo root, la tercera nada, y la segunda solo casos justificados como sync.

(d)

La discrepancia es la demostración: id consulta el fichero, y el núcleo usa las credenciales que el proceso lleva encima desde que se creó. Los grupos suplementarios se fijan al iniciar sesión y se heredan por fork (02-01), así que solo una sesión nueva los incorpora. Es la explicación de "ya le he dado el grupo y sigue sin funcionar".

Solución 2

Justificación. El paso 0 va primero porque si bloqueas antes de inventariar pierdes la foto de lo que tenía, y esa foto es el punto de partida de cualquier investigación posterior.

En el paso 1, los cuatro subpasos cierran caminos independientes: (a) la autenticación por contraseña; (b) la obtención de shell aunque sobreviva alguna vía; (c) el acceso desde la pila account de PAM, con independencia de cómo se autentique. Y (d) es el imprescindible y el más olvidado: sin él, nuria sigue entrando por SSH exactamente igual que antes, porque la autenticación por clave pública no consulta el hash de la contraseña.

El paso 2 existe porque los privilegios están atados al nombre y al UID, no a la capacidad de iniciar sesión: si el UID 1002 se reasigna, la persona nueva heredaría la ACL, el grupo y la regla de sudo. La ACL por defecto es una entrada distinta de la normal y hay que quitar las dos, y una tarea de cron seguiría ejecutándose aunque la cuenta esté bloqueada. El paso 3 es necesario porque bloquear no expulsa a quien ya está dentro. El paso 4 evita los huérfanos de 04-06, que serían heredados por el próximo UID 1002; --acls conserva las ACL que un tar normal perdería en silencio. Y el paso 5 parte de que un secreto conocido por alguien que ya no está debe considerarse comprometido: no se puede "desconocer".

Asesoría jurídica. El borrado definitivo (userdel -r), el plazo de conservación del archivo de /home/nuria, el tratamiento de su correo y la conservación de los registros de acceso que la identifican tienen implicaciones de RGPD y de normativa laboral, donde las obligaciones de conservación pueden chocar con la minimización de datos. Deben acordarse con cumplimiento normativo o asesoría jurídica antes de ejecutarlas, y el procedimiento debe recogerlas por escrito para no improvisar en cada caso.

Solución 3

Los Defaults. env_reset y secure_path son los críticos: impiden manipular PATH, LD_PRELOAD u otras variables para que el comando privilegiado cargue código del usuario, algo que convertiría cualquier regla, por estrecha que sea, en ejecución arbitraria como root. timestamp_timeout=5 da cinco minutos de caché a operaciones frecuentes, equilibrio entre seguridad y aceptabilidad psicológica; para %meteora-dba se pone a 0 porque restaurar una copia es destructivo y poco frecuente, y debe confirmarse siempre. log_input, log_output graba las sesiones del grupo que más toca el servicio. Y el NOPASSWD de %monitoring es aceptable solo porque el comando es único, de solo lectura, sin argumentos libres y lo ejecuta un automatismo que no puede teclear.

Por qué las tres alternativas son peligrosas.

1. NOPASSWD: /usr/bin/systemctl *. El comodín cubre todos los subcomandos y todas las unidades del sistema, no solo las de Meteora: incluye parar el cortafuegos, parar auditd o deshabilitar SSH, y sobre todo los subcomandos que crean o editan unidades —quien pueda escribir una unidad hace que el sistema ejecute lo que quiera como root en el próximo arranque—. Con NOPASSWD, equivale a conceder root sin barrera alguna. Corrección: enumerar los comandos exactos con la unidad incluida, como en METEO_CTL.

2. /usr/bin/tar *. tar no se puede acotar con un comodín, por dos razones independientes. Al extraer como root, puede escribir en cualquier ruta absoluta contenida en el archivo —/etc/sudoers.d/, /root/.ssh/authorized_keys, /etc/shadow— y el contenido del archivo lo controla quien lo proporciona. Y admite opciones que ejecutan programas externos como parte de su funcionamiento normal, que con * quedan permitidas. Corrección: un script propio con ruta fija y parámetros validados, como METEO_BAK.

3. /usr/bin/vim /etc/meteora/meteora.conf. Parece la más acotada y es igual de peligrosa: los editores completos ejecutan comandos del sistema y abren otros ficheros desde dentro, así que una vez vim corre como root la restricción del argumento es irrelevante. Lo mismo vale para less, more, man, awk o find. Corrección: sudoedit (o sudo -e), que copia el fichero a un temporal, lo edita con los permisos del usuario y lo devuelve —el editor nunca corre como root—: %meteora-ops ALL=(root) sudoedit /etc/meteora/meteora.conf.

La lección general: una regla de sudo no acota lo que el usuario puede hacer, sino lo que puede ejecutar. Ante cualquier regla, pregúntate: ¿puede este comando, con estos argumentos, escribir un fichero arbitrario o ejecutar otro programa?

La identidad en Linux es un número, el UID; todo lo demás vive en ficheros de /etc que el núcleo ni siquiera lee, y de ahí la consecuencia que ordena la lección: quien controla el número controla la identidad, por lo que una segunda cuenta con UID 0 es root con otro nombre. Cada proceso lleva tres UID —real, efectivo y guardado— porque autoridad e identidad deben poder ser distintas y ambas estar disponibles: es lo que permite a passwd escribir en /etc/shadow con el efectivo mientras usa el real para saber a quién cambiarle la contraseña. Y soltar privilegio —setgroups, setgid, setuid, en ese orden, y verificar que no se puede volver atrás— es el mínimo privilegio en el tiempo hecho código.

Los tres ficheros se leen campo a campo. /etc/passwd tiene siete, con la x que recuerda por qué los hashes se sacaron de un fichero legible por todos, y un séptimo campo, nologin, que es toda una capa de defensa para meteora. /etc/shadow tiene nueve, y el segundo lo dice todo: $y$... es contraseña válida, ! bloqueo reversible, * "nunca la tuvo" y vacío es una emergencia. /etc/group guarda solo los miembros suplementarios, por lo que id es más fiable que leerlo. En el ciclo de vida, los dos puntos de riesgo son universales: la acumulación de privilegios en los cambios de rol, que solo corrigen las revisiones periódicas, y la baja, que debe cerrar cuatro caminos —contraseña, shell, caducidad y authorized_keys—, cortar sesiones, reasignar ficheros y rotar secretos, porque bloquear la contraseña no cierra el acceso por clave SSH.

En autenticación, los tres factores y la regla de que MFA exige dos familias distintas. Las contraseñas no se guardan: se derivan con una KDF que aporta sal única, coste de trabajo y coste en memoria, y por eso el $y$j9T$sal$hash de Debian se lee como algoritmo, parámetros, sal y resultado, con la sal en claro porque no es un secreto. Frente a diccionario, fuerza bruta, tablas precalculadas, reutilización y pulverización, las contramedidas son concretas: longitud antes que complejidad, pam_pwquality, pam_faillock con desbloqueo temporal y, sobre todo, MFA. PAM organiza todo eso en cuatro pilas —auth, account, password, session—, con banderas que se leen sin dificultad en cuanto entiendes que [success=1] es un salto condicional, y con la distinción entre autenticarse bien y poder entrar ahora repartida en pilas separadas.

Para meteo-01 la configuración correcta es clave pública con frase de paso y agente, con PermitRootLogin no y PasswordAuthentication no: si no hay contraseña que probar desaparece toda una familia de ataques, y entrar con la cuenta nominal hace que cada acción sea atribuible. La elevación se hace con sudo, no con su: granularidad por comando, sin compartir la contraseña de root, revocable borrando una línea y con registro de cada elevación. Sus trampas son NOPASSWD, los comodines y la más sutil: una regla de sudo no acota lo que el usuario puede hacer, sino lo que puede ejecutar, así que cualquier comando capaz de lanzar otros programas o escribir rutas arbitrarias concede root aunque la regla parezca estrecha. Y el catálogo defensivo de escalada de privilegios —setuid innecesarios, capabilities invisibles en ls -l, reglas amplias, comodines, scripts escribibles, tareas mal permisionadas, secretos en el entorno, servicios como root— se audita con detección por diferencia contra una línea base, porque lo que importa no es la lista completa sino lo que ha aparecido desde la última revisión.

Ya tenemos identidad y control de acceso. Pero todo lo anterior supone que el atacante entra por la puerta: que intenta autenticarse, que abusa de una regla, que usa una credencial. ¿Y si no lo hace? ¿Qué ocurre cuando el fallo está en el código de meteo-api y no hace falta ninguna credencial para dispararlo? ¿Qué clases de error de programación lo permiten, qué defensas pone el sistema operativo por debajo —ASLR, pila no ejecutable, canarios— y cómo se comprueba que están activas? ¿Y qué medidas concretas, en orden y con su justificación, convierten un Debian recién instalado en un servidor endurecido?

Eso es Amenazas Comunes y Endurecimiento del Sistema, donde clasificaremos las amenazas de un servidor real con el indicio que cada una dejaría en meteo-01, construiremos el modelo de amenazas de Meteora, veremos las clases de vulnerabilidad de programa y las defensas del núcleo, y montaremos el endurecimiento completo: cortafuegos, aislamiento con systemd, cifrado, gestión de secretos y copias de seguridad como control de seguridad.