El mítico Kerberos
Uno de los servicios más utilizados actualmente para la autenticación en diferentes organizaciones es kerberos. Cualquiera que utilice o haya utilizado Active Directory seguramente conozca, aunque sea vagamente, kerberos, dado que este entorno lo utiliza como base. También se utiliza bastante en soluciones empresariales de Red Hat.
Dado que es un servicio de mucha importancia y uno de los que cualquier persona que trabaje en administración de sistemas o seguridad debe conocer, me parece bien dedicar un artículo para describir como funciona. En un próximo artículo veremos cómo instalarlo y configurarlo en GNU/Linux.
Este artículo forma parte del proyecto Autenticación y administración centralizada de usuarios en GNU/Linux.


Qué es?

Kerberos es un protocolo de autenticación desarrollado por el MIT e implementado en varios sistemas operativos. La principal función es permitir que dos nodos puedan autenticarse entre sí sobre una red insegura. Se utiliza principalmente en modelos cliente-servidor donde cliente y servidor pueden autenticarse mutuamente.
Kerberos funciona utilizando criptografía simétrica y requiere de una tercera parte confiable (siempre hay que confiar en alguien...).

Dato interesante: el nombre kerberos proviene del perro con tres cabezas y cola de serpiente, guardian de la entrada del templo de Hades en la mitología griega. El nombre era acertado porque la idea era proveer 3 mecanismos de seguridad: autenticación, contabilidad y auditoria. Desgraciadamente, sólo se implementó el componente de autenticación.

En el modelo kerberos contamos con dos servidores lógicos (que en la práctica suelen estar implementados en un sólo servidor físico denominado Key Distribution Center o KDC):
  • Authentication Server (AS): servidor encargado de autenticar al cliente y proveer un ticket para contactar al TGS. Este servidor almacena la clave de los clientes y las utiliza para autenticarlos.
  • Ticket Granting Server (TGS): servidor encargado de proveer tickets a los clientes para que puedan acceder al servicio deseado.

Qué servicios se puede acceder con un ticket de kerberos? cualquiera que implemente este tipo de autenticación. Por ejemplo, la autenticación de usuarios en un sistema operativo, acceso a servicios ldap, web, smtp, etc. Para poder utilizar un servicio kerberizado, el cliente debe primero contactar al AS y el TGS para obtener un ticket, que luego utiliza para acceder el servicio.
Los tickets tienen una validez de tiempo limitada, para lo cual se utilizan timestamps. Debido a esto, tanto clientes como servidores deben tener sus relojes sincronizados, porque sino el sistema no funciona. Normalmente esta sincronización se realiza utilizando el protocolo NTP.


Descripción del protocolo

El handshake de autorización para acceder a un servicio es la siguiente:
  • Cliente C contacta al AS requieriendo acceso a un servicio del Service Server (SS).
  • AS utiliza la clave que tiene almacenada del usuario (user master key) para encriptar la clave de sesión necesaria para encriptar los mensajes con el TGS (TGSsk). Además, AS envía al cliente otra tupla (denominada Ticket Granting Ticket - TGT) pero encriptada con la clave del TGS, la cual contiene el ID del cliente, la dirección de red del mismo, el tiempo de validez del ticket y la clave de sesión (TGSsk).
  • Cuando el cliente recibe los mensajes, desencripta el primero para obtener la clave de sesión TGSsk. Al desencriptar este mensaje, prueba quién es, dado que otro cliente no tendrá la clave necesaria para desencriptar el mensaje. El TGT no lo desencripta porque está encriptado con la clave del TGS.
  • El cliente ahora envía el TGT al TGS y un mensaje autenticador, compuesto por el ID del cliente y el timestamp, encriptado con la clave de sesión TGSsk.
  • Una vez que el TGS recibe los mensajes del cliente, desencripta el TGT para obtener la clave de sesión TGSsk, y con esta clave desencripta el otro mensaje (el autenticador) y responde al cliente enviando un nuevo ticket, muy similar al TGT, pero para ser utilizado con el Service Server, que provee el servicio deseado (por ejemplo ldap). Este mensaje contiene el ID del cliente, la dirección de red, el período de validez y una nueva clave de sesión para utilizar con el servidor (SSsk). Además, envía otro mensaje que contiene el SSsk, encriptado con la clave de sesión del TGS (TGSsk).
  • Finalmente el cliente tiene todo lo necesario para acceder el servicio que desea, por lo que contacta al SS enviando el ticket que recibió del TGS y un nuevo autenticador encriptado con la SSsk.
  • SS desencripta el ticket recibido para obtener la clave de sesión SSsk, con la cual desencripta el autenticador del cliente. SS responde con el último mensaje del handshake inicial que contiene el timestamp encontrado en el autenticador del cliente más 1, encriptado con la clave de sesión SSsk.
  • Con el último mensaje el cliente puede comprobar la autenticidad del servidor.

