Transparencias de clase sobre “Gestión de usuarios y LDAP”

Continúo con la publicación de viejas transparencias de clase; en este caso, la primera que publico de las clases de Administración de Sistemas Operativos en Red que impartí entre 1999 y 2012 y del que todavía hoy (literal) he tenido que preparar y realizar un examen.

Con esta presentación estudiábamos en clase los módulos PAM, cómo llegar a ser root y compartir privilegios (su y sudo) y cómo usar un directorio para centralizar la autenticación y autorización de los usuarios de un sistema con GNU/Linux.

La clase duraba 1 hora y media y no teníamos tiempo para más. Si no, podríamos haber incluido profundizado con otros temas, como por ejemplo: 2FA.

¡Espero que os sea útil!


Fortificando la autenticación de usuarios en WordPress

Al margen de la elección de contraseña, es una opinión, y cada vez más generalizada, que para aumentar la seguridad en la autenticación de los usuarios, debemos recurrir a sistemas MFA (Multi-Factor Authentication). Estos sistemas consisten en incluir diferentes factores de autenticación (2 o más): uno basado en algo que conocemos (por ejemplo, el clásico de la contraseña); otro en algo que poseemos (el móvil, por ejemplo) y/o algo que solo es el usuario (por ejemplo, su huella o cualquier característica biométrica).

Si queremos mejorar la seguridad de nuestro blog, existen pluggins que implementan un mecanismo 2FA (doble factor de autenticación) basado en Google Authenticator. En este blog estoy probando: WP Google Authenticator.

Es muy fácil de utilizar:

  1. Lo instalamos (Plugins>Añadir Nuevo y tras esto: Activar)
  2. Tras este proceso, en Ajustes, tendremos las opciones del plugin. En mi caso activé que el número máximo de veces que se puede autenticar un usuarios sin 2FA sea de 3)
  3. En Usuarios>Tu Perfil, abajo aparece información importante. Por un lado, el botón Get QR Code al que pulsaremos para obtener el código QR  sincronizará la aplicación Google Authenticator de nuestro móvil con el plugin. Para esto:
    • Arranqueremos en nuestro móvil Google Authenticator,
    • En Menú: Configurar Nueva cuenta,
    • Escanear código ¡et voila!
  4. Además en Usuario>Tu perfil tendremos el código de recuperación y tu clave secreta que no debes compartir con nadie.

Ahora, cada vez que queremos acceder al control de nuestro WordPress, nos encontraremos con:

Captura de pantalla de 2014-07-30 12:57:32

Quien disponga de un hosting propio al que se conecte con sesiones de trabajo que quiere fortalecer, también podemos utilizar Google Authenticator para implementar  un 2FA en el servicio SSH. Esto, en otra entrada que publicaré en breve 😉


Super User DO

SuDO es una herramienta que, como comentamos en esta entrada anterior, nos permite realizar una buena gestión de privilegios e implementar una administración compartida de los sistemas. En general, lo que nos permite es ejecutar las órdenes deseadas con los identificadores de usuario (UID y EUID) y grupo (GID y EGID) necesarios para su correcta ejecución, no es necesario que sea solo para  root. En el caso (bastante deseable) de que se necesite autenticar al usuario, esta acción se realizará con la contraseña del usuario que ejecuta la orden y no con la del usuario objetivo (es decir, NO con la de root).

La instalación es sencilla (sistemas Debian):

apt-get install sudo

Para la configuración: /etc/sudoers

Este es un fichero de texto en el que, cada línea, debe seguir la siguiente sintaxis:

[usuario/%grupo] [equipo] = [(id:gid del usuario objetivo)] órdenes

También admite alias con esta sintaxis:

alias nombre = elemento_alias

Los alias pueden ser de órdenes: Cmnd_Alias para lista de órdenes; User_alias para listas de usuarios; Host_alias, para listas de equipos

Un ejemplo de /etc/sudoers que usamos en la EPS es:

Cmnd_Alias CMDADMIN = /sbin/shutdown, /etc/init.d/sshd, /etc/init.d/network, /etc/init.d/rsysklog, /etc/init.d/nscd, /etc/init.d/tomcat, /etc/init.d/httpd, /etc/init.d/apache2
User_Alias USRWWWDATA = www-data, wwwadm
USRWWWDATA ALL= NOPASSWD: CMDWWWDATA

En este ejemplo se han definido 2 alias: CMDADMIN con la lista de comandos que van a poder ejecutar los usuarios listados en USRWWWDATA.

