Recomendaciones sobre contraseñas

Existen distintas aproximaciones a la hora de construir contraseñas seguras. Las siguientes están documentadas en diferentes libros sobre seguridad.

[Unix and Linux System Administration (4th edition) - pag 111]: Eligiendo la contraseña del root. Sin duda la cuenta root es la más delicada. Este libro nos da diferentes soluciones para no tener que usarla. Sin embargo insiste en la importancia de elegir una buena constraseña de root, que solo conocerá una persona, o "ninguna" (si utilizamos algún software de gestión de contraseñas). La característica más importante de una contraseña es su longitud. En teoría, las contraseñas más seguras son secuencias aleatorias de letras, caracteres especiales, y números, pero la dificultad para recordarlas, hace difícil escribirlas (la escritura lenta puede ser objeto de ataque "shoulder-surfing") y recordarlas.

Grady Ward propone la idea de "sinsentido chocante":

Shocking nonsense means to make up a short phrase or sentence that is both nonsensical and shocking in the culture of the user. That is, it contains grossly obscene, racist, impossible or otherwise extreme juxtapositions of ideas. This technique is permissible because the passphrase, by its nature, is never revealed to anyone with sensibilities to offend. Shocking nonsense is unlikely to be duplicated anywhere because it does not describe a matter of fact that could be accidentally rediscovered by someone else. The emotional evocation makes it difficult for the creator to forget. A mild example of such shocking nonsense might be, 'Mollusks peck my galloping genitals'. The reader can undoubtedly make up many far more shocking or entertaining examples for him or herself.

Los sistemas que soportan longitud arbitraria de entrada, pueden usar el concepto de "passphrase".

[Foundations of security - pag 151]: Otra aproximación sobre contraseñas fuertes, incluida en este libro, es la siguiente

  • Usar las contraseñas más largas posibles.
  • Incluir letras números y caracteres especiales.
  • Contraseñas diferentes para cada sistema.
  • Transformación de una passphrase en una contraseña. Por ejemplo: "Nothing is really work unless you would rather be doing something else" --$gt; n!rWuUwrbds3.
  • Utilizar contraseñas "Honeypots": confundir a los atacantes, para que sean los atacados, asignando contraseñas fáciles a cuentas de usuario "built-in" o fáciles de averiguar, como "Invitado", "guest", "usuario", etc. Dicha cuenta será configurada como una cárcel en cuanto a privilegios. De este modo, cuando un usuario trate de iniciar sesión, nos daremos por entendidos: alguien intenta entrar en el sistema. Podemos utilizar mecanismos de aviso que alerten al administrador de este hecho, y así tomar las medidas oportunas (rastrear la ip, reconfigurar el firewall, cambiar contraseñas...).

[Windows Server 2008 Security Resource Kit - pag 47]: Este libro dice claramente "Deja de pensar en palabras", piensa en frases. Windows soporta passwords de hasta 127 caracteres, todos presentes en el teclado (incluida la barra espaciadora). Para endurecer la passphrase, se puede realizar conversiones de vocales y consonantes a números y símbolos especiales, como por ejemplo a = @, i = !, e = 3, etc.

Con anterioridad, las contraseñas podían ser como máximo de 14 caracteres, por las limitaciones del algoritmo LM. Desde Windows 2000, con la llegada de NTLM, las contraseñas se alargaron hasta los 127 caracteres.

En sistemas Linux, la longitud de las contraseñas varía según el algoritmo criptográfico empleado. En www.ratliff.net/blog/2007/09/20/password-length/ tenemos un resumen sobre algunos de ellos. Si examinamos el archivo /etc/shadow, podemos ver el algoritmo empleado mirando los primeros caracteres del hash: $1$ indica que el sistema utiliza MD5, $2$ o $2a$ indica que el sistema utiliza blowfish, $5$ indica que el sistema utiliza SHA-256, $6$ indica que el sistema utiliza SHA-512. No he encontrado referencias a la longitud máxima de la contraseña en sistemas Linux que utilizan SHA-512, pero he probado con una contraseña de 180 caracteres, y no hubo problema.

Ataques a las contraseñas

Para romper una contraseña, un atacante tratará dos tipos de ataques: offline u online.

  • Online attack: En este método, el atacante adivina la contraseña de un usuario, tras probar diferentes contraseñas. Esta opción puede toparse con mecanismos de bloqueo ante fallos sucesivos de autenticación.
  • Offline attack: En este método, el atacante consigue acceder al archivo donde se almacenan las contraseñas. Entonces utiliza alguna herramienta para romper la contraseña. La ventaja de este método es que el atacante no necesita preocuparse sobre mecanismos para evitar los ataques online.

Ataques online a las contraseñas

Ahora vamos a ver algunos métodos para atacar online, así como sus contramedidas.

Adivinación de contraseñas

La adivinación de contraseñas es un método muy popular para obtener las credenciales de los usuarios. La adivinación de contraseñas se puede hacer contra cualquier servicio. Una vez ganado el acceso a un cierto servicio, la contraseña suele valer para más cosas, ya que a los usuarios no les gusta tener una contraseña para cada cosa.

Antes de empezar necesitamos revisar algunas cuestiones

SMB

IPC (Interprocess Communication Share) es un conjunto de técnicas que permiten a los procesos de una red Microsoft, comunicarse e intercambiar información. Microsoft proporciona el comando "net use" para acceder a un recurso compartido por otra máquina. Así, por ejemplo "net use Z: \\svr2008\compartida * /u:Administrador" creará una conexión con la carpeta llamada "compartida" de la máquina "svr2008", con las credenciales del administrador. Si utilizamos el comando "net use \\svr2008\ipc$ * /u:Administrador", estamos intentando realizar una conexión al recurso IPC de svr2008, y solo lo lograremos si conocemos la contraseña de dicho usuario. Así, que podemos jugar a las adivinanzas. Probar contraseña a contraseña manualmente no es eficiente, así que podemos automatizar el proceso, con un bucle FOR de MS-DOS. El siguiente es un ejemplo rudimentario, pero que funciona:

C:\> FOR /F "tokens=1,2*" %i in (credenciales.txt) do^ ¿Más? net use \\192.168.100.50 %j /u:%i

Para este ejemplo necesitaremos un archivo llamado credenciales.txt que almacenará los pares usuario/contraseña. Por ejemplo:

------------------------------------ Contenido del archivo credenciales.txt ------------------------------------ Administrador "" Administrador password Administrador contraseña Administrador secreto Administrador admin . . . --------------------------------------

El bucle for se puede perfeccionar, para que la salida sea más amigable. Por ejemplo:

C:\>FOR /F "tokens=1,2*" %i in (credenciales.txt)^ More? do net use \\192.168.100.50\IPC$ %j /u:192.168.100.50\%i^ More? 2>\>nul^ More? && echo %time% %date% >\> salida.txt^ More? && echo \\victim.com acct: %i pass: %j >\> salida.txt

Existen herramientas como smbgrind, cuyo principio es el mismo, aunque actuan de forma más eficiente. Para contar con un buen diccionario, podemos buscarlos ya hechos, con miles de palabras de cualquier idioma. Por ejemplo en ftp://ftp.ox.ac.uk/pub/wordlists/.

