Manual de FreeBSD
Anterior | Capítulo 14. Seguridad | Siguiente

# 14.8. Kerberos5

Texto de Tillman Hodgson. Basado en un texto de Mark Murray.

Cada versión de FreeBSD posterior a FreeBSD-5.1 incluye soporte solamente para Kerberos5. Por esta razón Kerberos5 es la única versión incluida. Su configuración es similar en muchos aspectos a la de KerberosIV. La siguiente información solo atañe a Kerberos5 en versiones de FreeBSD-5.0 o posteriores. Los usuarios que deséen utilizar KerberosIV pueden instalar el port `security/krb4`.

Kerberos es un sistema/protocolo agregado para red que permite a los usuarios validar su identidad a través de los servicios de un servidor seguro. Los servicios como login remoto, copia remota, copias de fichero de un sistema a otro y otras tareas generalmente consideradas poco seguras pasan a ser considerablemente seguras y más controlables.

Kerberos puede describirse como un sistema proxy identificador/verificador. También puede describirse como un sistema confiable de autentificación de terceros. Kerberos solamente ofrece una función: la validación segura de usuarios a través de una red. No proporciona funciones de autorización (es decir, lo que los usuarios tienen permitido hacer) o funciones de auditoría (lo que esos usuarios hicieron). Después de que un servidor y un cliente han usado Kerberos para demostrar su identidad pueden también cifrar todas sus sus comunicaciones, asegurando de este modo su intimidad y la integridad de sus datos durante su uso del sistema.

Es, por tanto, altamente recomendable que se use Kerberos además de otros métodos de seguridad que ofrezcan servicios de autorización y auditoría.

Puede usar las siguientes instrucciones como una guía para configurar Kerberos tal y como se distribuye en FreeBSD. De todas maneras, debería consultar las páginas de manual adecuadas para tener toda la información.

Vamos a mostrar una instalación Kerberos, para lo cual usaremos los siguientes espacios de nombres:

- El dominio DNS (“zona”) será ejemplo.org.

- El dominio Kerberos (realm) será EJEMPLO.ORG.

> Nota: Debe utilizar nombres de dominio reales al configurar Kerberos incluso si pretende ejecutarlo internamente. Esto le evitará problemas de DNS y asegura la interoperación con otros dominios Kerberos.

## 14.8.1. Historia

Kerberos fué creado en el Massachusetts Institute of Technology (MIT) como una solución a los problemas de seguridad de la red. El protocolo Kerberos utiliza criptografía fuerte para que un cliente pueda demostrar su identidad en un servidor (y viceversa) a través de una conexión de red insegura.

Kerberos es el nombre de un protocolo de autentificación vía red y un adjetivo para describir programas que implementan el programa (Kerberos telnet, por ejemplo, conocido también como el “telnet kerberizado”). La versión actual del protocolo es la 5, descrita en RFC 1510.

Existen diversas implementaciones libres de este protocolo, cubriendo un amplio rango de sistemas operativos. El MIT, donde Kerberos fué desarrollado, continúa desarrollando su propio paquete Kerberos. Suele usarse en los EEUU como producto criptográfico y como tal ha sufrido las regulaciones de exportación de los EEUU. El Kerberos del MIT existe como un port en (`security/krb5`). Heimdal Kerberos es otra implementación de la versión 5, y fué desarrollada de forma intencionada fuera de los EEUU para sortear las regulaciones de exportación (y por eso puede incluirse en versiones no comerciales de UNIX®). La distribución Heimdal Kerberos está en el port (`security/heimdal`), y se incluye una instalación mínima en el sistema base de FreeBSD.

Para alcanzar la mayor audiencia estas instrucciones asumen el uso de la distribución Heimdal incluída en FreeBSD.

## 14.8.2. Configuración de un KDC Heimdal

El centro de distribución de llaves (KDC, Key Distribution Center) es el servicio centralizado de validación que proporciona Kerberos: es el sistema que emite tickets Kerberos. El KDC goza del estátus de ser considerado como “confiable” por las demás computadoras del dominio Kerberos, y por eso tiene consideraciones de seguridad más elevadas.

