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