Otra forma en la que un atacante podría generar un diccionario suficientemente amplio, es empleando la herramienta "crunch", que puede generar todo tipo de combinaciones con caracteres alfa-numéricos y especiales para volcarlo en un archivo. Por ejemplo $ crunch 6 10 -f charset.lst mixalpha-numeric-symbol14-space -o diccionario.lst generará todas las cadenas posibles de entre 6 y 10 caracteres con caracteres alfanuméricos, símbolos y espacio en blanco.

Práctica 1. realiza un ataque de "password guessing" por SMB a un servidor Windows Server 2008. Incluye en tu diccionario particular la contraseña válida".

WMI

Para empezar, vamos a leer este texto: Introducción a WMI

Si ya lo hemos leido, vamos a probar lo siguiente. En primer lugar, habilita en el servidor la regla de entrada siguiente del firewall con seguridad avanzada: "Instrumental de administración de Windows (WMI de entrada)". Ahora, desde la máquina atacante, podemos probar lo siguiente:

La primera conclusión que podemos sacar de esto es, utilizar siempre contraseñas fuertes.

C:\> wmic wmic:root\cli> /user:Administrador /password:9pR3nD13nD0! /node:192.168.100.50 cpu list

La respuesta debe indicarnos el tipo de CPU que utiliza el sistema remoto. Lo importante de esto, es que con WMI también podemos jugar a las adivinanzas.

Suponiendo que en el entorno en que estamos, se utiliza WMI para el despliegue de las directivas de grupo, por ejemplo, podemos utilizar un programa como venom para intentar adivinar la contraseña via WMI. Cuando intentemos ejecutar venom, puede que tengamos problemas con algunos archivos "ocx" (en concreto, mscomctl.ocx y comdlg32.ocx). Para resolver el problema, debemos descargar esta solución y ejecutarla.

Práctica 2. Realiza un ataque de "password guessing", atacando WMI para un servidor Windows Server 2008. Asegúrate de habilitar en Windows las reglas que permitan el uso de WMI. Puedes utilizar la siguiente lista de passwords: diccionario para fuerza bruta de John de Ripper. Puedes encontrar más diccionarios en Skullsecurity.org

No solo con Windows se pueden utilizar técnicas de este tipo. También se puede hacer con Linux, por ejemplo, intentando autenticarnos contras servicios como SSH. Para este tipo de acciones, hay distribuciones repletas de herramientas, como BackTrack.

Si lo que queremos es tener BackTrack en español (teclado y demás), hacer lo siguiente:

apt-get install language-pack-es apt-get install language-pack-es-base apt-get install language-pack-kde-es apt-get install language-pack-kde-es-base apt-get install language-support-es apt-get install language-support-translations-es apt-get install language-support-writing-es apt-get install kde-i18n-es desde el menu settings->regional & accessibility->country/region & language y luego configura la disposicion del teclado

Supongamos que el atacante cuenta con un buen diccionario, y que los usuarios de nuestro sistema GNU/Linux han elegido contraseñas débiles. De algún modo ha conseguido también un listado de usuarios del sistema (lo que puede haber hecho de múltiples formas diferentes). También ha dedicado 10 segundos a realizar un escaneo de puertos con "nmap", y observó que nuestro sistema GNU/Linux tiene el servicio SSH instalado. Entonces, utilizando un disco de BackTrack, ejecuta el siguiente comando: $ hydra -l jperez -P passwords.txt 192.168.100.100 ssh.

Con BackTrack 4, el comando anterior falla. La única solución que he encontrado incluye la actualización a BT5. De cualquier modo, cuando lo ejecuteis con BT5, es posible que os genere el siguiente error: Warning: Timeout from child. Tiene que ver con el número de intentos que se hacen simultáneamente y el tiempo que consideramos de "timeout" para cada intento. Podemos bajar el número de intentos y el tiempo de espera, añadiendo el modificador "-t 10" y el modificador "-w 50". Por ejemplo: $ hydra -t 10 -w 50 -l jperez -P passwords.txt 192.168.100.100 ssh.

En el siguiente video, podemos ver un ataque por fuerza bruta similar, aunque empleando un script escrito en python, llamado brutessh: ataque con brutessh. El principio es el mismo y sobre gustos no hay nada escrito.

Práctica 3: Realiza un ataque de "password guessing" a un servicio ssh, empleando alguna herramienta como hydra o brutessh para ello.

SMB MITM

Otro tipo de ataque, puede consistir en un MITM sobre SMB. SMBRelay es una herramienta creada por "Sir Dystic of Cult of the Dead Cow". Se trata de un demonio SMB que recoge usuarios y contraseñas del tráfico entrante SMB. Además, puede redireccionar el tráfico al servidor SMB auténtico, entrando en un ataque MITM. Se trata de un problema que aprovecha la debilidad de las contraseñas LM. En principio está solucionado en las versiones modernas de Windows, ya que LM está desactivado por defecto. Aun así, podrían haber problemas con clientes antiguos. La solución es exigir el firmado de las comunicaciones SMB. El siguiente vídeo muestra un ataque de este tipo: Ataque smbrelay

Tenemos las siguientes directivas en Configuración de Windows\Configuración de seguridad\Directivas locales\Opciones de seguridad\:

  • Cliente de redes de Microsoft: enviar contraseña sin cifrar a servidores SMB de terceros
  • Cliente de redes de Microsoft: firmar digitalmente las comunicaciones (si el servidor lo permite)
  • Cliente de redes de Microsoft: firmar digitalmente las comunicaciones (siempre)
  • Servidor de red Microsoft: firmar digitalmente las comunicaciones (si el cliente lo permite)
  • Servidor de red Microsoft: firmar digitalmente las comunicaciones (siempre)

Los SO de Microsoft negocian el firmado. Si se puede aplicar se aplica, pero si no se puede no se aplica. Esto quiere decir, que para forzar el firmado, y evitar los ataques Mitm sobre SMB, se debe exigir siempre el firmado. Pero entonces, puede que tengamos problemas como el siguiente: problema con escaner. Es decir, exigir el firmado provocará que clientes que no lo soporten no podrán conectarse.

Las medidas necesarias para mitigar este ataque son las siguientes:

  • Activar y requerir NTLMv2 para la autenticación.
  • Activar (como ya hemos dicho) la firma de los paquetes SMB.
  • Instalar el parche ms08-068.

en el artículo "Microsoft patch closes 7-year-old OS hole" se comenta la pasividad con que Microsoft ha tratado el problema de SMBRelay durante casi una década. También es muy interesante el artículo "Preventing smb-relay attacks" donde se detallan los fundamentos del ataque.

Kaspersky (cuyo software probaremos en clase) ofrece esta información sobre smbrelay y su "Administration Kit": Cómo prevenir los ataques tipo SMB Relay que intentan recibir privilegios avanzados en Microsoft Windows.

Contramedidas a los ataques online en los sistemas Windows.