Tenga en cuenta que, aunque la ejecución del servidor Kerberos requiere muy pocos recursos, se recomienda el uso de una máquina dedicada a KDC por razones de seguridad.

Para empezar a configurar un KDC asegúrese de que su `/etc/rc.conf` contenga la configuración adecuada para actuar como KDC (tal vez deba ajustar algunas rutas para que cuadren con su sistema):

    kerberos5_server_enable="YES"
    kadmind5_server_enable="YES"
    kerberos_stash="YES"

> Nota: `kerberos_stash` solo existe en FreeBSD 4.X.

A continuación configuraremos el fichero de configuración de Kerberos, `/etc/krb5.conf`:

    [libdefaults]
        default_realm = EJEMPLO.ORG [realms]
        EXAMPLE.ORG = {
            kdc = kerberos.ejemplo.org
            admin_server = kerberos.ejemplo.org
        }
    [domain_realm]
        .ejemplo.org = EJEMPLO.ORG

Tenga en cuenta que este `/etc/krb5.conf` implica que su KDC tendrá el nombre de equipo completo calificado de `kerberos.ejemplo.org`. Necesitará añadir una entrada CNAME (alias) a su fichero de zona si su KDC tiene un nombre de equipo diferente.

> Nota: En grandes redes con un servidor DNS BIND bien configurado, el ejemplo de arriba puede quedar del siguiente modo:

>     [libdefaults]
>           default_realm = EJEMPLO.ORG

> Con las siguientes líneas agregadas al fichero de zona `ejemplo.org`:

>     _kerberos._udp      IN  SRV     01 00 88 kerberos.ejemplo.org.
>     _kerberos._tcp      IN  SRV     01 00 88 kerberos.ejemplo.org.
>     _kpasswd._udp       IN  SRV     01 00 464 kerberos.ejemplo.org.
>     _kerberos-adm._tcp  IN  SRV     01 00 749 kerberos.ejemplo.org.
>     _kerberos           IN  TXT     EJEMPLO.ORG

> Nota: Para que los clientes sean capaces de encontrar los servicios Kerberos debe tener ya sea un `/etc/krb5.conf` configurado o un `/etc/krb5.conf` configurado de forma mínima y un servidor DNS configurado correctamente.

A continuación crearemos la base de datos Kerberos. Esta base de datos contiene las llaves de todos los principales cifradas con una contraseña maestra. No es necesario que recuerde esta contraseña, pues se almacenará en `/var/heimdal/m-key`. Para crear la llave maestra ejecute `kstash` e introduzca una contraseña.

Una vez que se ha creado la llave maestra puede inicializar la base de datos usando el programa `kadmin` con la opción `-l` (que significa “local”). Esta opción le dice a `kadmin` que modifique los ficheros de la base de datos directamente en lugar de ir a través del servicio de red `kadmind`. Esto gestiona el problema del huevo y la gallina de tratar de conectar a la base de datos antes de que ésta exista. Una vez que tiene el “prompt” de `kadmin`, utilice `init` para crear su base de datos de dominios iniciales.

Para terminar, mientras está todavía en `kadmin` puede crear su primer principal mediante `add`. Utilice las opciones por defecto por ahora, más tarde puede cambiarlas mediante `modify`. Recuerde que puede usar `?` en cualquier “prompt” para consultar las opciones disponibles.

Veamos un ejemplo de sesión de creación de una base de datos:

    # kstash
    Master key: xxxxxxxx
    Verifying password - Master key: xxxxxxxx

    # kadmin -l
    kadmin> init EJEMPLO.ORG
    Realm max ticket life [unlimited]:
    kadmin> add tillman
    Max ticket life [unlimited]:
    Max renewable life [unlimited]:
    Attributes []:
    Password: xxxxxxxx
    Verifying password - Password: xxxxxxxx