Resumiendo, obtenemos el siguiente flujo:
C ---- pedido de servicio -----> AS
AS ---- TGSsk encriptada con clave del cliente ----> C
AS ---- TGT ----> C
C ---- TGT ----> TGS
C ---- autenticador encriptado con TGSsk ----> TGS
TGS ---- ticket para acceder servicio ----> C
TGS ---- SSsk encriptado con clave del cliente ----> C
C ----> ticket para acceder servicio ----> SS
C ----> autenticador encriptado con SSsk ----> SS
SS ----> timestamp +1 encriptado con la clave de sesión SSsk ----> C

Sí, parece (o es) tremendo lío el sistema de autenticación, pero es efectivo y seguro, y prestando atención llega a entenderse bien (aunque con el tiempo uno se vuelve a olvidar =P).
Gracias a que la autenticación con usuario y contraseña genera el TGT, para acceder a distintos servicios sólo necesitamos este ticket, por lo cual no es necesario cargar las credenciales por cada servicio accedido. Esto permite que sistemas como el single sign-on funcionen. Además el TGT puede ser renovable dentro de un dado período de tiempo, lo que da flexibilidad a servicios que necesitan mucho tiempo para completarse.

Se desprende de la explicación anterior que el KDC contiene todas las credenciales de todos sus usuarios. Obviamente estas credenciales no se almacenan de forma plana en la base de datos. La base de datos se encripta utilizando una master key que el administrador debe elegir al momento de configurar el KDC. Pero esta master key también debe estar almacenada en algún lugar si se desea que el servicio se cargue automáticamente! En el kerberos de MIT la master key se almacena en el archivo stash. En AD existe un usuario denominado kbrtgt cuya contraseña es la utilizada como master key del KDC, este usuario no puede loguearse y está deshabilitado.


Limitaciones y desventajas

  • La obvia desventaja de un sistema de autenticación centralizado es el único punto de falla. Si se cae el AS o el TGS, nadie puede acceder a ningún servicio. Esto se soluciona utilizando más de un servidor y replicando los datos.
  • Todos los participantes deben tener coordinados sus relojes, porque sino, los tickets no funcionan.
  • Dado que todas las claves se almacenan en un servidor, si un atacante logra hackearlo, podrá acceder como cualquier usuario!
  • Otro problema es el replay attack, un ataque que no simple, pero tampoco imposible como se demuestra en el paper Replay Attack on Kerberos V and SMB.


Terminología

En el mundo kerberos existen ciertas definiciones que es necesario conocer para poder configurarlo correctamente. Veamos entonces los términos utilizados:
  • Realm (reino, interesante nombre): indica el dominio de autenticación. El realm establece los límites en los cuales un servidor de autenticación tiene autoridad para autenticar usuarios, hosts o servicios. Es posible, sin embargo, realizar autenticaciones cross-realm entre, por ejemplo, un usuario de un realm y un servicio de otro. Esto se lleva a cabo a través de una relación de confianza entre los realms que debe ser establecida previamente.
  • Básicamente un usuario/servicio pertenece a un realm sólo si comparte un secreto (password/key) con el servidor de autenticación. Es recomendable que el nombre del realm sea igual al del dominio (DNS) en el que nos encontramos, escrito con letras mayúsculas (los nombres son case-sensitive). Si nuestro dominio es demasiadovivo.org, lo aconsejable es nombrar al realm DEMASIADOVIVO.ORG.
  • Principal: es el nombre utilizado para referirse a las entradas en la base de datos del servidor de autenticación. Cada usuario/host/servicio del realm tiene asociado un principal (string) que lo identifica. Ejemplos de principals son el nombre de usuario, el nombre de un host, etc. Cada principal puede tener varios componentes, pero generalmente se usan 3:
    • primary: la primera parte del principal. En el caso de un usuario, este es su nombre de usuario. En el caso de un servicio, es el nombre del servicio.
    • instance: la segunda parte de principal. Da información que califica al primary y puede ser null. En el caso de un usuario, el instance suele usarse para describir el uso para el cual están destinadas las credenciales. En el caso de un host, el instance es el hostname.
    • realm: el nombre del realm en mayúsculas.
    Los principals se escriben con el formato "primary/instance@REALM". Por ejemplo, un principal para el servicio ldap sería ldap/lab.demasiadovivo.org@DEMASIADOVIVO.ORG
  • Ticket: en la explicación anterior se describió el concepto de tickets en kerberos. Un ticket permite demostrar la autenticidad de un cliente. Los tickets caducan luego de un cierto tiempo, y es necesario obtener uno nuevo cuando esto sucede, o bien renovarlo si esto es posible.
  • Keytab: es un archivo que contiene pares principal -> clave. Este archivo se puede utilizar para obtener tickets sin que el sistema pida password en el proceso de autenticación. El uso más común es en scripts que necesitan utilizar kerberos sin interacción humana. Los archivos keytab son muy importantes y deben mantenerse seguros.