Las contramedidas tienen que ver tanto con el control de acceso como con la identificación y registro de los hechos que puedan sugerir un ataque. Los controladores de dominio son un objetivo bastante probable para alguien que quiere obtener información sobre los usuarios de un sistema. Por ello deben estar fuertemente protegidos y monitoreados. De este modo, un atacante buscará un sistema pobremente defendido, y tratará de realizar a partir de aquí una escalada de privilegios que le lleve a controlar los recursos del dominio.

Una vez comprometido un dominio, los daños pueden ser aun mayores si existen relaciones de confianza con otros dominios (en un árbol de dominios, o en un bosque). Para conocer más información sobre este tema, se puede consultar en Estableciendo límites seguros para Active Directory.

Se puede configurar Windows para que LSASS añada al registro de eventos información relevante sobre permisos de acceso concedidos o denegados a los recursos. Las SACL (System ACL) permiten definir con gran detalle, qué eventos registrar y para qué usuarios. Estos registros incluyen información sobre el SID que realiza el acceso y el permiso resultante.

La auditoría sobre el control de acceso está desactivada por defecto. Para activar la directiva de auditoría, es preciso editar las directivas en Directivas\Configuración de Windows\Directivas locales\Directiva de auditoría".

Como parte de una estrategia de detección se recomienda activar la auditoría de la forma más exhaustiva posible. Esto es, activar la auditoría de acceso para todos los objetos, tanto en aciertos como en errores, menos para el seguimiento de los procesos (por la sobrecarga que puede generar).

Práctica 4. Para entender la auditoría, vamos a revisar las instrucciones especificadas en Guía paso a paso de la directiva de auditoría. Debemos establecer directivas de auditoría sobre las cuentas y sobre los objetos. Comprobaremos que al iniciar sesión, o al introducir una contraseña errónea, se generan los eventos de auditoría correspondientes. Del mismo modo, debemos comprobar que los accesos a un objeto auditado, quedan registrados.

Una vez que activamos la auditoría sobre el acceso a los objetos (archivos y carpetas), debemos elegir los objetos que serán auditados. Para ello, en las propiedades del objeto, elegimos "Seguridad\Opciones avanzadas\Auditoría" y añadimos los permisos y los usuarios que queremos auditar.

El problema que tendremos con la auditoría, es cómo administrar tal cantidad de información generada en los registros de eventos. Se puede definir un límite de tamaño para el registro de eventos de seguridad. Como recomendación, se puede establecer para el registro de eventos de seguridad un máximo de 130 MB, y unos 26 MB para el registro de Aplicaciones y de Sistema. Esto se puede definir en las propiedades de los mismos registros (en el Visor de Eventos).

Existe una mejora en cuanto a la organización, análisis y correlación de los datos de auditoría, que se introdujo con Windows Vista. Esta mejora, está disponible en Visor de Eventos\Suscripciones. El siguiente vídeo muestra esta característica: Vídeo sobre la suscripción de sucesos en Windows Server 2008.

Además de auditar, debemos prevenir los ataques online contra contraseñas mediante directivas de contraseñas y de bloqueo de cuentas. En un grupo de trabajo, dichas directivas estarán en las directivas de seguridad local\Configuración de seguridad\Directivas de cuenta\. En un controlador de dominio, deberemos irnos al editor de directivas de grupo. Para conocer la función de cada directiva, podemos hacer clic sobre ella y leer la explicación.

Práctica 5. Partimos de un servidor Windows Server 2008. Crea al menos una cuenta "no de administrador". Establece una política de contraseñas y bloqueo de cuentas, para que las contraseñas sean complejas, y tengan una longitud mínima de 10 caracteres. Además, una cuenta se bloqueará cuando hayan más de 5 intentos de logueo fallidos. El bloqueo durará 5 minutos. Configura la directiva de inicio de sesión para queden registrados los fallos de autenticación. Por último realíza desde otra máquina un ataque de "password guessing" con cualquier herramienta que desees. Posteriormente, comprueba que las cuentas "no de admnistrador" están bloqueadas y que han quedado registrados los intentos fallidos de inicio de sesión.

Un atacante intentará evitar los bloqueos de cuentas por un excesivo número de intento de inicio de sesión. No solo impedirá que pueda seguir intentándolo, sino que además puede generar un evento de auditoría. Las directivas de enumeración de contraseñas están por defecto deshabilitadas, pero el atacante no lo sabe. Por ello, antes de intentar averiguar la contraseña de un usuario de interés, puede intentarlo con la cuenta "Invitado", que probablemente esté desactivada (ojo, desactivada no es lo mismo que bloqueada).

El comando net use \\maquina\ipc$ /user:Invitado, con contraseña en blanco, inicia el contador de inicios de sesión. Superado el límite (si es que lo hay), se nos informará de que la cuenta ha sido bloqueada.

Práctica 6. Tras montar una infraestructura con un DC y un cliente, define una directiva para el bloqueo de las contraseñas, para que las cuentas se bloqueen pasados 3 intentos de inicio de sesión fallidos, estableciendo un bloqueo de 5 minutos. Puedes encontrar dicha directiva en Directivas\Configuración de Windows\Configuración de seguridad\Directivas de cuenta\. Asegúrate de que se está aplicando la directiva en el cliente. Comprueba que la cuenta se bloquea cuando desde otra máquina, introducimos mal la contraseña al comando net use \\maquina\ipc$ * /user:Invitado, al menos 4 veces.

Otra cuestión imporante es la siguiente: la cuenta de Administrador no se va a bloquear en un ataque de "password guessing", y además, el administrador suele no cambiar la contraseña. Por ello, un atacante puede centrarse en esta cuenta para obtener la contraseña, causando así el mayor impacto posible. Para combatir esto hay una solución: cambiar el nombre de la cuenta de Administrador . Además, podemos crear una cuenta falsa con el nombre "Administrador" como estrategia "honeypot". De este modo, podremos mediante auditoría cuando la cuenta falsa llamada "Administrador" se bloquea, y entenderemos que está habiendo un ataque.

Desgraciadamente, un atacante puede descubrir nuestro engaño, si consigue (mediante un ataque de enumeración) averiguar la auténtica cuenta de Administrador del dominio. Dicha cuenta tiene un RID 500. Por lo que empleando una herramienta como "sid2user/user2sid" podrá averiguarlo. Los pasos son los siguientes: 1. averiguar el SID del dominio: C:\>user2sid \\192.168.100.50 usuario. 2. Una vez que conozco el SID del dominio, averiguo nombre del administrador: C:\>sid2user \\192.168.100.50 5 21 2570943746 2782215392 1967871400 500. Ante esta estrategia, no hay nada como una buena política de contraseñas.

Esto último solo funcionará si la máquina ya está dentro del dominio.

Práctica 7. En esta actividad, habrá un administrador que protege sus sistemas, y un atacante que pretende averiguar la contraseña del administrador del dominio. El administrador debe cambiar el nombre de la cuenta de Administrador. El atacante debe averiguar el nombre de dicha cuenta.

Práctica 8. Haz un resumen, teniendo en cuenta todo lo que hemos hablado, con las medidas que tomarías en un dominio Microsoft para proteger tus cuentas de usuario de ataques online.

