Gestión Usuarios Linux: Permisos y Seguridad Práctica

Cuando tuve que limpiar los accesos en una organización sanitaria pública con 2.000 endpoints, encontré 47 cuentas con privilegios root. Cuarenta y siete. Algunas pertenecían a consultores que no trabajaban allí desde hacía tres años. La gestión usuarios linux no es un ejercicio académico. Es la línea de defensa que separa un servidor bajo control de un servidor vulnerado. Si cualquiera puede convertirse en root, tu SIEM no te salvará. Si los archivos de configuración tienen permisos 777, cualquier script malicioso los sobrescribe. Aquí abordamos exactamente cómo crear, modificar y eliminar usuarios, asignar los permisos correctos y auditar el acceso. Sin teoría inútil, solo comandos listos para producción. Lee también: Fail2ban on Linux: Complete Setup and SSH Hardening

Requisitos Previos / Entorno de Prueba

Necesitas un terminal con acceso root o un usuario con privilegios sudo. Cualquier distribución moderna sirve. Recomiendo usar una VM en Proxmox o un entorno de laboratorio antes de aplicar estos comandos en un servidor en producción. Evita probar la eliminación de usuarios o cambios masivos de permisos directamente en tu máquina de trabajo.

Usuarios, grupos y UID/GID: Cómo funciona Linux internamente

Para gestionar usuarios linux de forma eficaz, debes entender cómo el sistema los identifica. Linux no conoce los nombres de usuario internamente. Conoce solo números. El UID (User ID) identifica al usuario, el GID (Group ID) identifica al grupo primario. El UID 0 es root. Si un usuario tiene UID 0, es root, independientemente del nombre que le des.

Los datos residen en tres archivos críticos:

• /etc/passwd: mapea el nombre de usuario a UID, GID, shell y directorio home.
• /etc/shadow: contiene los hashes de las contraseñas. Solo root puede leerlo.
• /etc/group: define los grupos y miembros suplementarios.

Si abres /etc/passwd y ves una shell /bin/bash en una cuenta de servicio, tienes un problema. Las cuentas de servicio no deben hacer login interactivo. La shell debe ser /usr/sbin/nologin.

Crear y gestionar usuarios y grupos: adduser, usermod, userdel

El primer error que veo a menudo es usar useradd en lugar de adduser. En Debian y Ubuntu, useradd crea el usuario pero no configura el directorio home, no establece la contraseña y no copia los archivos skeleton. adduser es un script Perl interactivo que hace todo correctamente.

Para crear un nuevo usuario:

sudo adduser nombreusuario

El comando pedirá la contraseña, el nombre completo y creará automáticamente /home/nombreusuario copiando los archivos de /etc/skel.

Si este usuario necesita privilegios administrativos, no le des la contraseña de root. Añádelo al grupo sudo:

sudo usermod -aG sudo nombreusuario

El flag -aG es fundamental. Significa append to supplementary Group. Si omites -a, eliminarás al usuario de todos los demás grupos suplementarios a los que pertenece, aislándolo y rompiendo probables configuraciones de acceso.

Cuando un consultor deja la empresa, la cuenta debe desaparecer. No la desactives solamente. Elimínala junto con su directorio home:

sudo userdel -r nombreusuario

El flag -r elimina el home y la cola de correo. Si no lo usas, dejarás archivos huérfanos en el sistema de archivos, archivos de los que nadie se hace responsable.

Para los grupos, si tres desarrolladores deben escribir en el mismo directorio, no establezcas permisos por usuario individual. Crea un grupo:

sudo groupadd developers
sudo usermod -aG developers nombreusuario

Para ver a qué grupos pertenece un usuario, usa id nombreusuario. El output muestra el UID, el grupo primario (GID) y todos los grupos suplementarios.

Si necesitas eliminar un usuario de un grupo específico sin tocar los demás, usa gpasswd:

sudo gpasswd -d nombreusuario developers

Para más detalles sobre la gestión de grupos y archivos de configuración, consulta la documentación oficial de Shadow utils: https://man7.org/linux/man-pages/man5/passwd.5.html

Permisos y propiedad de archivos: chmod, chown y bits especiales

Cada archivo en Linux tiene tres categorías de acceso: User (propietario), Group (grupo propietario), Other (todos los demás). Cada categoría puede tener permisos de Read (4), Write (2) y Execute (1).

La notación octal suma estos valores. 7 significa 4+2+1 (Lectura, Escritura, Ejecución). 5 significa 4+1 (Lectura, Ejecución).

Para hacer un script ejecutable por el propietario y legible por todos:

chmod 755 script.sh

La notación simbólica es más selectiva cuando debes modificar un solo permiso sin alterar los demás:

chmod u+x,g-w,o-r archivo.txt

Un aviso sobre los permisos 777. Significa que cualquiera puede leer, escribir y ejecutar. No lo uses jamás en producción. Si un atacante obtiene acceso mediante un servicio comprometido, lo primero que hará será escribir un script en un directorio con permisos 777 y hacer que el propietario del proceso lo ejecute.

