Capítulo 4. Autenticación y controles de acceso

Aquí están algunos de los archivos de configuración más importantes usados por PAM y NSS.

Las normas para la selección de contraseñas se desarrolla en los módulos PAM, pam_unix(8) y pam_cracklib(8). Se pueden configurar por sus parámetros.

	Sugerencia
	Los nombres de archivos de los módulos de PAM usan el sufijo «.so».

La gestión moderna de sistemas centralizados puede desplegarse empleando un servidor central LDAP (Protocolo Ligero de Acceso a Directorios) que administre los sistemas en la red, sean estos tipo Unix o de otro tipo. La implementación de código libre de este protocolo es el software OpenLDAP.

El servidor LDAP proporciona información de la cuenta mediante PAM y NSS con los paquetes libpam-ldap y libnss-ldap del sistema Debian. Se necesitan distintas acciones para activarlo (La siguiente configuración no está comprobada y es información totalmente secundaria. Por favor léala en este contexto).

Consulte los documentos pam_ldap.conf(5) y «/usr/share/doc/libpam-doc/html/» que contiene el paquete libpam-doc e «info libc 'Name Service Switch'» que contiene el paquete glibc-doc.

De forma parecida, se pueden instalar sistemas centralizados para otro métodos.

Esta frase famosa al final de la página antigua de «info su» de Richard M. Stallman. Para no preocuparse: la orden actual su en Debian usa PAM, así este puede limitar el uso de su al grupo root habilitando la línea «pam_wheel.so» en «/etc/pam.d/su».

# here are the per-package modules (the "Primary" block)
password	requisite			pam_cracklib.so retry=3 minlen=8 difok=3
password	[success=1 default=ignore]	pam_unix.so obscure use_authtok try_first_pass yescrypt
# here's the fallback if no module succeeds
password	requisite			pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password	required			pam_permit.so
# and here are more per-package modules (the "Additional" block)
password	optional	pam_gnome_keyring.so
# end of pam-auth-update config

Los servicios de la capa de transporte más usados usan mensajes que incluyen la acreditación mediante contraseñas en texto plano. Es una mala idea emitir contraseñas en texto plano en una red descentralizada donde se pueden interceptar. Puede ejecutar estos servicios sobre la «Capa de Transporte Segura« (TLS) o su predecesor «Secure Sockets Layer« (SSL) para asegurar por medio del cifrado todas las comunicaciones incluidas las contraseñas.

El coste de tiempo de CPU del cifrado. Como alternativa más eficiente para la CPU, se pueden mantener las comunicaciones en texto plano y securizando la contraseña con el protocolo de acreditación como «Protocolo de Acreditación de Oficina de Correos (Authenticated Post Office Protocol, APOP )« para POP y «Mecanismo de acreditación reto-respuesta MD5(Challenge-Response Authentication Mechanism MD5, CRAM-MD5)« para SMTP e IMAP. (Para el envío de mensajes de correo en Internet a su servidor de correo desde su cliente de correo, se ha vuelto usual el uso del puerto 587 para la recepción de mensajes en vez del tradicional puerto 25 SMTP para evitar el bloqueo del puerto 25 por el proveedor de red mientras se acredita con CRAM-MD5.)

El programa Secure Shell (SSH) ofrece comunicaciones cifradas seguras entre dos equipos no confiables sobre una red insegura con acreditación segura. Consiste en el cliente OpenSSH, ssh(1) y el demonio OpenSSH, sshd(8). Este SSH se puede usar para realizar un túnel de un protocolo de comunicación inseguro como es POP y asegurar X sobre Internet con la funcionalidad de reenvío de puerto (port forwarding).

El cliente intenta acreditarse a si mismo usando la acreditación basada en equipos, acreditación de clave pública, acreditación reto-respuesta, o acreditación por contraseña. El uso de acreditación por clave pública permite acceso remoto sin contraseña. Consulte Sección 6.3, “Servidor de acceso remoto (SSH) y utilidades”.

Incluso si ejecutas servicios de seguridad como Secure Shell (SSH) y protocolo de tunelización punto a punto (PPTP), En Internet, todavía existe la oportunidad de obtener acceso mediante ataques de adivinación de contraseñas de fuerza bruta. El uso de una política de firewall (ver Sección 5.7, “Infraestructura Netfilter”), junto con las siguientes herramientas de seguridad, puede mejorar la situación de seguridad.

Para evitar que las personas accedan a tu máquina con privilegios de root, debes realizar las siguientes acciones.

• Impide el acceso físico al disco duro

• Bloquee UEFI/BIOS y evita el arranque desde los medios extraíbles

• Asigne una contraseña a las sesiones interactivas de GRUB

• Bloquee la edición del menú de GRUB

Si tienes acceso físico al disco duro, puedes restablecer la contraseña con relativa facilidad siguiendo los siguientes pasos.

1. Lleve el disco duro a un ordenador que pueda configurar UEFI/BIOS para que arranque desde un CD.

2. Arranque el sistema con un medio de rescate (disco de arranque Debiam. Knoppix CD, GRUB CD, ...).

3. Monte la partición raíz con permisos de lectura/escritura.

4. Edita "/etc/passwd" en la partición root y haz que la segunda entrada para la cuenta root esté vacía.

Si tienes acceso de edición a la entrada del menú del GRUB (consulta Sección 3.1.2, “Fase 2: el cargador de arranque”) para grub-rescue-pc en el momento del arranque, es aún más fácil con los siguientes pasos.