Contramedidas a los ataques online en sistemas GNU/Linux

En los sistemas *NIX es tradicionalmente el software de aplicación el que implementa la seguridad. Pero esto no es práctico actualmente. Una primera solución fue /etc/shadow. Pero shadow dejaba en manos de la aplicación el manejo de las contraseñas. Una solución muy extendida, entre otras que ya veremos en este tema, es PAM. La idea original de los Pluggable Authentication Modules, en adelante PAM, fue de Sun y sus especificaciones se encuentran recogidas en "Unified login with pluggable authentication modules (PAM) - Open Software Foundation, 1995. Sin embargo, muchos otros sistemas adoptaron esta solución y cuentan desde hace tiempo con sus propias implementaciones. PAM permite el desarrollo de programas independientes del mecanismo de autenticación a utilizar y además permite al administrador del sistema construir políticas diferentes de autenticación para cada servicio.

Ahora, antes de seguir es preciso leer un texto técnico sobre PAM.

NOTA: Para consultar las opciones de un cierto módulo, podemos usar el comando "man nombre_modulo". Por ejemplo, para consultar las opciones del módulo pam_module.so, ejecutaríamos el comando "man pam_module".

Si ya hemos leido el texto anterior, sabremos que para establecer políticas de contraseñas, necesitamos el módulo "PAM_CRACKLIB". Para instalarlo:

$ sudo apt-get install libpam-cracklib $ sudo update-cracklib

Con el segundo comando, actualizamos la base de datos de palabras que utiliza cracklib. Esta tarea se añade automáticamente a cron y se ejecuta diariamente.

Práctica 9. Diseña una política de contraseñas que no permita introducir palabras más cortas de 10 caracteres, y que incluyan a ser posible caracteres alfanuméricos, y símbolos especiales. Para ello primero debes instalar el módulo pam_cracklib y después modificar el archivo de configuración de PAM dedicado a las contraseñas: /etc/pam.d/common-password. Para forzar el comportamiento sobre minúsculas, mayúsculas, números y caracteres especiales, busca en internet información sobre los modificadores lcredit, ucredit, dcredit y ocredit del módulo pam_craklib. Intenta introducir una mala contraseña y comprueba lo que ocurre.

Otro aspecto importante en la política de contraseñas es la expiración del periodo de validez. PAM ofrece el parámetro PASS_MAX_DAYS en /etc/login.defs. Por ejemplo, si queremos que solamente dure 90 días, escribiremos PASS_MAX_DAYS 90. Además de este parámetro, también están PASS_MIN_DAYS y PASS_WARN_AGE. También contamos con el comando chage que permite modificar la expiración de la contraseña. Por ejemplo, /usr/bin/chage -m 10 -M 90 -W 70 jperez indica que el usuario jperez no puede cambiar su contraseña antes de 10 días, y que a los 90 caduca. Será avisado una vez queden 20 días para la caducidad de su contraseña.

Práctica 10. Crea una cuenta de usuario llamada testage. Asegúrate de asignarle una carpeta "home" y una shell. Asígnale mediante chage, 2 días como mínimo para cambiar la contraseña, 4 días para empezar a advertir que la contraseña va a caducar y 10 días para que caduque. Después has las siguientes cosas:

  • Inicia sesión como testage e intenta cambiar la contraseña en menos de 2 días de haberla creado
  • Modifica la fecha de la máquina, para que hayan pasado 3 días. Comprueba los avisos de caducidad
  • Modifica una vez más la máquina para que hayan pasado 11 días. Comprueba que la contraseña ha caducado
  • Restablece como administrador la contraseña

También necesitamos bloquear las cuentas del sistema (al igual que hacíamos en los sistemas Windows) cuando el fallo de autenticación supere un cierto número. Pero ¡Cuidado! Hay ciertas consideraciones a tener en cuenta. Algunas distribuciones GNU/Linux no permiten iniciar una sesión con el usuario "root". Si vamos a bloquear las cuentas cuando haya un ataque de "password guessing" necesitamos la cuenta de root (que no se bloqueará) para poder iniciar sesión en caso de denegación de servicio sobre las cuentas de usuario. Por ello, lo primero es permitir a root iniciar sesión en el sistema.Dar una contraseña a root para poder iniciar como root. Para ello, haremos lo siguiente:

  • Comprobar que root puede iniciar en tty, comprobando "auth required pam_securetty.so" en /etc/pam.d/login.
  • Asignar una contraseña al usuario root (debe ser una contraseña fuerte o una passphrase), ya que de otro modo, no podemos iniciar sesión con root.
  • Añadir al principio de "common-auth" lo siguiente: auth required pam_tally.so onerr=fail deny=5 unlock_time=60
  • Para ver cuantos intenos hubieron sobre cada usuario, usaremos el comando pam_tally
  • Para desbloquear una cuenta manualmente, podemos ejecutar el siguiente comando: pam_tally --user usuario_bloqueado --reset

Con el comando pam_tally podemos establecer políticas de bloqueo directamente.

Práctica 11. Configura tu sistema GNU/Linux para que bloquee las cuentas tras 5 intentos fallidos de autenticación. Después simula un ataque de "password guessing" contra shh, con alguna herramienta diseñada para ello, como por ejemplo hydra. Utiliza un diccionario que incluya la contraseña correcta del usuario atacado, pero colócala suficientemente "atrás" en el archivo de diccionario para que la emplee pasados 5 intentos fallidos. ¿Conseguiste repeler el ataque? Comprueba en el sistema, mediante pam_tally que el usuario está bloqueado por superar los 5 intentos. Comprueba en /var/log/auth.log que se registraron los intentos fallidos. Deja pasar el tiempo establecido de bloqueo, e intenta establecer una nueva conexión por ssh contra el mismo usuario objeto del ataque. ¿Pudiste iniciar sesión?

Por útlimo, un recurso que me gusta: www.brandonhutchinson.com/wiki/Linux_Password_Policy

Ataques offline contra las contraseñas

Para un administrador, las técnicas aquí comentadas pueden servirle para conocer la fortaleza de sus contraseñas, ya que una buenta contraseña es más difícil de romper que una débil

Las contraseñas se almacenan en el sistema después de haber sido pasadas por alguna función de "un solo sentido" (hashing). Es decir, no se puede dar marcha atrás, para obtener la contraseña original. La única opción posible es obtener los hashes, y probar las posibles contraseñas, hasta conseguir romperla.

Para poder romper las contraseñas, necesitamos los hashes de las contraseñas, ya que lo primero es obtener dichos hashes. En linux, están en el archivo /etc/shadow y en Windows están en el registro SAM. En Windows, además, estos hashes están encriptados por una contraseña llamada Syskey. Dicha contraseña puede encontrarse almacenada localmente, en un "disquete" o ser una passphrase a introducir cada vez que arrancamos el sistema. Por defecto, Syskey se almacena localmente, dispersa por varios puntos del registro. Aunque la encriptación de los hashes es 128 bits, no sirve de mucho, ya que la forma en que Windows guarda el Syskey es conocida.

