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

# 14.7. KerberosIV

Escrito por Mark Murray. Basado en un texto de Mark Dapoz.

Kerberos es un sistema/protocolo de red agregado que permite a los usuarios identificarse a través de los servicios de un servidor seguro. Los servicios como login remoto, copia remota, copias de ficheros de un sistema a otro y otras tantas tareas arriesgadas pasan a ser considerablemente seguras y más controlables.

Las siguientes instrucciones pueden usarse como una guía para configurar Kerberos tal y como se distribuye con FreeBSD. De todas maneras, debe consultar diversas páginas de manual para conocer todos los detalles.

## 14.7.1. Instalación de KerberosIV

Kerberos es un componente opcional de FreeBSD. La manera más fácil de instalar este software es seleccionando la distribución `krb4` o `krb5` en sysinstall durante la instalación inicial de FreeBSD. Desde ahí instalará la implementación de Kerberos eBones (KerberosIV) o Heimdal (Kerberos5). Estas implementaciones se incluyen porque a que han sido desarrolladas fuera de EEUU y Canadá, lo que las convertía en accesibles para administradores de sistemas del resto del mundo durante la época restrictiva de control control de exportaciones de código criptográfico desde EEUU.

También puede instalar la implementación de Kerberos del MIT desde la colección de ports (`security/krb5`).

## 14.7.2. Creación de la base de datos inicial

Esto solo debe hacerse en el servidor Kerberos. Lo primero es asegurarse de que no tiene bases de datos de Kerberos anteriores. Entre al directorio `/etc/kerberosIV` y asegúrese de que solo estén los siguientes ficheros:

    # cd /etc/kerberosIV
    # ls
    README		krb.conf        krb.realms

Si existe cualquier otro fichero (como `principal.*` o `master_key`) utilice `kdb_destroy` para destruir la base de datos antigua de Kerberos. Si Kerberos no está funcionando simplemente borre los ficheros sobrantes.

Edite `krb.conf` y `krb.realms` para definir su dominio Kerberos. En nuestro ejemplo el dominio será `EJEMPLO.COM` y el servidor es `grunt.ejemplo.com`. Editamos o creamos `krb.conf`:

    # cat krb.conf
    EJEMPLO.COM
    EJEMPLO.COM grunt.ejemplo.com admin server
    CS.BERKELEY.EDU okeeffe.berkeley.edu
    ATHENA.MIT.EDU kerberos.mit.edu
    ATHENA.MIT.EDU kerberos-1.mit.edu
    ATHENA.MIT.EDU kerberos-2.mit.edu
    ATHENA.MIT.EDU kerberos-3.mit.edu
    LCS.MIT.EDU kerberos.lcs.mit.edu
    TELECOM.MIT.EDU bitsy.mit.edu
    ARC.NASA.GOV trident.arc.nasa.gov

Los demás dominios no deben estar forzosamente en la configuración. Los hemos incluido como ejemplo de cómo puede hacerse que una máquina trabaje con múltiples dominios. Si quiere mantener todo simple puede abstenerse de incluirlos.

La primera línea es el dominio en el que el sistema funcionará. Las demás líneas contienen entradas dominio/equipo. El primer componente de cada línea es un dominio y el segundo es un equipo de ese dominio, que actúa como centro de distribución de llaves. Las palabras `admin server` que siguen al nombre de equipo significan que ese equipo también ofrece un servidor de base da datos administrativo. Si quiere consultar una explicación más completa de estos términos consulte las páginas de manual de de Kerberos.

Ahora añadiremos `grunt.ejemplo.com` al dominio `EJEMPLO.COM` y también una entrada para poner todos los equipos en el dominio `.ejemplo.com` Kerberos `EJEMPLO.COM`. Puede actualizar su `krb.realms` del siguiente modo:

    # cat krb.realms
    grunt.ejemplo.com EJEMPLO.COM
    .ejemplo.com EJEMPLO.COM
    .berkeley.edu CS.BERKELEY.EDU
    .MIT.EDU ATHENA.MIT.EDU
    .mit.edu ATHENA.MIT.EDU

Igual que en caso previo, no tiene por qué incluir los demás dominios. Se han incluido para mostrar cómo puede usar una máquina en múltiples dominios. Puede eliminarlos y simplificar la configuración.

La primera línea pone al sistema específico en el dominio nombrado. El resto de las líneas muestran cómo asignar por defecto sistemas de un subdominio a un dominio Kerberos.

Ya podemos crear la base de datos. Solo se ejecuta en el servidor Kerberos (o centro de distribución de llaves). Ejecute `kdb_init`:

    # kdb_init
    Realm name [default  ATHENA.MIT.EDU ]: EJEMPLO.COM
    You will be prompted for the database Master Password.
    It is important that you NOT FORGET this password.

    Enter Kerberos master key:

Ahora tendremos que guardar la llave para que los servidores en la máquina local puedan recogerla. Utilice `kstash`:

    # kstash

    Enter Kerberos master key:

    Current Kerberos master key version is 1.

    Master key entered. BEWARE!

Esto guarda la contraseña cifrada maestra en `/etc/kerberosIV/master_key`.

## 14.7.3. Puesta en marcha del sistema

Tendrá que añadir a la base de datos dos entradas en concreto para cada sistema que vaya a usar Kerberos: `kpasswd` y `rcmd`. Se hacen para cada sistema individualmente cada sistema, y el campo instance es el nombre individual del sistema.

Estos dæmons kpasswd y rcmd permiten a otros sistemas cambiar contraseñas de Kerberos y ejecutar órdenes como rcp(1), rlogin(1) y rsh(1).

Ahora vamos a añadir estas entradas:

    # kdb_edit
    Opening database...

    Enter Kerberos master key:

    Current Kerberos master key version is 1.

    Master key entered.  BEWARE!
    Previous or default values are in [brackets] ,
    enter return to leave the same, or new value.

    Principal name: passwd
    Instance: grunt

    <Not found>, Create [y] ? y

    Principal: passwd, Instance: grunt, kdc_key_ver: 1
    New Password:                    <---- tecleo aleatorio
    Verifying password

    New Password: <---- tecleo aleatorio

    Random password [y] ? y

    Principal's new key version = 1
    Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
    Max ticket lifetime (*5 minutes) [ 255 ] ?
    Attributes [ 0 ] ?
    Edit O.K.
    Principal name: rcmd
    Instance: grunt

    <Not found>, Create [y] ?

    Principal: rcmd, Instance: grunt, kdc_key_ver: 1
    New Password:		<---- tecleo aleatorio
    Verifying password

    New Password:           <---- tecleo aleatorio

    Random password [y] ?

    Principal's new key version = 1
    Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
    Max ticket lifetime (*5 minutes) [ 255 ] ?
    Attributes [ 0 ] ?
    Edit O.K.
    Principal name:         <---- si introduce datos nulos saldrá del programa

## 14.7.4. Creación del fichero del servidor

Ahora tendremos que extraer todas las instancias que definen los servicios en cada máquina; para ello usaremos `ext_srvtab`. Esto creará un fichero que debe ser copiado o movido por medios seguros al directorio `/etc/kerberosIV` de cada cliente Kerberos. Este fichero debe existir en todos los servidores y clientes dada su importancia clave para el funcionamiento de Kerberos.

    # ext_srvtab grunt
    Enter Kerberos master key:

    Current Kerberos master key version is 1.

    Master key entered. BEWARE!
    Generating 'grunt-new-srvtab'....

Esta orden solo genera un fichero temporal al que tendrá que cambiar el nombre a `srvtab` para que todos los servidores puedan recogerlo. Utilice mv(1) para moverlo al lugar correcto en el sistema original:

    # mv grunt-new-srvtab srvtab

Si el fichero es para un sistema cliente y la red no puede considerarse segura copie el ``cliente`-new-srvtab` en un medio extraíble y transpórtelo por medios físicos seguros. Asegúrese de cambiar su nombre a `srvtab` en el directorio `/etc/kerberosIV` del cliente, y asegúrese también de que tiene modo 600:

    # mv grumble-new-srvtab srvtab
    # chmod 600 srvtab

## 14.7.5. Añadir entradas a la base de datos

Ahora tenemos que añadir entradas de usuarios a la base de datos. Primero vamos a crear una entrada para el usuario `jane`. Para ello usaremos `kdb_edit`:

    # kdb_edit
    Opening database...

    Enter Kerberos master key:

    Current Kerberos master key version is 1.

    Master key entered.  BEWARE!
    Previous or default values are in [brackets] ,
    enter return to leave the same, or new value.

    Principal name: jane
    Instance:

    <Not found>, Create [y] ? y

    Principal: jane, Instance: , kdc_key_ver: 1
    New Password:                <---- introduzca una constraseña segura
    Verifying password

    New Password:                <---- introduzca de nuevo la contraseña
    Principal's new key version = 1
    Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
    Max ticket lifetime (*5 minutes) [ 255 ] ?
    Attributes [ 0 ] ?
    Edit O.K.
    Principal name:		   <---- si introduce datos nulos saldrá del programa

## 14.7.6. Prueba del sistema

Primero tenemos que iniciar los dæmons de Kerberos. Tenga en cuenta que si su `/etc/rc.conf` está configurado correctamente el inicio tendrá ligar cuando reinicie el sistema. Esta prueba solo es necesaria en el servidor Kerberos; los clientes Kerberos tomarán lo que necesiten automáticamente desde el directorio `/etc/kerberosIV`.

    # kerberos &
    Kerberos server starting
    Sleep forever on error
    Log file is /var/log/kerberos.log
    Current Kerberos master key version is 1.

    Master key entered. BEWARE!

    Current Kerberos master key version is 1
    Local realm: EJEMPLO.COM
    # kadmind -n &
    KADM Server KADM0.0A initializing
    Please do not use 'kill -9' to kill this job, use a
    regular kill instead

    Current Kerberos master key version is 1.

    Master key entered.  BEWARE!

