Playbooks para la gestión básica de infraestructura IT

Continuando con la automatización de configuraciones de nuestra infraestructura, en la Escuela Politécnica también hemos programado (y liberado) playbooks de Ansible relacionados con las tareas básicas que se realizan con los servidores de nuestros servicios IT.

Más información sobre estos playbooks en https://blogs.ua.es/labseps/?s=ansible&x=0&y=0

Y el software en https://github.com/EPSAlicante/ansibleEPS

¡Espero que os sea útil!


Google authenticator como 2FA en Debian

El año pasado probé Google Authenticator como 2FA en una CentOS. Hoy he usado la información de esa entrada para configurar, ¡por fin!, un 2FA para el acceso por SSH a mi almacenamiento personal.

Como la distro es Debian, hay un pequeño cambio: el paquete que debemos tener instalado:

apt-get install libpam0g-dev

Debemos tener instalado tanto gcc como make para poder compilar la librería de google.

Un detalle más es que, al contrario de lo que comenté en mi anterior entrada, para configurar mi Android he preferido usar la secret key que obtenemos al ejecutar Google Authenticator para el usuario que queremos proteger.

¡Espero que os sea útil!


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!


ownCloud y Raspberry PI

Tras un aviso de Dropbox para que reduzca los muchísimos GB que me sobran al haber “caducado la oferta” por pertenecer a la UA, he decidio crearme mi “ownCloud” con un disco duro de 1TB que tenía y una Raspberry PI.

Sobre como instalarlo hay muchas entradas en la red (I, II, III, IV,  …) así que poco más que añadir o comentar, salvo:

Leer más


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…

 


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