El intérprete de órdenes del superusuario del sistema es accesible sin contraseña.

La única solución software razonable es evitar lo anterior con la utilización de software que cifra la partición raíz (o la partición «/etc») usando dm-crypt e initramfs (ver Sección 9.9, “Trucos para cifrar información”). Sin embargo, siempre necesitará la contraseña para arrancar el sistema.

Las ACL son un superconjunto de los permisos normales, como se explica en Sección 1.2.3, “Permisos del sistema de archivos”.

En los entornos de escritorio modernos, las ACL entran en acción. Cuando un dispositivo de almacenamiento USB formateado se monta automáticamente como, por ejemplo, "/media/penguin/USBSTICK", un usuario normal penguin puede ejecutarlo:

 $ cd /media/penguin
 $ ls -la
total 16
drwxr-x---+ 1 root    root    16 Jan 17 22:55 .
drwxr-xr-x  1 root    root    28 Sep 17 19:03 ..
drwxr-xr-x  1 penguin penguin 18 Jan  6 07:05 USBSTICK

"+" en la undécima columna indica que las ACL están en acción. Sin ACLs, un usuario normal pingüino no debería poder listar así ya que pingüino no está en el grupo root. Puedes ver ACLs como:

 $ getfacl .
# file: .
# owner: root
# group: root
user::rwx
user:penguin:r-x
group::---
mask::r-x
other::---

Aquí:

Ver "Listas de control de acceso POSIX en Linux", acl(5), getfacl(1) y setfacl(1) para más información.

sudo(8) es un programa diseñado para permitir que el administrador de sistemas conceda ciertos privilegios de superusuario a los usuarios y registre su actividad. sudo necesita únicamente la contraseña del usuario normal. Una vez instalado el paquete sudo la configuración se realiza en el archivo «/etc/sudoers». Ver una configuración de ejemplo en «/usr/share/doc/sudo/examples/sudoers» y Sección 1.1.12, “Configuración de sudo”.

En un sistema monousuario, el uso que yo realizo de sudo (verSección 1.1.12, “Configuración de sudo”) pretende evitar mi propia estupidez. Personalmente, considero el uso de sudo como la mejor alternativa al uso de la cuenta de superusuario de forma constante. Por ejemplo, lo siguiente cambia el dueño de «un_archivo» a «mi_nombre».

$ sudo chown my_name some_file

Desde luego si conoce la contraseña de «root« (como la conoce cualquier usuario que se instala Debian), cualquier orden puede ser ejecutada por «root« desde cualquier cuenta de usuario utilizando «su -c».

PolicyKit es un componente del sistema operativo con el fin de controlar los privilegios del sistema en toda su extensión para sistemas operativos tipo Unix.

Los nuevas aplicaciones de interfaz gráfico de usuario no están diseñadas para ejecutarse como procesos privilegiados. Se comunican con los procesos privilegiados a través de PolicyKit realizando de forma eficiente las operaciones administrativas.

PolicyKit restringe cada operación a cuentas de usuario que pertenecer al grupo sudo en el sistema Debian.

Ver polkit(8).

Para la seguridad del sistema, es una buena idea deshabilitar tantos programas del servidor como sea posible. Esto es crítico en servidores en red. Tener servidores sin utilidad, ejecutándose como demonios o por medio de un programa super servidor, se considera un riesgo de seguridad.

Muchos programas, como sshd(8), utilizan PAM como control de acceso. Existen muchas maneras de limitar el acceso a algunos servicios de servidor.

Ver Sección 3.5, “Gestión del sistema”, Sección 4.5.1, “Archivos de configuración utilizados por PAM y NSS”, y Sección 5.7, “Infraestructura Netfilter”.

El kernel de Linux ha evolucionado y admite características de seguridad que no se encuentran en las implementaciones tradicionales de UNIX.

Linux soporta atributos extendidos que amplían los atributos tradicionales de UNIX (ver xattr(7)).

Linux divide los privilegios tradicionalmente asociados con el superusuario en distintas partes, conocidas como capacidades(7), que se puede habilitar y deshabilitar de forma independiente. Las capacidades son un atributo por subproceso desde la versión 2.2 del kernel.

La infraestructura Linux Security Module (LSM proporciona un mecanismo para varias pruebas de seguridad para que sean unidas por nuevas extensiones del kernel. Por ejemplo:

Dado que estas extensiones pueden endurecer el tipo de privilegio más estricto que las políticas ordinarias de tipo de seguridad similares a las de Unix, incluso se puede restringir el poder de root. Recomendamos leer el documento marco de Linux Security Module (LSM) en kernel.org.

Linux namespaces empaqueta un recurso del sistema global en una abstracción que hace aparecer a los procesos dentro del espacio de nombres que tienen su propia instancia aislada del recurso global. Los cambios en el recurso global son visibles a otros procesos que son miembros del espacio de nombres, pero son invisibles a otros procesos. Desde el kernel 5.6, hay 8 tipos de espacios de nombres (ver namespaces(7), unshare(1), nsenter(1)).

A partir de Debian 11 Bullseye (2021), Debian utiliza jerarquía de grupos unificados (a.k.a. cgroups-v2).

Ejemplos de uso de namespaces con cgroups para aislar sus procesos y permitir el control de recursos son:

Estas funcionalidades no se pueden realizar por Sección 4.1, “Acreditación normal de Unix”. Estos temas avanzados están fuera del alcance de este documento introductorio.