Ahora puede arrancar los servicios KDC. Ejecute `/etc/rc.d/kerberos start` y `/etc/rc.d/kadmind start` para levantar dichos servicios. Recuerde que no tendrá ningún dæmon kerberizado ejecutándose pero debe poder confirmar que KDC funciona por el procedimiento de obtener y listar un boleto del principal (usuario) que acaba de crear en la línea de órdenes de KDC:

    % k5init tillman
    tillman@EJEMPLO.ORG's Password:

    % k5list
    Credentials cache: FILE:/tmp/krb5cc_500
    	Principal: tillman@EJEMPLO.ORG

      Issued           Expires          Principal
    Aug 27 15:37:58  Aug 28 01:37:58  krbtgt/EJEMPLO.ORG@EJEMPLO.ORG

## 14.8.3. Creación de un servidor Kerberos con servicios Heimdal

Antes de nada necesitaremos una copia del fichero de configuración de Kerberos, `/etc/krb5.conf`. Cópielo al cliente desde KDC de forma segura (mediante scp(1), o usando un disquete).

A continuación necesitará un fichero `/etc/krb5.keytab`. Esta es la mayor diferencia entre un servidor que proporciona dæmons habilitados con Kerberos y una estación de trabajo: el servidor debe tener un fichero `keytab`. Dicho fichero contiene las llaves de equipo del servidor, las cuales le permiten a él y al KDC verificar la identidad entre ellos. Deben transmitirse al servidor de forma segura ya que la seguridad del servidor puede verse comprometida si la llave se hace pública. Por decirlo más claro, transferirla como texto plano a través de la red (por ejemplo por FTP) es una pésima idea.

Lo normal es que transmita su `keytab` al servidor mediante el programa `kadmin`. Esto es práctico porque también debe crear el principal del equipo (el KDC que aparece al final de `krb5.keytab`) usando `kadmin`.

Tenga en cuenta que ya debe disponer de un ticket, y que este ticket debe poder usar el interfaz `kadmin` en `kadmind.acl`. Consulte la sección “administración remota” en la página info de Heimdal (`info heimdal`), donde se exponen los detalles de diseño de las listas de control de acceso. Si no quiere habilitar acceso remoto `kadmin`, puede conectarse de forma segura al KDC (por medio de consola local, ssh(1) o telnet(1) Kerberos) y administrar en local mediante `kadmin -l`.

Después de instalar el fichero `/etc/krb5.conf` puede usar `kadmin` desde el servidor Kerberos. `add --random-key` le permitirá añadir el principal del equipo servidor, y `ext` le permitirá extraer el principal del equipo servidor a su propio keybat. Por ejemplo:

    # kadmin
    kadmin> add --random-key host/myserver.ejemplo.org
    Max ticket life [unlimited]:
    Max renewable life [unlimited]:
    Attributes []:
    kadmin> ext host/miservidor.ejemplo.org
    kadmin> exit

Tenga en cuenta que `ext` (contracción de “extract”) almacena la llave extraída por defecto en en `/etc/krb5.keytab`.

Si no tiene `kadmind` ejecutándose en KDC (posiblemente por razones de seguridad) y por lo tanto carece de acceso remoto a `kadmin` puede añadir el principal de equipo (`host/miservidor.EJEMPLO.ORG`) directamente en el KDC y entonces extraerlo a un fichero temporal (para evitar sobreescribir `/etc/krb5.keytab` en el KDC) mediante algo parecido a esto:

    # kadmin
    kadmin> ext --keytab=/tmp/ejemplo.keytab host/miservidor.ejemplo.org
    kadmin> exit

Puede entonces copiar de forma segura el keytab al servidor (usando `scp` o un diquete). Asegúrese de usar un nombre de keytab diferente para evitar sobreescribir el keytab en el KDC.

Su servidor puede comunicarse con el KDC (gracias a su fichero `krb5.conf`) y puede probar su propia identidad (gracias al fichero `krb5.keytab`). Ahora está listo para que usted habilite algunos servicios Kerberos. En este ejemplo habilitaremos el servicio `telnet` poniendo una línea como esta en su `/etc/inetd.conf` y reiniciando el servicio inetd(8) con `/etc/rc.d/inetd restart`:

    telnet    stream  tcp     nowait  root    /usr/libexec/telnetd  telnetd -a user

La parte crítica es `-a`, de autentificación de usuario. Consulte la página de manual telnetd(8) para más información.

## 14.8.4. Kerberos con un cliente Heimdal