Ahora podemos probar a usar `kinit` para obtener un ticket para el ID `jane` que creamos antes:

    % kinit jane
    MIT Project Athena (grunt.ejemplo.com)
    Kerberos Initialization for "jane"
    Password:

Pruebe a listar los tokens con `klist` para ver si realmente están:

    % klist
    Ticket file:    /tmp/tkt245
    Principal:      jane@EJEMPLO.COM

      Issued           Expires          Principal
    Apr 30 11:23:22  Apr 30 19:23:22  krbtgt.EJEMPLO.COM@EJEMPLO.COM

Ahora trate de cambiar la contraseña usando passwd(1) para comprobar si el dæmon kpasswd está autorizado a acceder a la base de datos Kerberos:

    % passwd
    realm EJEMPLO.COM
    Old password for jane:
    New Password for jane:
    Verifying password
    New Password for jane:
    Password changed.

## 14.7.7. Añadir privilegios de `su`

Kerberos nos permite dar a cada usuario que necesite privilegios de `root` su propia contraseña para su(1). Podemos agregar un ID que esté autorizado a ejecutar su(1) `root`. Esto se controla con una instancia de `root` asociada con un usuario. Vamos a crear una entrada `jane.root` en la base de datos, para lo que recurrimos a `kdb_edit`:

    # kdb_edit
    Opening database...

    Enter Kerberos master key:

    Current Kerberos master key version is 1.

    Master key entered.  BEWARE!
    Previous or default values are in [brackets] ,
    enter return to leave the same, or new value.

    Principal name: jane
    Instance: root

    <Not found>, Create [y] ? y

    Principal: jane, Instance: root, kdc_key_ver: 1
    New Password:                    <---- introduzca una contraseña SEGURA
    Verifying password

    New Password:    	 	 <---- introduzca otra vez la constraseña

    Principal's new key version = 1
    Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
    Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- Keep this short!
    Attributes [ 0 ] ?
    Edit O.K.
    Principal name:		         <---- si introduce datos nulos saldrá del programa

Ahora trate de obtener los tokens para comprobar que todo funciona:

    # kinit jane.root
    MIT Project Athena (grunt.ejemplo.com)
    Kerberos Initialization for "jane.root"
    Password:

Hemos de agregar al usuario al `.klogin` de `root`:

    # cat /root/.klogin
    jane.root@EJEMPLO.COM

Ahora trate de hacer su(1):

    % su
    Password:

y eche un vistazo a qué tokens tenemos:

    # klist
    Ticket file:	/tmp/tkt_root_245
    Principal:      jane.root@EJEMPLO.COM

      Issued           Expires          Principal
    May  2 20:43:12  May  3 04:43:12  krbtgt.EJEMPLO.COM@EJEMPLO.COM

## 14.7.8. Uso de otras órdenes

En un ejemplo anterior creamos un usuario llamado `jane` con una instancia `root`. Nos basamos en un usuario con el mismo nombre del principal (`jane`), el procedimiento por defecto en Kerberos: `<principal>.<instancia>` con la estructura `<nombre de usuario>.``root` permitirá que `<nombre de usuario>` haga su(1) a `root` si existen las entradas necesarias en el `.klogin` que hay en el directorio home de `root`:

    # cat /root/.klogin
    jane.root@EJEMPLO.COM

De la misma manera, si un usuario tiene en su directorio home lo siguiente:

    % cat ~/.klogin
    jane@EJEMPLO.COM
    jack@EJEMPLO.COM

significa que cualquier usuario del dominio `EJEMPLO.COM` que se identifique como `jane` o como `jack` (vía `kinit`, ver más arriba) podrá acceder a la cuenta de `jane` o a los ficheros de este sistema (`grunt`) vía rlogin(1), rsh(1) o rcp(1).

Veamos por ejemplo cómo `jane` se se identifica en otro sistema mediante Kerberos:

    % kinit
    MIT Project Athena (grunt.ejemplo.com)
    Password:
    % rlogin grunt
    Last login: Mon May  1 21:14:47 from grumble
    Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
            The Regents of the University of California.   All rights reserved.

    FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995

Aquí `jack` se identifica con la cuenta de `jane` en la misma máquina (`jane` tiene configurado su fichero `.klogin` como se ha mostrado antes, y la persona encargada de la administración de Kerberos ha configurado un usuario principal jack con una instancia nula):

    % kinit
    % rlogin grunt -l jane
    MIT Project Athena (grunt.ejemplo.com)
    Password:
    Last login: Mon May  1 21:16:55 from grumble
    Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
            The Regents of the University of California.   All rights reserved.
    FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995

Anterior | Inicio | Siguiente
TCP Wrappers | Subir | Kerberos5

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>.