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