Configurar una computadora cliente es extremadamente fácil. Lo único que necesita es el fichero de configuración de Kerberos que encontrará en `/etc/krb5.conf`. Simplemente cópielo de forma segura a la computadora cliente desde el KDC.

Pruebe su computadora cliente mediante `kinit`, `klist`, y `kdestroy` desde el cliente para obtener, mostrar y luego borrar un ticket para el principal que creó antes. Debería poder usar aplicaciones Kerberos para conectarse a servidores habilitados con Kerberos, aunque si no funciona y tiene problemas al intentar obtener el boleto lo más probable es que el problema esté en el servidor y no en el cliente o el KDC.

Al probar una aplicación como `telnet`, trate de usar un “sniffer” de paquetes ( como tcpdump(1)) para confirmar que su contraseña no viaja en claro por la red. Trate de usar `telnet` con la opción `-x`, que cifra el flujo de datos por entero (algo parecido a lo que hace `ssh`).

Las aplicaciones clientes Kerberos principales (llamadas tradicionalmente `kinit`, `klist`, `kdestroy` y `kpasswd`) están incluidas en la instalación base de FreeBSD. Tenga en cuenta que en las versiones de FreeBSD anteriores a 5.0 reciben los nombres de `k5init`, `k5list`, `k5destroy`, `k5passwd` y `k5stash`.

También se instalan por defecto diversas aplicaciones Kerberos que no entran dentro de la categoría de “imprescindibles”. Es aquí donde la naturaleza “mínima” de la instalación base de Heimdal salta a la palestra: `telnet` es el único servicio Kerberos habilitado.

El port Heimdal añade algunas de las aplicaciones cliente que faltan: versiones Kerberos de `ftp`, `rsh`, `rcp`, `rlogin` y algunos otros programas menos comunes. El port del MIT también contiene una suite completa de aplicaciones cliente de Kerberos.

## 14.8.5. Ficheros de configuración de usuario: `.k5login` y `.k5users`

Suele ser habitual que los usuarios de un dominio Kerberos (o “principales”) tengan su usuario (por ejemplo `tillman@EJEMPLO.ORG`) mapeado a una cuenta de usuario local (por ejemplo un usuario llamado llamado `tillman`). Las aplicaciones cliente como `telnet` normalmente no requieren un nombre de usuario o un principal.

Es posible que de vez en cuando quiera dar acceso a una una cuenta de usuario local a alguien que no tiene un principal Kerberos. Por ejemplo, `tillman@EJEMPLO.ORG` puede necesitar acceso a la cuenta de usuario local `webdevelopers`. Otros principales tal vez necesiten acceso a esas cuentas locales.

Los ficheros `.k5login` y `.k5users`, ubicados en el directorio home del usuario, pueden usarse de un modo similar a una combinación potente de `.hosts` y `.rhosts`. Por ejemplo, si pusiera un fichero `.k5login` con el siguiente contenido

    tillman@example.org
    jdoe@example.org

en el directorio home del usuario local `webdevelopers` ambos principales listados tendrían acceso a esa cuenta sin requerir una contraseña compartida.

Le recomendamos encarecidamente la lectura de las páginas de manual de estas órdenes. Recuerde que la página de manual de `ksu` abarca `.k5users`.

## 14.8.6. Kerberos Sugerencias, trucos y solución de problemas

- Tanto si utiliza el port de Heimdal o el Kerberos del MIT asegúrese de que su variable de entorno `PATH` liste las versiones de Kerberos de las aplicaciones cliente antes que las versiones del sistema.

- ?Todas las computadoras de su dominio Kerberos tienen la hora sincronizada? Si no, la autentificación puede fallar. Sección 29.12 describe como sincronizar los relojes utilizando NTP.

- MIT y Heimdal conviven bien, con la excepción de `kadmin`, protocolo no está estandarizado.

- Si cambia su nombre de equipo debe cambiar también el “apellido” de su principal y actualizar su keytab. Esto también se aplica a entradas especiales en keytab como el principal `www/` que usa el `www/mod_auth_kerb` de Apache.