Referencias

- Kerberos protocol wik
- The Kerberos protocol and its implementation
- Kerberos FAQ, v2.0
Sincronicemos relojes con NTP
En el artículo Configurar NTP en GNU/Linux se explicó como instalar y configurar NTP en una máquina cliente, pero faltaron detalles concernientes al protocolo y la instalación de servidores. El protocolo NTP es el más conocido y utilizado para sincronización de relojes, por lo cual es importante conocer las bases del mismo antes de instalar el servicio.

De la teoría de sistemas distribuidos sabemos que existen varios algoritmos para esta tarea. NTP emplea el algoritmo de Marzullo para la estimación, y usa un sistema jerárquico de niveles de fuentes horarias. Cada nivel se denomina stratum, y comienzan en el valor 0. Este valor se utiliza para indicar la distancia desde la fuente horaria, y no es un indicador de calidad o confiabilidad, dado que hay fuentes de stratum 3 de mejor calidad que algunos stratum 2.
Los stratum se definen de la siguiente manera:
  - stratum 0 son dispositivos como relojes atómicos (por ejemplo de cesio), GPS, u otros relojes de radio. En general, estos dispositivos no están conectados a la red, sino conectados a computadoras (por ej, por RS-232).
  - stratum 1 son computadoras conectadas a dispositivos stratum 0. Normalmente actúan de servidores NTP para servidores de stratum 2.
  - stratum 2 son computadoras que envían solicitudes a servidores stratum 1. Estas computadoras suelen utilizar varias fuentes stratum 1 y utilizan el algoritmo NTP para obtener la mejor muestra. Las computadoras de este stratum se comunican entre sí en modalidad peer-to-peer para proveer tiempos más estables y robustos.
  - stratum 3 son computadoras que emplean las mismas funciones que las de stratum 2, y pueden actuar de servidores de capas inferiores. NTP soporta hasta el stratum 256.
De esta organización jerárquica, tenemos que un cliente NTP puede operar en modelo cliente-servidor (donde el stratum del cliente es 1 más que el del servidor), o peer-to-peer (clientes con el mismo stratum). Además de estas dos, un servidor NTP puede funcionar enviando la hora en forma broadcast o multicast, y los clientes se configuran para sincronizarse con estas señales.

El proceso comienza cuendo un cliente NTP envía un paquete conteniendo su timestamp a un servidor. Cuando el servidor recibe el paquete, este almacena su propio timestamp y un timestamp de transmisión en el paquete, y lo envía de regreso al cliente. Una vez que el cliente recibe la respuesta, logguea la hora a la que lo recibió para estimar el tiempo de transmisión del paquete.
Teniendo varias fuentes horarias, el algoritmo de Marzullo selecciona las fuentes que se consideren confiables (en base a ciertos parámetros) para encontrar la hora precisa. De los intervalos retornados por las fuentes, se calcula el menor intervalo que sea consistente con el mayor número de fuentes (intersección). Si por ejemplo, los intervalos son [8,12], [11,13] y [10,12], la intersección de todos da [11,12]. Si en cambio, los intervalos son [8,12], [11,13] y [14,15], no existe un intervalo consistente con todos los valores, pero [11,12] es consistente con el mayor número de fuentes.
En el algoritmo original de Marzullo, el mejor valor se toma como el centro del intervalo. Un acercamiento más sofisticado (y utilizado en NTP) es reconocer que esto puede desperdiciar información valiosa de los intervalos confiables, y por ello es mejor utilizar un modelo probabilístico, que puede retornar un valor distinto al centro.