Los permisos se aplican siempre según el propietario y el grupo. Si asignas permisos al grupo equivocado, el acceso no funcionará. Para cambiar propietario y grupo de un archivo específico:

chown usuario:grupo archivo.txt

En los servidores web, el problema más común es tener archivos propiedad de root mientras el proceso Apache o Nginx corre como www-data. El resultado es un error 403 Forbidden cuando la aplicación intenta escribir un log o subir una imagen. La corrección estándar para la document root:

chown -R www-data:www-data /var/www/

El flag -R aplica el cambio recursivamente a todos los archivos y subdirectorios. Atención: úsalo solo donde sea necesario. Si cambias recursivamente el propietario de /etc, romperás el sistema de forma irreversible. Para cambiar solo el grupo, usa chgrp.

Respecto a los permisos especiales, el bit SUID (Set-owner User ID) ejecuta un archivo con los privilegios del propietario, no de quien lo lanza. El ejemplo clásico es /usr/bin/passwd. Debe correr como root para modificar /etc/shadow, pero un usuario normal debe poder cambiar su propia contraseña. El problema surge cuando encuentras archivos SUID que no deberían serlo. Un atacante que explota una vulnerabilidad en un archivo SUID se convierte instantáneamente en root. Encuentra todos los archivos con bit SUID activo en el sistema:

find / -perm -4000 -type f 2>/dev/null

Compara el output con una lista conocida de binarios SUID legítimos de tu sistema operativo. Si encuentras algo anómalo en /tmp o /home, investiga de inmediato.

El bit SGID (Set-Group ID) en directorios hace que cada nuevo archivo creado herede el grupo del directorio, en lugar del grupo primario del usuario. Es útil para los directorios compartidos del equipo.

El sticky bit se usa casi exclusivamente en el directorio /tmp. Permite a los usuarios crear archivos dentro del directorio, pero solo el propietario del archivo (o root) puede eliminarlo. Sin sticky bit, cualquier usuario podría borrar los archivos temporales de los demás.

sudo y /etc/sudoers: Delegar privilegios con seguridad

Distribuir la contraseña de root es un error de seguridad básico. Usa sudo. Permite delegar comandos específicos a usuarios específicos, con registro completo de quién hizo qué.

Nunca modifiques directamente /etc/sudoers con un editor de texto. Si cometes un error de sintaxis, sudo deja de funcionar y te quedas bloqueado fuera del sistema. Usa siempre:

sudo visudo

visudo abre el archivo en un editor, pero antes de guardar verifica la sintaxis. Si hay un error, te avisa y no guarda los cambios.

Para delegar un comando específico, crea un archivo en /etc/sudoers.d/. Es más limpio y fácil de gestionar que modificar el archivo principal. Por ejemplo, para permitir al usuario backupadm lanzar solo los comandos de backup sin contraseña:

backupadm ALL=(ALL) NOPASSWD: /usr/local/bin/backup.sh

Limita siempre los comandos al mínimo indispensable. Un usuario con NOPASSWD: ALL es de facto root sin contraseña.

Errores Comunes y Resolución de Problemas

• Error: usermod -G grupo usuario elimina al usuario de sus otros grupos suplementarios.

Solución: Usa siempre el flag -a junto con -G (usermod -aG grupo usuario) para añadir sin eliminar.

• Error: sudo: syntax error in /etc/sudoers tras editar con nano o vim.

Solución: Nunca edites sudoers directamente. Usa sudo visudo para que verifique la sintaxis antes de guardar.

• Error: Error 403 Forbidden en Nginx/Apache al escribir logs o subir archivos.

Solución: Verifica que el propietario del directorio sea el usuario del servicio web (www-data) usando chown -R www-data:www-data /var/www/.

• Error: El agente SSH rechaza la clave privada.

Solución: Los permisos de ~/.ssh deben ser 700 y authorized_keys 600. Cualquier otro permiso hará que sshd ignore la clave por seguridad.

Conclusiones con Puntos Clave Operativos

Aplica estos controles en cada nuevo servidor antes de ponerlo en producción.

1. Desactiva el login root directo. En /etc/ssh/sshd_config, establece PermitRootLogin no.
2. Elimina las shells de login de las cuentas de servicio. Usa /usr/sbin/nologin.
3. Verifica los archivos SUID. Compara la salida de find / -perm -4000 -type f con la baseline del sistema operativo.
4. Controla los permisos de las claves SSH. El directorio ~/.ssh debe ser 700, el archivo authorized_keys debe ser 600.
5. Configura sudo con visudo. Delega solo los comandos necesarios. Nada de NOPASSWD: ALL a menos que esté estrictamente justificado y documentado.
6. Establece el sticky bit en directorios world-writable como /tmp.
7. Usa lastlog para identificar y eliminar las cuentas inactivas durante más de 90 días.

La seguridad no es un producto, es un proceso. Gestionar usuarios y permisos Linux requiere constancia. Un servidor configurado perfectamente hoy se vuelve inseguro en seis meses si nadie controla quién accede y qué dejan por ahí. Automatiza estos controles con scripts bash o Ansible, pero antes asegúrate de haberlos entendido a fondo manualmente.