- Todos los equipos en su dominio Kerberos deben poder resolverse (tanto en la forma normal normal como en la inversa) en el DNS (o en `/etc/hosts` como mínimo). Los CNAME funcionarán, pero los registros A y PTR deben ser correctos y estar en su sitio. El mensaje de error que recibirá de no hacerlo así no es muy intuitivo: “`Kerberos5 refuses authentication because Read req failed: Key table entry not found`”.

- Algunos sistemas operativos que puede usar como clientes de su KDC no activan los permisos para `ksu` como setuid `root`. Esto hará que `ksu` no funcione, lo cual es muy seguro pero un tanto molesto. Tenga en cuenta que no se debe a un error de KDC.

- Si desea permitir que un principal tenga un ticket con una validez más larga que el valor por defecto de diez horas en Kerberos del MIT debe usar `modify_principal` en `kadmin` para cambiar “maxlife” tanto del principal en cuestión como del `krbtgt` del principal. Hecho esto, el principal puede utilizar la opción `-l` con `kinit` para solicitar un boleto con más tiempo de vida.

- > Nota: Si ejecuta un “sniffer” de paquetes en su KDC para ayudar con la resolución de problemas y ejecuta `kinit` desde una estación de trabajo puede encontrarse con que su TGT se envía inmediatamente después de ejecutar `kinit`: incluso antes de que escriba su contraseña La explicación es que el servidor Kerberos transmite tranquilamente un TGT (Ticket Granting Ticket) a cualquier petición no autorizada; de todas maneras, cada TGT está cifrado en una llave derivada de la contraseña del usuario. Por tanto, cuando un usuario teclea su contraseña no la está enviando al KDC, se está usando para descifrar el TGT que `kinit` ya obtuvo. Si el proceso de descifrado termina en un ticket válido con una marca de tiempo válida, el usuario tiene credenciales Kerberos válidas. Estas credenciales incluyen una llave de sesión para establecer comunicaciones seguras con el servidor Kerberos en el futuro, así como el TGT en sí, que se cifra con la llave del propio servidor Kerberos. Esta segunda capa de cifrado es invisible para el usuario, pero es lo que permite al servidor Kerberos verificar la autenticidad de cada TGT.

- Si desea utilizar tickets con un tiempo largo de vida (una semana, por ejemplo) y está utilizando OpenSSH para conectarse a la máquina donde se almacena su boleto asgúrese de que Kerberos `TicketCleanup` esté configurado a `no` en su `sshd_config` o de lo contrario sus tickets serán eliminados cuando termine la sesión.

- Recuerde que los principales de equipos también pueden tener tener un tiempo de vida más largo. Si su principal de usuario tiene un tiempo de vida de una semana pero el equipo al que se conecta tiene un tiempo de vida de nueve horas, tendrá un principal de equipo expirado en su caché, y la caché de ticket no funcionará como esperaba.

- Cuando esté configurando un fichero `krb5.dict` pensando específicamente en prevenir el uso de contraseñas defectuosas (la página de manual de de `kadmind` trata el tema brevemente), recuerde que solamente se aplica a principales que tienen una política de contraseñas asignada. El formato de los ficheros `krb5.dict` es simple: una cadena de texto por línea. Puede serle útil crear un enlace simbólico a `/usr/share/dict/words`.

## 14.8.7. Diferencias con el port del MIT

Las diferencias más grandes entre las instalaciones MIT y Heimdal están relacionadas con `kadmin`, que tiene un conjunto diferente (pero equivalente) de órdenes y utiliza un protocolo diferente. Esto tiene implicaciones muy grandes si su KDC es MIT, ya que no podrá utilizar el programa `kadmin` de Heimdal para administrar remotamente su KDC (o viceversa).