Empleando la distribución BackTrack, es posible recuperar los hashes de las contraseñas, mediante la aplicación samdump2 y después realizar un ataque de fuerza bruta o de diccionario contra los mismos, mediante la aplicación John the Ripper. En el siguiente vídeo se puede observar como llervar a cabo este ataque mediante BackTrack 4 en un sistema Windows 7: Ataque offline sobre Windows 7

Mediante BackTrack 5 también se puede realizar el mismo ataque, aunque en este caso, la aplicación samdump2 cambia en su forma de uso:

En el siguiente enlace podemos ver los mismo utilizando una distribución Ubuntu. Comprueba la fortaleza de tu contraseña en Ubuntu.

OJO: Windows almacena las contraseñas hasheadas de dos maneras, mediante LM y mediante NTLM. Por ejemplo, el siguiente hash: Usuario:1002:aad3b435b51404eeaad3b435b51404ee:59d32547243b435fae5565732123cc6f::: incluye un hasn LM (aad3b435b51404eeaad3b435b51404ee) y otro hash NTLM (59d32547243b435fae5565732123cc6f). Al ejectuar John the Ripper, si no indicamos expresamente la opción --format=NT, "Jonhny" se irá a por el hash más fácil de romper, es decir, LM, y dejará NTLM para "otra ocasión". Windows Vista y posteriores, tienen desactivado por defecto LM, y por ello, el hash LM proviene de la contraseña vacía (en realidad aad3b435b51404eeaad3b435b51404ee es el hash LM de una cadena vacía). Por ello, si no indicamos --format=NT nos devolverá una contraseña vacía.

root@bt:~# fdisk -l root@bt:~# mkdir /mnt/windows root@bt:~# mount /dev/sda1 /mnt/windows root@bt:~# cd /mnt/windows/WINDOWS/system32/config/ root@bt:/mnt/windows/WINDOWS/system32/config# bkhive SYSTEM /root/key.txt root@bt:/mnt/windows/WINDOWS/system32/config# samdump2 ./SAM /root/key.txt > /root/hashes.txt

De este modo recuperaríamos los hashes empleando BackTrack 5. Con bkhive recuperamos el syskey. Con samdump2, extraemos los hashes suministrándo la syskey obtenida con bkhive.

Práctica 12. Recuperar los hashes de la SAM de un Windows 7 y guardarlos en un archivo de texto de otra máquina.

Una vez que hemos obtenidos los hashes, existen diferentes enfoques. Uno es llamado de "Fuerza bruta". Este método, realiza una comprobación una a una de todas las claves posibles, hasheando una a una, y comprobando si el resultado es igual que el hash de la contraseña objetivo. Esta técnica puede provocar que el ataque dure mucho. Un clásico de la fuerza bruta es "John the Ripper".

John the Ripper se puede usar de varias maneras. Por defecto, John realiza ataques de diccionario y utiliza cierta cantidad de inteligencia para realizar los ataques, incluyendo el uso de prefijos y postficos de caracteres especiales, uso del nombre de usuario como password y prueba de variaciones sobre el nombre de usuario. John puede trabajar en diferentes modos:

  • Modo diccionario: utiliza un diccionario suministrado, o por defecto utiliza el diccionario incluido con John si no se indica un archivo de diccionario. John intentará cada contraseña de forma secuencial.
  • Modo crack-único: intenta con los nombre de cuenta solamente.
  • Modo incremental: Este modo es el más potente de John, ya que prueba con todas las combinaciones de caracteres posibles para una cierta longitud de contraseña. Las contraseñas que emplean cracteres diversos pero que son cortas, pueden ser rotas por este método. Por supuesto, tardará más ya que prueba más combinaciones.

Por ejemplo:

root@br:~# john --format=NT --wordlist=password.lst /root/hashes.txt root@br:~# john --format=NT --incremental:ALL /root/hashes.txt root@br:~# john --format=NT --single /root/hashes.txt

Para quien esté interesado en el manual de John the Ripper, tiene el siguiente enlace: www.openwall.com/john/doc/.

Práctica 13. Intentar romper una contraseña por fuerza bruta, a partir de los hashes obtenidos anteriormente, empleando John the Ripper.

El enfoque de "tablas rainbow" se basa en el uso de tablas de hashes precomputados, de forma que se busca una coincidencia con el hash de la contraseña objetivo. Las tablas rainbow pueden ser muy grandes. Un clásico de las tablas Rainbow es Ophcrack. Originalmente, Ophcrack se basaba en la debilidad de LM, por lo que no se portaba bien para los nuevos Windows que solo almacenan en NTLM (como Windows 7). La última versión de Ophcrack (live-CD) sí puede romper NTLM.

Práctica 14. Descarga la última imagen de Ophcrack en live-CD. En una máquina con Windows 7, crea un usuario con una contraseña débil. Por ejemplo, en mi caso, el usuario se llamaría "mauri2", y la contraseña débil podría ser "Mauri01". Asigna también una contraseña fuerte a otro usuario. Trata de romper las contraseñas con Ophcrack live-CD.

Modificación de las contraseñas

Modificar las contraseñas es más fácil que romperlas. Existen múltiples formas de hacerlo. Vamos a centrarnos primero en sistemas Windows.

Modificación de contraseñas Windows

Vamos a ver dos de ellas para Windows. La primera se basa en el uso de una distribución que pueda acceder a la SAM y cambiar la contraseña. La segunda hace uso de una vulnerabilidad de Windonws.

Hay varias distribuciones que pueden modificar la contraseña, como UBCD4win o Hiren's Boot CD. En este caso, vamos a utilizar Hiren's Boot CD, aunque como ya digo, existen otras alternativas. Para cambiar la contraseña, los pasos a dar son:

  • Arrancar desde HBCD
  • En el menú inicial, elegir "Offline NT/2000... Password Changer"
  • En el prompt Boot:, pulsar Intro
  • A continuación se nos muestra un menú de selección, donde se ofren varias unidades a montar. En mi caso, se me ofrece /dev/sda1 de 100 MB (partición de arranque), y /dev/sda2 de 10138 MB, que contiene la SAM. Así que elijo la segunda opción.
  • La siguiente pregunta se refiere al punto del sistema de archivos donde se encuentra el registro. La opción por defecto (Windows/System32/config) es correcta, así que solo tengo que pulsar intro.
  • En el siguiente paso se me pide que elija entre dos acciones posibles: Resetear la contraseña o bien iniciar la consola de recuperación. Elegiremos "Password reset".
  • A continuación debo elegir entre editar los usuarios y sus contraseñas, o bien editar el registro. Elegiremos "Edit user data and passwords".
  • En el siguiente paso introduzco el nombre del usuario a editar. Presiono intro, y se nos ofrecen varias opciones. Elegiremos "Clear (blank) user password".
  • Ya hemos terminado, nos queda guardar y salir de HBCD. Para ello, en las sucesivas preguntas, introducimos "!", "q", y ante la pregunta "About to write file(s) back! Do it? [n]:" introducimos "y" para guardar los cambios en la SAM.
  • A la pregunta "New run? [n]" respondemos "n" y presionamos intro. Finalmente, damos la orden "reboot".

