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.
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"
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.
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
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, “NTP” 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.
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.
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>.