Las aplicaciones cliente pueden también disponer de diferentes opciones de línea de órdenes para lograr lo mismo. Le recomendamos seguir las instrucciones de la página web de Kerberos del MIT (http://web.mit.edu/Kerberos/www/). Sea cuidadoso con los parches: el port del MIT se instala por defecto en `/usr/local/`, y las aplicaciones “normales” del sistema pueden ser ejecutadas en lugar de las del MIT si su variable de entorno `PATH` lista antes los directorios del sistema.

> Nota: Si usa el port del MIT `security/krb5` proporcionado por FreeBSD asegúrese de leer el fichero `/usr/local/share/doc/krb5/README.FreeBSD` instalado por el port si quiere entender por qué los login vía `telnetd` y `klogind` se comportan de un modo un tanto extraño. Más importante aún, corregir la conducta de “permisos incorrectos en el fichero caché” requiere que el binario `login.krb5` se use para la validación para que pueda cambiar correctamente los permisos de propiedad de credenciales reenviadas.

## 14.8.8. Mitigación de limitaciones encontradas en Kerberos

### 14.8.8.1. Kerberos es un enfoque “todo o nada”

Cada servicio habilitado en la red debe modificarse para funcionar con Kerberos (o debe ser asegurado contra ataques de red) o de lo contrario las credenciales de usuario pueden robarse y reutilizarse. Un ejemplo de esto podría ser que Kerberos habilite todos los shells remotos ( vía `rsh` y `telnet`, por ejemplo) pero que no cubra el servidor de correo POP3, que envía contraseñas en texto plano.

### 14.8.8.2. Kerberos está pensado para estaciones de trabajo monousuario

En un entorno multiusuario Kerberos es menos seguro. Esto se debe a que almacena los tickets en el directorio `/tmp`, que puede ser leído por todos los usuarios. Si un usuario está compartiendo una computadora con varias personas (esto es, si utiliza un sistema multiusuario) es posible que los tickets sean robados (copiados) por otro usuario.

Esto puede solventarse con la opción de línea de órdenes `-c` nombre-de-fichero o (mejor aún) la variable de entorno `KRB5CCNAME`, pero raramente se hace. Si almacena los tickets en el directorio home de los usuarios y utiliza sin mucha complicación los permisos de fichero puede mitigar este problema.

### 14.8.8.3. El KDC es el punto crítico de fallo

Por motivos de diseño el KDC es tan seguro como la base de datos principal de contraseñas que contiene. El KDC no debe ejecutar ningún otro servicio ejecutándose en él y debe ser físicamente seguro. El peligro es grande debido a que Kerberos almacena todas las contraseñas cifradas con la misma llave (la llave “maestra”, que a su vez se guarda como un fichero en el KDC).

De todos modos una llave maestra comprometida no es algo tan terrible como parece a primera vista. La llave maestra solo se usa para cifrar la base de datos Kerberos y como semilla para el generador de números aleatorios. Mientras sea seguro el acceso a su KDC un atancante no puede hacer demasiado con la llave maestra.

Además, si el KDC no está disponible (quizás debido a un ataque de denegación de servicio o problemas de red) no se podrán utilizar los servicios de red ya que no se puede efectuar la validación, lo que hace que esta sea una buena forma de lanzar un ataque de denegación de servicio. Este problema puede aliviarse con múltiples KDCs (un maestro y uno o más esclavos) y con una implementación cautelosa de secundarios o autentificación de respaldo (para esto PAM es excelente).

### 14.8.8.4. Limitaciones de Kerberos

Kerberos le permite a usuarios, equipos y servicios validarse entre sí, pero no dispone de ningún mecanismo para autentificar el KDC a los usuarios, equipos o servicios. Esto significa que una versión (por ejemplo) “troyanizada” `kinit` puede grabar todos los usuarios y sus contraseñas. Puede usar `security/tripwire` o alguna otra herramienta de revisión de integridad de sistemas de ficheros para intentar evitar problemas como este.

## 14.8.9. Recursos y más información

- Las preguntas frecuentes (FAQ) de Kerberos

- Designing an Authentication System: a Dialog in Four Scenes

- RFC 1510, The Kerberos Network Authentication Service (V5)

- Página web de Kerberos del MIT

- Página web de Kerberos Heimdal

Anterior | Inicio | Siguiente
KerberosIV | Subir | OpenSSL

Puede descargar éste y muchos otros documentos desde ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

Si tiene dudas sobre FreeBSD consulte la documentación antes de escribir a la lista <questions@FreeBSD.org>.
Envíe sus preguntas sobre la documentación a <doc@FreeBSD.org>.