Ahora, cuando volvamos a reiniciar, el usuario cuya contraseña hemos cambiado está en blanco. Podemos iniciar sesión sin introducir contraseña. Una vez iniciada la sesión, podemos pulsar "Ctrl+Alt+Supr" para cambiar la contraseña.

En el siguiente enlace, tenemos una demostración: www.youtube.com/watch?v=JIx46zQlKCk

Práctica 15. Modifica la contraseña de un usuario empelando Hiren's Boot CD.

El segundo método hace uso de las StikyKeys. Mediante un CD Live se accede a la partición de Windows y se sustituye sethc.exe por cmd.exe. Al reiniciar, en la página de inicio de sesión, se puede pulsar 5 veces "Shift", obteniendo una consola con permisos de "System" (ya que aun no ha iniciado ningún usuario). Solo queda ejecutar control userpasswords2.

Práctica 16. Modifica la contraseña del usuario Administrador mediante el método de StickyKeys.

Modificar la contraseña en GNU/Linux

Todo sistema GNU/Linux actual almacena los hashes de las contraseñas en /etc/shadow, como ya vimos anteriormente. Lo primero es arrancar con un CD Live, y montar la partición donde se encuentra la carpeta /etc del sistema objetivo. Hecho esto, para modificar la contraseña de un usuario, debemos conocer primero cuál es la función hash empleada. Ésto lo podemos ver en /etc/pam.d/common-password, buscando una línea similar a la siguiente:

password [success=2 default=ignore] pam_unix.so obscure sha512

Ahora ya sabemos que se está empleando sha512 en este sistema. Solo nos queda conocer la "Salt" empleada en la contraseña, lo que podremos buscar en /etc/shadow, entre entre el primer y el segundo $. Por ejemplo, veamos la siguiente línea del archivo shadow:

mbaeza:$6$ss6rW4fc$R7nggW5Aqvu5lj0LYgqhNBvxDKHrUgkZ71PWf/UCpbYKdU8fbJO.zqp.AzYo5I1GC3VKvhppBZhW1U/nBvXkZ0:15132:0:99999:7:::

La "salt" empleada es ss6rW4fc. Tendremos que incluirla al final de la contraseña cuando queramos calcular el nuevo hash.

Para generar una nueva contraseña, podemos utilizar el comando mkpasswd, disponible en diferentes distribuciones, incluida Ubuntu. Pongamos que queremos asignar la contraseña "perro20" al usuario anterior. Entonces escribiremos:

mkpasswd -m sha-512 perro20 ss6rW4fc

Como resultado obtendremos una cadena como esta:

$6$ss6rW4fc$TK5eDwK5Dz43hVusa42OMNbf5YmIE43XzX4RrYUSqzCsP1GFCok/h4RxLBJaNDsfxmJ5WzkxxiGm4fl8NvZ/90

Esto significa que en el archivo /etc/shadow, deberíamos poner la cadena anterior en lugar de la contraseña acual del usuario. En lo sucesivo, el usuario "mbaeza" deberá usar la nueva contraseña si quiere acceder a su cuenta. Por supuesto, esto también se puede hacer con el usuario root.

Práctica 17. Crea en un sistema GNU/Linux una cuenta llamada "mgarcia" y asígnale una contraseña. Después inicia sesión con dicha contraseña. Reinicia el sistema y arranca desde un Live CD. Configura la red e instala el paquete mkpasswd, y modifica la contraseña de "mgarcia" para que su nueva contraseña sea "Cr@ck3d!".

Contramedidas contra los ataques offline

Como se ha podido ver, el sistema operativo tiene de por sí mecanismos para evitar que se puedan obtener los hashes de las contraseñas. Por esto, las técnicas que hemos visto requieren el acceso físico a la máquina, y arrancar desde alguna distribución Live.

Evitar esto pasa por reforzar la seguridad física, en primer lugar.

En segundo lugar, debemos evitar que se pueda arrancar desde un CD o una memoria flash externa, salvo que nosotros lo autoricemos. Es decir:

  • Como primera unidad de arranque en la BIOS estará especificado el disco duro de la máquina.
  • No se puede acceder a la configuración de la BIOS si no lo autorizamos.

Establecer una contraseña en la BIOS

Para establecer una contraseña en la BIOS, debemos ir a la pestaña dedicada a la seguridad, probablemente llamada "Security". Allí, podemos establecer dos tipos de contraseñas:

  • Supervisor password: se refiere a la contraseña para acceder a la configuración de la BIOS
  • User password: se refiere a la contraseña para que la BIOS inicie la secuencia de arranque
  • Además, pueden haber, dependiendo de la BIOS, más opciones, relativos al nivel de control que tendrá un usuario cuando acceda a la configuración de la BIOS.

Práctica 18. Asigna una contraseña a la BIOS de una de tus máquina virtuales. Asigna tanto una contraseña de supervisor, como una contraseña de usuario. Comprueba como las contraseñas se piden tanto para iniciar la secuencia de arranque, como para editar la configuración de la BIOS.

Desgraciadamente es posible saltarse esta barrera. Existen diferentes opciones para ello:

  • Quitar la pila de la placa base. Esto se puede evitar con control de acceso físico, y utilizando un candado para abrir la máquina.
  • Activando el jumper "CLR_CMOS" de la placa base. Se puede evitar de igual modo que en el caso anterior.
  • Utilizando una contraseña "backdoor" de la BIOS. Muchos chips incluyen una contraseña de recuperación que depende del fabricante. Solo podemos controlar este ataque mediante control de acceso físico.
  • Existen programas y distribuciones que permiten el reseteo de la contraseña. Esta opción requiere el arranque desde una distribución live (como UBCD). Este ataque se controlará mediante control de acceso físico, y una contraseña de la BIOS fuerte, que combine mayúsculas, minúsculas y números.
  • Un atacante también puede instalar software con permisos de administrador para resetear la contraseña de la BIOS. Una vez detectada la intrusión, se debe estudiar el alcance del ataque y las medidas de contención del mismo, ya que el atacante ya se ha podido hacer con el control del sistema.

Contraseña para GRUB

Puesto que vamos a trabajar en una máquina virtual con GNU/Linux recién instalado, solo estárá este sistema en la máquina. Por defecto, Ubuntu (la distribución que estamos utilizando) no muestra el menú de Grub2 cuando arrancamos si solamente tenemos un sistema operativo instalado. Para poder probar el uso de contraseñas, vamos (para empezar) a mostrar dicho menú. Así que editamos el archivo /etc/default/grub y añadimos el símbolo "#" delante de la línea GRUB_HIDDEN_TIMEOUT=0. Hecho esto, ejecutamos el comando update-gr2. La próxima vez que iniciemos, nos aparecerán las entradas de Grub2.

Ahora vamos a crear una contraseña para la entrada correspondiente a la consola de recuperación, es decir, "Ubuntu, con Linux 2.6.32-33-generic (modo recuperación)". Para ello, lo primero es ejecutar el comando grub-mkpasswd-pbkdf2. El resultado será algo como esto:

Enter password: Reenter password: Your PBKDF2 is grub.pbkdf2.sha512.10000.823F1CCFAD6D4918E9030D3D 83895D2829E0713F764E06295765E545B7E888AEAD3E6C53AC8587B94142B882 BBE28EE63608EDC5C6ABBE558F7BADCB354E9F11.BE4F2EDB3FFB713C0527951 428FAB27B5EAD07EBE79E6EC2FF7D5E1E928C4E62F4F7E57F7B22F0A605C6DF2 E0198211C3CA2A5E6722CF7797455DA57011822CD

El siguiente paso es abrir el archivo /etc/grub.d/00_header y añadir la siguiente línea al final:

cat << EOF set superusers="seguridad" password_pbkdf2 seguridad grub.pbkdf2.sha512.10000.823F1CCFAD6D4 918E9030D3D83895D2829E0713F764E06295765E545B7E888AEAD3E6C53AC858 7B94142B882BBE28EE63608EDC5C6ABBE558F7BADCB354E9F11.BE4F2EDB3FFB 713C0527951428FAB27B5EAD07EBE79E6EC2FF7D5E1E928C4E62F4F7E57F7B22 F0A605C6DF2E0198211C3CA2A5E6722CF7797455DA57011822CD EOF

donde la parte que empieza con "grub.pbkdf2..." es la que obtuvimos anteriormente al ejecutar "grub-mkpasswd-pbkdf2".

Podemos añadir tantos usuarios como queramos. Cada uno se añadiría al final del archivo /etc/grub.d/00_header.

Se pueden añadir contraseñas sin hashear, sustituyendo la lína password_pbkdf2 seguridad grub.pbkdf2... por password seguridad perro20, donde "perro20" sería la contraseña del usuario "seguridad".

Para terminar debemos ir a los scripts de grub2, ubicados en /etc/grub.d. Existen varios scripts, orientados a automatizar la construcción de la entradas de Grub. En concreto, el script 10_linux genera las entradas para los kernels de la distrubución. Al mirarlo se puede sentir algo de vértigo, pero en realidad, la finalidad de cada uno de los scripts es escribir una parte del archivo /boot/grub/grub.cfg.

Nuestro objetivo es introducir la cadena --users seguridad en la línea menuentry de la entrada que queremos proteger. Por ejemplo, cuando arrancamos, podemos ver Ubuntu, con Linux 2.6.32-33-generic (modo recuperación). Si abrimos el archivo /etc/grub.d/10_linux, podremos ver la parte del script que genera la entrada comentada:

if ${recovery} ; then title="$(gettext_quoted "%s, with Linux %s (modo recuperación)")" else title="$(gettext_quoted "%s, with Linux %s")" fi printf "menuentry '${title}' ${CLASS} {\n" "${os}" "${version}"

Para que la contraseña solo afecte a la entrada (modo recuperación), debemos sustituir esta parte del script por lo siguiente:

if ${recovery} ; then title="$(gettext_quoted "%s, with Linux %s (modo recuperación)")" contrasena="--users seguridad" else title="$(gettext_quoted "%s, with Linux %s")" contrasena="" fi printf "menuentry '${title}' ${contrasena} ${CLASS} {\n" "${os}" "${version}"

¿Entiendes lo que ha cambiado y por qué?

En realidad, protoger cualquier entrada, sea la que sea, sería igual.

Práctica 19. Protege mediante contraseña la entrada Ubuntu ... (modo recuperación) y Memory test (memtest86+). Cada entrada debe tener una contraseña diferente.

Estableciendo una contraseña para SYSKEY

Como ya hemos comentado con anterioridad, cuando hablábamos de los ataques offline a contraseñas en Windows, la SAM no se guarda en texto claro en el registro, sino que se antes se encripta con la SYSKEY. También comentamos que la SYSKEY se suele almacenar localmente, dispersa por el registro. El problema es que la forma de dispersar la SYSKEY es conocida. De hecho, como ya hemos visto, sepuede extraer una contraseña suficientemente débil mediante tablas rainbow con Ophcrack. Una opción para proteger la SAM de este tipo de ataques, es no almacenar la contraseña localmente.

Si ejecutamos el comando SYSKEY podemos establecer el modo en que la clave SYSKEY se almacena y se gestiona. El diálogo que se inicia, en primer lugar nos informa de que SYSKEY está activado. Si hacemos clic en actualizar, accedemos a un segundo diálogo donde se nos muestra las 3 formas de almacenar la clave:

  • Inicio con contraseña: la SYSKEY debe ser suministrada durante el inicio, ya que no se almacena localmente.
  • Almacenar la clave de inicio en un disco: requiere el uso de un disquete para guardar la SYSKEY.
  • Almacenar la clave de inicio localmente: esta es la opción por defecto.

La opción del disquete no es buena idea por la fragilidad y obsolescencia del soporte. En cambio, usar una contraseña puede ser una buena medida si queremos evitar que se extraigan los hashes de la SAM.

Práctica 20. Utiliza el sistema Windows en que utilizaste anteriormente Ophcrack con éxito. Cambia la configuración de la SYSKEY, para que haya que introducir una contraseña. Después, realiza un ataque offline con Ophcrack y sus tablas rainbow. ¿Conseguiste romper la contraseña que averiguaste anteriormente?

Control de acceso a datos y aplicaciones

Existen tres modelos de control de acceso en la actualidad. Estos modelos se usan para controlar los permisos de acceso a los recursos.

DAC (Discretionary Access Control): Permite que los propietarios de los datos configuren el control de acceso. Tienen control total sobre los archivos que crean. Este es el modelo por defecto en Linux y es el menos seguro. La única salvaguarda contra la pérdida de datos, son la sensatez del usuario, un buen esquema de copias de seguridad y software de recuperación. Este modelo no se debería utilizar en sistemas críticos para el negocio.

MAC (Mandatory Access Control): Los propietarios de los datos no tienen control total sobre el control de acceso a ellos. El control de acceso es gestionado por el personal de administración. Los usuarios y los archivos tienen un nivel de seguridad asignado y solo pueden acceder a los archivos cuyo nivel es igual o menor al suyo. Este modelo previene a los propietarios conceder permisos menos restrictivos a recursos cuyo nivel de seguridad definió un administrador. De hecho, MAC protege a los datos de su propietario, impidiendo su borrado por ejemplo. MAC aporta protección contra mal uso, abuso, errores o malas intenciones. Este modelo supone una sobregarga al trabajo de los administradores. En GNU/Linux SELinux y Apparmor utilizan un modelo MAC.

RBAC (Role-Based Access Control): El acceso a los datos se controla según el papel (rol) que juega el usuario en la organización. Los usuarios pueden ser asignados a muchos roles, los roles a muchos usuarios, cada rol puede estar asociado con muchos permisos y los permisos se pueden asignar a muchos roles. El modelo RBAC es el más complejo de todos, y dicha complejidad puede ser contraproducente. En GNU/Linux, sudo y SELinux están basados en este modelo.

Problemas del control de acceso en *NIX