En GNU/Linux se instala un demonio que puede actuar como servidor y cliente, permitiendo sincronizar relojes con servidores de stratums superiores o entre pares del mismo nivel. La diferencia entre un servidor y un cliente está dada por los comandos de control de acceso.

En una configuración estándar, un host que trabaje de servidor puede configurarse teniendo en cuenta lo siguiente:
  - debe contener al menos una fuente horaria superior (por ejemplo relojes stratum 2 o 1), o bien deben existir otros servidores del mismo nivel (peers) para calcular la hora, o ambos.
  - debe utilizar una fuente horaria local, para el caso en que no se pueda conectar con otros servidores.
  - debe permitir que hosts de la red consulten la hora, pero que no participen en el cálculo de la hora, o modifiquen la configuración.
Por su parte, un host cliente debera configurarse teniendo en cuenta que:
  - debe sincronizar su hora con uno o más servidores NTP superiores
  - no debe permitir que otros hosts consulten su hora, ni alteren la configuración.

Como se vió en el artículo anterior, la instalación del demonio NTP es tan simple como:
  # apt-get install ntpd

Los comandos más utilizados dentro de la configuración (/etc/ntp.conf) son:
  * server define servidor superior con el cual conectarse para obtener información horaria
    + iburst envía una ráfaga de ocho paquetes en lugar de uno en caso que el servidor esté inalcanzable
  * peer define un servidor NTP que se encuentra al mismo nivel
  * fudge permite establecer el stratum de un servidor
  * restrict establece el control de acceso para una dada red o host:
    + kod envía un paquete "kiss of death" si el flag limited está presente y un paquete viola el límite de rate establecido
    + notrap niega el uso del servicio trap
    + nomodify niega consultas que intenten modificar el estado del servidor
    + nopeer evita que el host sea utilizado como servidor de hora
    + noquery previene consultas por el estado del ntpd
 
Teniendo en cuenta lo descripto líneas atrás, la configuración (/etc/ntp.conf) debe contener lo siguiente:
  - En servidores NTP:
    # servidores default debian, cambiar por los deseados
    server 0.debian.pool.ntp.org iburst
    server 1.debian.pool.ntp.org iburst
    server 2.debian.pool.ntp.org iburst
    server 3.debian.pool.ntp.org iburst

    # configurar un servidor del mismo nivel (opcional)
    # peer 192.168.1.10
 
    # reloj local como fuente en caso que la conexión a internet se corte (esto lo asegura el stratum 10)
    server 127.127.1.0
    fudge  127.127.1.0 stratum 10
 
    # acceso completo para localhost
    restrict 127.0.0.1
 
    # permitir a los hosts de la red 192.168.1.0/24 realizar consultas, pero no modificar nada
    restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
 
    # restringir el acceso a todo el resto
    restrict default kod notrap nomodify nopeer noquery

  - Los hosts clientes, por su parte, deberán contar con las líneas:
    # direccion del servidor configurado anteriormente (ej 192.168.1.56)
    server 192.168.1.56
 
    # restringir consultas para que otros hosts no lo utilicen como servidor
    restrict default kod notrap nomodify nopeer noquery

Una vez terminada la configuración, reiniciar el demonio en clientes y servidores:
  # /etc/init.d/ntp restart

Para testear la configuración, se puede ejecutar:
  # ntpq -p
  # ntpdc -p


Referencias