La última línea habilita la ejecución de las órdenes listadas en CMDWWWDATA por los usuarios definidos en USRWWWDATA como si las estuviera ejecutando el usuario root (no pone usuario objetivo por lo que es root). La expresión “como si las estuviera ejecutando” es una forma de expresarme. Como he comentado antes, la ejecución es con UID, EUID, GID y EGID de root (para este caso, en otros, con el del usuario objetivo.

De esta forma, los usuarios wwwadm y www-data pueden parar, reiniciar, lanzar Apache, Tomcat, nscd, ssh,… sin necesidad de conocer la contraseña del administrador.

También podríamos usar la directiva Defaults con la que podríamos definir determinadas opciones globales de comportamiento de sudo. Un uso interesante es:

Defaults env_reset, timestamp_timeout=1,passwd_timeout=2,passwd_tries=1

que implica que los usuarios tendrán:

  • Un solo intento de autenticación (passwd_tries=1),
  • tiempo de sesión sin solicitar de nuevo la contraseña de 1 minuto (timestamp_timeout=1),
  • timeout de 2 minutos.

Con la opción env_reset lo que se pretende es eliminar todas las variables de entorno del usuario salvo LOGNAME, SHELL, USER, USERNAME, MAIL y las de SUDO_*

Referencias:

  1. man 8 sudo
  2. man 5 sudoers
  3. Hardening de servidores GNNU/Linux, Carlos Álvarez Martín y Palo González Pérez, 0xWord, 2013

Administración de sistemas compartida

En mis clases de Administración de sistemas operativos en Red me gustaba recalcar, dentro del tema de gestión de usuarios, la importancia del usuario administrador (root) y cómo llegar a serlo. Su importancia radica, como sabemos, en que es el encargado de la ejecución de las tareas de administración, instalación, configuración, monitorización y seguridad de los sistemas de tal forma que, en infraestructuras de cierto tamaño, es fácil que existan varios administradores.

En estas circunstancias ¿cómo se reparten el trabajo? ¿por equipos/servidores? Y si el responsable de un servidor no está, ¿el resto se desentiende?  Para responder a esta última pregunta como un equipo profesional, debemos permitir la administración compartida y colaborativa  entre varios administradores y que puedan, cualquiera de ellos, administrar (ejecutar tareas de un administrador) un mismo sistema.

Una manera es conociendo todos la contraseña de root. En mi opinión no es una buena opción ya que diluye la responsabilidad. En GNU/Linux existe una utilidad que nos permite, precisamente, obtener las bondades mencionadas anteriormente sin necesidad de que todos los administradores conozcan la contraseña de root: sudo.

El uso de sudo tiene las siguientes ventajas:

  • Alta contabilidad: se registra las órdenes y quién las ejecutó en los registros de eventos del sistema (los logs)
  • Como ya he comentado: se limita el conocimiento del passwd de root a una única persona y sin limitar la labor de los operadores, por ejemplo, a los que les podemos dar autorizaciones concretas.
  • No se necesitan establecer sesiones de trabajo de root.
  • Los privilegios pueden ser revocados cuando se necesite.
  • Tenemos una lista de todos los usuarios con privilegios de root y qué es lo que pueden hacer con esta responsabilidad (está en la configuración del comando).
  • Las restricciones de acceso son dependientes del host, un fichero simple puede ser usado para el control de acceso a una entidad de red.

Como no es oro todo lo que reluce, también tenemos varias desventajas:

  • Una brecha en la seguridad de la cuenta de usuarios es equivalente a una brecha en la de root (para las acciones autorizadas)
  • Una mala configuración, como es el uso de path relativos para describir las órdenes autorizadas, puede provocar problemas debido a engaños con ejecuciones del “programas no controlados” como si fuera un programa permitido. Se arregla con el uso sin path absolutos en las configuraciones.

Para utilizarlo, debemos instalarlo y configurar el fichero /etc/sudoers, pero esto, será otro día…

 


Autenticación con LDAP en Alfresco

En /opt/alfresco-4.2.f/tomcat/shared/classes/alfresco-global.properties debemos añadir la cadena de conexión del LDAP:

authentication.chain=ldap1:ldap,alfrescoNtlm1:alfrescoNtlm

Una recomendación es dejar, como última cadena alfrescoNtlm1:alfrescoNtlm para la autenticación nativa de Alfresco*.

Después debemos configurar el acceso a nuestro directorio para lo que necesitamos un fichero con los valores de LDAP. Para ello podemos partir de uno existente ejecutando la orden**:

sudo cp $ALFRESCO_DIR/tomcat/webapps/alfresco/WEB-INF/classes/alfresco/subsystems/Authentication/ldap/ldap-authentication.properties 
$ALFRESCO_DIR/tomcat/shared/classes/alfresco/extension/subsystems/Authentication/ldap/ldap1/ldap-authentication.properties

En mi caso, el valor de $ALFRESCO_DIR es el directorio por defecto en la instalación /opt/alfresco-4.2.f/

En el fichero copiado: $ALFRESCO_DIR/tomcat/shared/classes/alfresco/extension/subsystems/Authentication/ldap/ldap1/ldap-authentication.properties

podemos configurar el uso y conexión al sevidor LDAP. Si solo queremos autenticar, debemos insertar las líneas:

  • ldap.authentication.active=true
  • ldap.authentication.userNameFormat=uid=%s,dc=midominio,dc=dominio_primer_nivel
  • ldap.authentication.java.naming.provider.url=ldap://servidorLDAP.midominio.es:puerto

Si no queremos sincronizar la información de los usuarios y grupo: ldap.synchronization.active=false

Para que el sistema funcionara con cierta seguridad, deberíamos configurar la conexión bajo SSL. Otra opción es que la comunicación entre el servidor Alfresco y el directorio se realice por un túnel cifrado con, por ejemplo, IPSec y, en este caso, desde el punto de vista del servicio, no tenemos que hacer nada más.

Por último, que no se nos olvide desactivar el usuario invitado. En el mismo fichero de configuración del LDAP: ldap.authentication.allowGuestLogin=false

*Para desactivar los accesos anónimos/invitados también en la autenticación nativa de Alfresco, en el fichero $ALFRESCO_DIR/tomcat/webapps/alfresco/WEB-INF/classes/alfresco/subsystems/Authentication/alfrescoNtlm/alfresco-authentication.properties

alfresco.authentication.allowGuestLogin=false

** Es posible que tengas que crear algunos subdirectorios intermedios. Yo lo tuve que hacer.

Referencias:

  1. Información sobre los subsistemas de Alfresco: http://wiki.alfresco.com/wiki/Alfresco_Authentication_Subsystems
  2. Configurando LDAP: http://docs.alfresco.com/4.1/concepts/auth-ldap-intro.html

 


¿Hay algo que no pueda hacer root?

Pues si y no. Y no es por quedarme con el personal. Es que, directamente, hay cosas que NO puede hacer, aunque siempre puede buscar otro camino para conseguirlo.
Si empezamos con los ficheros y sus permisos y atributos, nos encontramos con:

  • Si un fichero está protegido ante cambios (atributo inmutable ‘i‘), root no podrá escribir en él (ver imagen).
  • Si un fichero está protegido con el atributo ‘a‘, solo “crece”, añade contenido y root no podrá borrar datos de él.

Captura de pantalla de 2014-04-14 22:55:50

Aunque, en ambos casos, siempre podrá quitar el atributo, independientemente de a quien pertenezca el fichero y hacer lo que considere.

Además, si queremos desmontar un sistema de archivo (FS) que está siendo utilizado, por ejemplo, porque un proceso que tiene abierto un fichero de este FS, root no podrá desmontarlo. Para conseguir su objetivo deberá, para el ejemplo, buscar qué proceso tiene abierto el fichero (lsof le ayudará), pararlo (kill)y, entonces, podrá desmontar el FS. Si, por otra parte, este FS es de solo lectura (porque se ha montado así, y no porque sea un CD-R), root no podrá escribir o hacer cualquier cambio en él aunque, para lograrlo, podrá

  • acceder directamente al dispositivo
  • remontarlo como RW

Por otra parte las contraseñas de los usuarios se guardan cifradas en el sistema por lo que root no conoce las contraseñas de los usuarios, aunque siempre podrá:

  • emplear mecanismos de fuerza bruta, no hay que olvidar que tiene acceso a la contraseña cifrada,
  • emplear mecanismos que la obtengan (captura de pulsaciones del teclado,…) ya que tiene acceso a todo el sistema,
  • cambiarla por otra…

Y por último, una acción que tampoco podrá hacer root es parar un proceso que entre en modo de espera en el núcleo (aunque sí que podrá parar TODO el sistema, que para chulo,…)

Referencias:

  1. Administración de sistemas operativos Windows y Linux. Un enfoque práctico, de Juan Antonio Gil, Julio Gómez y Nicolás Padilla.
  2. Linux system Administration, de Tom Adelstein y Bill Lubanovic

Las cookies nos permiten ofrecer nuestros servicios. Al utilizar nuestros servicios, aceptas el uso que hacemos de las cookies. Más información.