sudo y permisos mínimos

Módulo 3: Usuarios, permisos y sudo · Tiempo de lectura: 11 minutos

Objetivo de aprendizaje: Después de esta lección, usted podrá trabajar como usuario normal con sudo, añadir un administrador de forma segura, modificar la configuración de sudo sin quedarse fuera y explicar por qué los permisos mínimos protegen su servidor.

Conceptos clave: sudo, grupo sudo, grupo wheel, /etc/sudoers, /etc/sudoers.d, visudo, NOPASSWD, sudo -l, bloquear root, registro de sudo, permisos mínimos (least privilege), usuario de servicio

¿Por qué no trabajar simplemente como root?

Después de la instalación, a menudo inicia sesión como root. Es cómodo: todo está permitido. Pero ese es precisamente el problema:

• Basta un error tipográfico. rm -rf / home/anna/oud (fíjese en el espacio después de la primera barra) borra todo su servidor si lo ejecuta como root. Como usuario normal, recibe un mensaje de error.
• Todo se ejecuta como root. Un script que copia de internet, un programa que está probando: todo obtiene permisos completos.
• No queda rastro. Si tres personas trabajan como root, después nadie sabe quién hizo qué.
• Root es el nombre que prueba todo atacante. Lo mejor es desactivar por completo el inicio de sesión como root (lección 2.2), pero solo puede hacerlo cuando tenga otra vía para obtener permisos de administración.

Esa otra vía es sudo: usted inicia sesión con su propio usuario y solo antepone sudo a los comandos que necesitan permisos de administración.

anna@web1:~$ apt update
E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
anna@web1:~$ sudo apt update
[sudo] password for anna:
Hit:1 http://deb.debian.org/debian trixie InRelease
...

(Desde la versión 25.10, Ubuntu utiliza por defecto sudo-rs, una nueva implementación de sudo. Para todo lo que se trata en esta lección funciona igual.)

sudo le pide su contraseña, no la de root. Después la recuerda durante un cuarto de hora por defecto, para que no tenga que introducirla en cada comando. Cada comando que ejecuta con sudo queda en el registro.

Crear un administrador

En Debian y Ubuntu, todos los miembros del grupo sudo pueden hacer cualquier cosa mediante sudo. Eso está en /etc/sudoers:

%sudo   ALL=(ALL:ALL) ALL

Léalo así: los miembros del grupo sudo (%) pueden ejecutar, en todas las máquinas (ALL), como cualquier usuario y grupo ((ALL:ALL)), cualquier comando (ALL).

Por tanto, añadir un administrador se hace en dos pasos, como root:

root@web1:~# adduser anna
root@web1:~# adduser anna sudo

A continuación, coloque la clave pública de Anna en /home/anna/.ssh/authorized_keys con el propietario y los permisos correctos:

root@web1:~# mkdir -p /home/anna/.ssh
root@web1:~# cp /root/.ssh/authorized_keys /home/anna/.ssh/
root@web1:~# chown -R anna:anna /home/anna/.ssh
root@web1:~# chmod 700 /home/anna/.ssh
root@web1:~# chmod 600 /home/anna/.ssh/authorized_keys

No olvide el chown: si root copia el archivo, el archivo pertenece a root, y entonces Anna no puede iniciar sesión con su clave.

Ahora pruebe, mientras mantiene abierta su sesión de root, en una segunda ventana:

anna@laptop:~$ ssh anna@192.0.2.10
anna@web1:~$ sudo -l
[sudo] password for anna:
User anna may run the following commands on web1:
    (ALL : ALL) ALL
anna@web1:~$ sudo whoami
root

Solo cuando esto funcione, configure PermitRootLogin no en sus ajustes de SSH (lección 2.2). A partir de ese momento, inicie sesión siempre como Anna.

Algo que debe recordar: Anna necesita ahora una contraseña para sudo. Guárdela en su gestor de contraseñas. El inicio de sesión se hace con la clave y sudo con la contraseña: dos cosas distintas que un intruso tendría que conseguir.

Modificar la configuración de sudo: siempre con visudo

Un error en /etc/sudoers puede hacer que sudo deje de funcionar por completo. Si además root no puede iniciar sesión, se queda bloqueado. Por eso nunca edita la configuración de sudo con un editor normal, sino con visudo. Este abre una copia temporal y comprueba el contenido antes de guardarlo:

root@web1:~# visudo -f /etc/sudoers.d/backup

Igual que con SSH, es preferible usar un archivo propio en /etc/sudoers.d/ en lugar del archivo principal. Tenga en cuenta dos reglas de ese directorio:

• Los archivos cuyo nombre contiene un punto o termina en ~ se ignoran. Así que backup.conf no funciona, pero backup sí. Está pensado para ignorar las copias que crean los editores, pero sorprende a mucha gente.
• El archivo debe pertenecer a root y no debe poder ser modificado por otros (lo habitual es 440; visudo se encarga de ello).

Si desea comprobar un archivo existente sin editarlo: visudo -c lo comprueba todo.

NOPASSWD: práctico, pero sepa lo que hace

Con NOPASSWD, sudo ya no pide contraseña:

anna ALL=(ALL:ALL) NOPASSWD: ALL

Algunas imágenes de VPS configuran esto para el usuario predeterminado, de modo que al iniciar sesión con una clave ya es administrador. Compruebe con sudo -l qué se aplica en su caso. La consecuencia: quien tenga la clave de Anna es root de inmediato. Ya no hay una segunda cerradura. En un servidor personal puede optar por ello, pero hágalo de forma consciente.

Es mucho mejor usar NOPASSWD solo para un comando concreto, por ejemplo para un script de copia de seguridad que debe poder ejecutarse automáticamente:

backup ALL=(root) NOPASSWD: /usr/local/bin/maak-backup

El usuario backup puede entonces ejecutar exactamente ese script como root, sin contraseña, y nada más. Dos trampas:

• Use siempre la ruta completa. Con solo maak-backup, alguien podría colocar un programa propio con ese nombre al principio de su ruta.
• El propio script no debe poder ser modificado por ese usuario. De lo contrario, podría cambiarlo y ejecutar comandos arbitrarios como root. Lo mismo vale para los comandos que pueden abrir una shell por sí mismos, como un editor (vim, nano) o less: quien pueda iniciarlos mediante sudo puede abrir una shell de root desde el programa. Nunca conceda esos comandos por separado mediante sudo.

Qué se registra

Cada vez que alguien usa sudo, se escribe una línea en el journal (y, en sistemas con rsyslog, también en /var/log/auth.log):

anna@web1:~$ sudo journalctl _COMM=sudo --since today
Nov 09 10:31:02 web1 sudo[2214]:     anna : TTY=pts/0 ; PWD=/home/anna ; USER=root ; COMMAND=/usr/bin/apt update

Puede ver quién, desde dónde, como quién y qué comando. Es una de las razones para no trabajar varias personas como root. Los intentos fallidos de sudo ("incorrect password attempts", es decir, intentos con contraseña incorrecta) desde una cuenta que no es la suya son una señal de alarma.

Permisos mínimos a gran escala

sudo es una aplicación de un principio general: permisos mínimos (least privilege). Cada usuario y cada servicio recibe exactamente los permisos que necesita, y no más. En un servidor, eso significa, entre otras cosas:

• usted trabaja como usuario normal y solo usa sudo cuando es necesario;
• cada servicio se ejecuta con su propio usuario sin shell (lección 3.1), no como root;
• una aplicación web recibe un usuario de base de datos que solo puede usar su propia base de datos, no el administrador del servidor de bases de datos;
• un script de copia de seguridad solo puede ejecutar el único comando que necesita (NOPASSWD con ruta completa);
• un compañero que solo actualiza el sitio web recibe permiso de escritura en /var/www/example.com mediante un grupo, no sudo.

La idea: si algo sale mal (una vulnerabilidad en un plugin, una clave robada), el daño queda limitado a ese único usuario o servicio. Este principio aparece una y otra vez en los principios de CIS y en la lección de hardening (10.1).

En AlmaLinux y Rocky Linux

Allí el grupo de administradores se llama wheel en lugar de sudo: usermod -aG wheel anna. La línea en /etc/sudoers es %wheel ALL=(ALL) ALL. visudo y /etc/sudoers.d funcionan igual. Los mensajes de sudo se encuentran allí también en /var/log/secure.

Resumen

• Trabaje como usuario normal y use sudo para la administración; sudo pide su propia contraseña y registra cada comando.
• Crear un administrador: adduser anna, adduser anna sudo (wheel en sistemas tipo RHEL), clave con el propietario y los permisos correctos, prueba en una segunda ventana y solo entonces desactivar el inicio de sesión como root.
• Edite las reglas de sudo solo con visudo, preferiblemente en un archivo propio en /etc/sudoers.d/ sin punto en el nombre.
• NOPASSWD para todo elimina una cerradura; es mejor usarlo solo para un comando con ruta completa que el usuario no pueda modificar.
• Permisos mínimos: cada usuario y servicio recibe exactamente lo que necesita, para que un error o una vulnerabilidad tenga un alcance reducido.

Cuestionario

Ejercicio

Ejercicio O3.2: Un administrador con sudo. Cree en su servidor un administrador normal (por ejemplo anna), coloque bien su clave, pruebe el inicio de sesión y sudo -l en una segunda ventana y, después, desactive el inicio de sesión como root por SSH (PermitRootLogin no). Marque los pasos, pegue la salida de id (solo nombre y grupos) y responda a las preguntas: ¿qué línea da permisos a su administrador?, ¿aparece NOPASSWD en algún sitio? y ¿cómo entra si olvida su contraseña?

Para saber más

Los pasos de estos artículos se aplican a los VPS de WebOké; con otros proveedores funciona de forma similar.

• Proteger su VPS: los primeros cinco minutos
• Sin acceso a su VPS: ¿qué hacer?
• Manual de DirectAdmin 12.2: Usuarios, permisos y contraseñas de la base de datos
• Ubuntu Server: User management: https://ubuntu.com/server/docs/how-to/security/user-management/
• Manual de Debian sobre sudoers: https://manpages.debian.org/trixie/sudo/sudoers.5.en.html