- Network Time Protocol wiki
- Marzullo's algorithm wiki
- Introduction to NTP
- Network Time Protocol daemon
- Access Control Commands and Options
- 6.5. ntpd access restrictions
Autenticación y administración centralizada de usuarios en GNU/Linux
Desde que estoy en mi actual trabajo, me vi forzado a utilizar Active Directory (AD), a aprender de qué trata, cómo funciona, y cómo administrarlo.
Realmente este servicio me parece una buena idea por parte de MS, y a nivel empresa es muy útil. La experiencia en el trabajo me enseñó que cuando la cantidad de usuarios supera un cierto número, administrarlos por workstation y/o por servicio es muy complejo, inaceptable. Además, la facilidad de independizar al usuario de la workstation en la que se encuentra, es muy importante para muchas empresas.
El problema, claro está, es que AD es de MS, con todo lo que ello representa:
- código cerrado
- licencias caras y limitantes
- poco flexible
- software malo (si, la idea de AD es buena, pero el soft de MS es malo)
- hay que utilizar Windows
- fuerza a utilizar más software MS, gracias a su política "incompatible con el mundo no MS"
- no se puede aprender de él
- mientras todo anda, es fácil, pero cuando algo falla, arreglarlo es extremadamente difícil
- etc, etc
No es ningún secreto que MS no me cae bien, y creo que las razones anteriores son suficientes para ello.
Por eso me di a la tarea de buscar una alternativa libre que brinde capacidades similares. El objetivo es tener un sistema centralizado de usuarios, donde los usuarios tienen una identidad única para utilizar el sistema operativo (y las aplicaciones que utilicen autenticación integrada) desde cualquier máquina.

MS no inventó nada nuevo con Active Directory, sino que supo combinar protocolos que ya se utilizaban desde hace años y que mayoritariamente nacieron como protocolos libres, por lo cual existen alternativas para cada componente. El problema es unir estos componentes para que trabajen en conjunto.
Los componentes básicos para lograr la funcionalidad deseada son:
- Autenticación con Kerberos.
- NTP para mantener sincronizados los relojes (requerimiento importante para kerberos).
- Servicio de directorio LDAP para almacenar datos de usuarios, grupos, hosts, etc.
- DNS para asignar nombres de dominio.
- DHCP para distribuir direcciones IPs (opcional pero muy útil).
- Replicación de los datos entre múltiples servidores (multi-master replication).
- Administración de seguridad a través de políticas de grupo (GPOs).
Es claro que AD no se queda ahí y gracias al la integración con el resto del soft MS, es posible tener integrado servicio de email (Exchange), y servicio de archivos (SMB), entre otros.

Sacando las GPOs, todo el resto se puede lograr utilizando software libre, por ejemplo:
- MIT Kerberos
- NTP
- OpenLDAP
- Bind (DNS)
- Samba
- Postfix
La tarea entonces es configurar los servicios para que trabajen en conjunto.
Existe mucha información en internet sobre cómo lograr que las herramientas interactúen, pero poco sobre proyectos que integren todo.
El más notable al respecto es la distribución Calculate Linux. Si bien todavía no probé esta distribución, la descripción de la misma es muy alentadora, ya que hasta permite integrar hosts Windows para que interactúen con los servidores Linux.

En base a lo expuesto, desde hace un par de meses estoy trabajando en armar una infraestructura como la de Active Directory, pero utilizando software libre y documentando todo al respecto, desde la definición de kerberos y LDAP, hasta la instalación y configuración de los diferentes servicios en servidores y clientes para lograr la funcionalidad deseada.
Como la información es mucha, decidí repartirla en varios artículos que iré publicando a lo largo del próximo mes (o tal vez dos meses). Uno de estos artículos ya lo publiqué hace un par de semanas, y trata sobre PAM.
La lista de artículos es la siguiente:
- Un servicio básico, el DNS: breve descripción y cómo utilizar bind
A medida que los vaya publicando, volveré a este artículo para actualizar los links y tener así todo integrado.
De los citados, sólo me falta escribir el de DNS, y puede que alguno lo termine partiendo en 2 por ser muy largos, pero básicamente no cambiará mucho a lo planteado.
También espero tener tiempo de armar un sistema de archivos y montar un servidor de mail con postfix, pero como viene la mano en el trabajo, puede que eso quede para más adelante.

Mi recomendación es que si les interesa la idea, vayan armando sus propios proyectos y compartan dudas, mejoras o lo que se les ocurra. Pueden utilizar comentarios en el blog o en la página de IT Freek Zone en facebook.
Les recomiendo utilizar máquinas virtuales para poder probar servidores y clientes con una sola máquina de forma rápida. Además clonando discos virtuales es fácil deshacer y volver a empezar.