El modelo tradicional de control de acceso de UNIX, lleva funcionando 40 años, y sigue siendo efectivo, por su simplicidad. Sin embargo, tiene algunos inconvenientes:

  • La cuenta root supone un problema de seguridad. Si es comprometida, la integridad de todo el sistema también lo será.
  • La única forma de subdividir los privilegios de root es escribiendo programas setuid/setgid. Pero la escritura de software seguro no es fácil.
  • El modelo de seguridad no es suficientemente fuerte para el trabajo en red. La misma UID puede significar cosas diferentes en máquinas diferentes, si se hacen cambios.
  • Ciertas convenciones de seguridad específicas son complicadas de cumplir. Por ejemplo, la mostrada en la siguiente imagen:
  • Muchas reglas del control de acceso están incrustadas en el software. Pero no es práctico modificarlo y recompilarlo.
  • Existe un soporte mínimo para la auditoría. Podemos ver la pertenencia de usuarios a grupos, pero esta información no nos deja claro que pueden o no hacer estos usuarios.

Soluciones para el control de acceso en *NIX

Los inconvenientes mencionados han dado como resultado soluciones de seguridad. La más universal es PAM, que ya vimos con anterioridad.

La cuenta "root" sigue siendo el centro del control de acceso, y por tanto lo más importante a proteger. Por ello algunas cosas importantes sobre root, son:

  • Contraseña: el método llamado "shocking nonsense" ya fue comentado con anterioridad.
  • Cambio de contraseñas: es preciso cambiarlas cada 3 meses como mínimo. Esto es especialmente exigible en sistemas críticos.
  • Gestión de las contraseñas: se debe contar con algún sistema para almacenar y consultar las contraseñas. Van desde caros sistemas empotrados (CyberArk) hasta software libre (KeePass).
  • Pseudo usuarios: muchos usuarios son definidos por el sistema para la ejecución de servicios. Tienen UIDs entre 10 y 100. Es importante sustituir en /etc/shadow sus contraseñas por un "*". Además, no deben tener shell disponible (/bin/false o /bin/nologin).
  • sudo: RBAC es implementado en GNU/Linux por SELinux, un sistema complejo. Es difícil permitir a alguien que pueda hacer backups sin que corra libre por el sistema, por ejemplo. Si hay más de un administrador, todos usando root, es difícil controlar quién hace qué. La solución más usada (basada en RBAC) es sudo. Sudo permite definir alias para recursos, para conjuntos de comandos y para permisos de los usuarios sobre ellos.

SUDO

Para entender como funciona sudo, hay varios textos sobre ello: Sudoers en la documentación de Ubuntu, Manual de sudo para bisoños, Manual de configuración de fichero sudoers y Manual de SUDO de Linux Magazine.

Práctica 21. Descarga e instala algún software para la gestión de contraseñas como Keepass (keepassx para Ubuntu). Cubre al menos las siguientes tareas:

  • Utiliza una contraseña maestra segura, según lo que hemos visto en este mismo tema.
  • Crea un archivo de dicho programa para tus contraseñas personales.
  • Añade en el archivo de contraseñas todas tus contraseñas personales.
  • Guarda el archivo de las contraseñas en remoto (Dropbox por ejemplo) para que en caso de desastre, puedas recuperar tus contraseñas.
  • Si utilizas la misma contraseña para varios sitios, este es el momento de cambiar el problema.

Práctica 22. crear 3 usuarios: jperez, agonzalez y pgarcia. Después haz las siguientes cosas:

  • Crear un alias para agonzalez y pgarcia, llamado OPERADORES.
  • Crear un alias llamado NETWORKING, para los siguientes comandos: ifconfig,dhclient,ifup e ifdown.
  • El usuario jperez puede ejecutar como root el comando ls.
  • Los operadores pueden revisar los logs ejecutando como root el comando cat sobre los archivos del directorio /var/log.
  • Permitir al usuario jperez editar el archivo de configuración de la red /etc/network/interfaces.
  • Permitir al usuario jperez reconfigurar la red, ejecutando el script /etc/init.d/networking restart, y los comandos NETWORKING.
  • Configurar sudo de forma que se pida la contraseña del usuario destino (debeis tener cuiadado con esto, puesto que en ubuntu, el usuario root no tiene contraseña por defecto. Antes de guardar la nueva configuración, es preciso asignar una contraseña a root).

El uso de sudo tiene las siguientes ventajas:

  • El registro de responsabilidades (accountability) está claramente mejorado, ya que es posible ver el historial de comandos de un usuario.

  • Los administradores pueden trabajar sin permisos de root ilimitados.
  • La contraseña real de root puede ser conocida solo por una o dos personas (o 0 personas a ser posible, si usamos algo como KeePass).
  • Los privilegios se pueden revocar sin cambiar la contraseña de root.
  • Existe una lista con los usuarios sudoer.
  • Hay menos oportunidades de dejar una "root shell" desatendida.
  • Un solo archivo puede ser usado para controlar el acceso para toda una red.

En definitiva, sudo es un mecanismo superior para la división de privilegios en GNU/Linux.

CONSEJO: Lanzar un password cracker contra los usuarios sudoers periódicamente. Así sabremos si están bien elegidas las contraseñas.

CONSEJO: Cuidado con dejar comandos como su o sh entre los permitidos para los sudoers. En tal caso, podrán hacer "sudo su" o "sudo sh".

POSIX ACL

Otros modelos se pueden implementar, además de sudo. Por ejemplo, POSIX, incorpora un modelo de ACL más compleja que la tradicional de UNIX. Normalmente los administradores de sistemas *NIX suelen encontrar suficiente el modelo tradicional de permisos, pero en ciertos casos concretos, con muchos usuarios, puede ser útil un mayor nivel de granularidad. Los sisetmas *N?X actuales incorporan soporte para POSIX. Nosotros nos vamos a centrar en GNU/Linux.

Vamos a leer el manual siguiente: Activar soporte para POSIX ACL en Debian y Ubuntu [EN]

Práctica 23. Crea un usuario en Ubuntu, llamado "pruebaacl". Monta una unidad para que soporte POSIX ACL, y crea allí un archivo llamado "testACL". Usuario y grupos propietarios serán "root" y el resto no tendrá permisos. Se pide asignar mediante "POSIX ACL" permisos de lectura y escritura al usuario "pruebaacl". [Muestra: los permisos tradicionales, los permisos extendidos y al usuario "pruebaacl" accediendo al usuario.]

Otros temas de interés

El tema del control de acceso, es muy extenso. Existen otros mecanismos que hemos dejado sin comentar. En concreto, es interesante conocer el modo en que los sistemas operativos manejan los permisos cuando el usuario es un servicio. Los sistemas operativos modernos, tratan de evitar que un servicio pueda llevar a cabo acciones ilegales que puedan comprometer al sistema.

Nos dejamos en el tintero hablar de LSA, security principals, tokens, suplantación y UAC. Recomiendo el libro "Windows Server 2008 Security Resource Kit" de Microsoft Press.

En cuanto a Linux, debemos conocer AppArmor (utilizado por defecto en Ubuntu) o SELinux (siendo este más complejo que el anterior, y por ello, menos utilizado). Sobre AppArmor, os dejo este recurso: Armado y protegido con AppArmor

Os lo dejo a vosotros.