Kerberos

Kerberos 

La seguridad e integridad de sistemas dentro de una red puede ser complicada. Puede ocupar el tiempo de varios administradores de sistemas sólo para mantener la pista de cuáles servicios se estan ejecutando en una red y la manera en que estos servicios son usados. Más aún, la autenticación de los usuarios a los servicios de red puede mostrarse peligrosa cuando el método utilizado por el protocolo es inherentemente inseguro, como se evidencia por la transferencia de contraseñas sin encriptar sobre la red bajo los protocolos FTP y Telnet. Kerberos es una forma eliminar la necesidad deaquellos protocolos que permiten métodos de autenticación inseguros, y de esta forma mejorar la seguridad general de la red.

¿Qué es Kerberos? 

Kerberos es un protocolo de seguridad creado por MIT que usa una criptografía de claves simétricas para validar usuarios con los servicios de red — evitando así tener que enviar contraseñas a través de la red. Al validar los usuarios para los servicios de la red por medio de Kerberos, se frustran los intentos de usuarios no autorizados.

Ventajas de Kerberos

Los servicios de redes más convencionales usan esquemas de autenticación basados en contraseñas. Tales esquemas requieren que cuando un usuario necesita una autenticación en un servidor de red, debe proporcionar un nombre de usuario y una contraseña. Lamentablemente, la información de autenticación para muchos servicios se transmite sin estar encriptada. Para que un esquema de este tipo sea seguro, la red tiene que estar inaccequible a usuarios externos, y todos los usuarios de la red deben ser de confianza.

Aún en este caso, una vez que la red se conecte a la Internet, ya no puede asumir que la red es segura. Cualquier intruso del sistema con acceso a la red y un analizador de paquetes puede interceptar cualquier contraseña enviada de este modo, comprometiendo las cuentas de usuarios y la integridad de toda la infraestructura de seguridad.

El primer objetivo de Kerberos es el de eliminar la transmisión a través de la red de información de autenticación. Un uso correcto de Kerberos erradica la amenaza de analizadores de paquetes que intercepten contraseñas en su red.

Desventajas de Kerberos

A pesar de que Kerberos elimina una amenaza de seguridad común, puede ser difícil de implementar por una variedad de razones:

  • La migración de contraseñas de usuarios desde una base de datos de contraseñasestándar UNIX, tal como /etc/passwd o /etc/shadow, a una base de datos de contraseñas Kerberos puede ser tediosa y no hay un mecanismo rápido para realizar esta tarea.
  • Kerberos es sólo parcialmente compatible con los Pluggable Authentication Modules (PAM) usados por la mayoría de los servidores Red Hat Enterprise Linux.
  • Kerberos presupone que cada usuario es de confianza pero que está utilizando una máquina no fiable en una red no fiable. Su principal objetivo es el de prevenir que las contraseñas no encriptadas sean enviadas a través de la red. Sin embargo, si cualquier otro usuario aparte del usuario adecuado, tiene acceso a la máquina que emite tickets usados para la autenticación — llamado Centro de distribución de llaves (KDC) —, el sistema de autenticación de Kerberos completo está en riesgo.
  • Para que una aplicación use Kerberos, el código debe ser modificado para hacer las llamadas apropiadas a las librerías de Kerberos. Las aplicaciones que son modificadas de esta forma son consideradas kerberizadas. Para algunas aplicaciones, esto puede suponer un esfuerzo excesivo de programación, debido al tamaño de la aplicación o su diseño. Para otras aplicaciones incompatibles, los cambios se deben realizar en el modo en que el servidor de red y sus clientes se comunican; de nuevo, esto puede suponer bastante programación. En general, las aplicaciones de código cerrado que no tienen soporte de Kerberos son usualmente las más problemáticas.
  • Finalmente, si decide usar Kerberos en su red, debe darse cuenta de que es una elección de todo o nada. Si decide usar Kerberos en su red, debe recordar que si se transmite cualquier contraseña a un servicio que no usa Kerberos para autenticar, se corre el riesgo de que el paquete pueda ser interceptado. Así, su red no obtendrá ningún beneficio de usar Kerberos. Para asegurar su red con Kerberos, solo debe utilizar las versiones kerberizadas (que funcionen con Kerberos) de todas las aplicaciones cliente/servidor que envien contraseñas sin encriptar o no utilizar ninguna de estas aplicaciones en la red.

 

Terminología Kerberos

Como algunos otros sistemas, Kerberos tiene su propia terminología para definir varios aspectos del servicio. Antes de aprender como funciona kerberos, es importante aprender estos términos.

servidor de autenticación (AS)

Un servidor que emite tickets para un servicio deseado los cuales a su vez son entregados a los usuarios para que accesen al servicio. El AS responde a las peticiones de los clientes quienes no tienen o no envian credenciales con la petición. Usualmente es utilizado para ganar acceso al servidor de otorgamiento de tickets (Ticket-granting Server, TGS) emitiendo un ticket de acceso (TGT). El AS usualmente se ejecuta en la misma máquina que el KDC.

texto cifrado

Datos encriptados.

cliente

Una entidad en la red (un usuario, un host o una aplicación) que pueden obtener un ticket de Kerberos.

credenciales

Un grupo temporal de credenciales electrónicas que verifica la identidad de un cliente para un servicio particular. También se conoce como ticket.

caché credencial o archivo de tickets

Un archivo que contiene las llaves para encriptar las comunicaciones entre el usuario y varios servicios de red. Kerberos 5 proporciona un framework para usar otros tipos de caché, tales como memoria compartida, pero los archivos están mejor soportados.

hash encriptado

Un hash de un sentido usado para autentificar usuarios. Aunque es más seguro que los datos sin encriptar, es bastante fácil de descifrar por un cracker con experiencia.

GSS-API

La Interfaz del Programa de la Aplicación de Servicio de seguridad Genérico (Generic Security Service Application Program Interface, definido en la RFC-2743 publicada por la Fuerza de Tareas de Ingeniería de Internet) es un conjunto de funciones que proveen servicios de seguridad. Esta API es usada por clientes y servicios para autenticarse entre ellos sin que ninguno de los programas tenga un conocimiento específico del mecanismo detrás de ello. Si un servicio de red (tal como cyrus-IMAP) usa GSS-API, puede autenticar usando Kerberos.

hash

Un número de texto generado y que es usado para asegurar que los datos transmitidos no han sido dañados.

llave

Datos usados cuando encriptamos o desencriptamos otros datos. Los datos encriptados no pueden ser desencriptados sin la llave apropiada o con una extraordinaria capacidad para adivinar.

centro de distribución de llaves (KDC)

Un servicio que emite tickets Kerberos, que habitualmente se ejecuta en el mismo host que el servidor de otorgamiento de tickets (TGS).

keytab (o tabla de llaves)

Un fichero que incluye una lista desencriptada de “principals” y sus claves. Los servidores recuperan las claves que necesitan desde los archivos keytab en lugar de usarkinit. El archivo keytab por defecto es /etc/krb5.keytab. El servidor de administración KDC, /usr/kerberos/sbin/kadmind, es el único servicio que usa otro archivo (usa /var/kerberos/krb5kdc/kadm5.keytab).

kinit

El comando kinit permite a un principal quien que ya se ha conectado, obtener y hacer caché del primer ticket de acceso (TGT).

principal (o nombre del principal)

El principal es el nombre único de un usuario o servicio que puede autenticar mediante el uso de Kerberos. Un nombre de principal está en el formatoroot[/instance]@REALM. Para un usuario típico, el root es el mismo que su ID de inicio de sesión. La instance es opcional. Si el principal tiene una instancia, estará separada de root con una barra hacia adelante (“/”). Una cadena de caracteres vacía (“”) es considerada como una instancia válida (que se diferencia del valor de la instancia por defecto NULL), pero usarlo puede ser confuso. Todos los principales de un reino tienen su propia llave, la cual para los usuarios se deriva de su contraseña o se genera aleatoriamente para servicios.

reino

Red que usa Kerberos, compuesto de uno o varios servidores (también conocidos como KDCs) y un número potencial de clientes.

servicio

Un programa accesado a través de la red.

ticket

Grupo temporal de credenciales electrónicas que verifican la identidad de un cliente para un servicio particular. También llamado credenciales.

servidor de otorgamiento de tickets (TGS)

Un servidor que emite tickets para un servicio deseado; estos tickets son entregados a los usuarios para que accesen el servicio. El TGS usualmente se ejecuta en el mismo servidor que KDC.

ticket de acceso (TGT)

Ticket especial que permite al cliente obtener tickets adicionales sin solicitarlos desde KDC.

contraseña no encriptada

Una contraseña en texto plano que se puede leer fácilmente.

Modo en que funciona Kerberos

Kerberos es diferente de los métodos de autenticación de nombre de usuario/contraseña. En vez de validar cada usuario para cada servicio de red, Kerberos usa encriptación simétrica y un tercero, un KDC, para autentificar los usuarios a un conjunto de servicios de red. Una vez que el usuario se ha autentificado al KDC, se le envía un ticket específico para esa sesión de vuelta a la máquina del usuario y cualquier servicio kerberizado buscará por el ticket en la máquina del usuario en vez de preguntarle al usuario que se autentifique usando una contraseña.

Cuando un usuario en una red kerberizada se registra en su estación de trabajo, su principal se envía al KDC en una petición para un TGT desde el servidor de autenticación (AS). Esta petición puede ser enviada por el programa de conexión para que sea transparente al usuario o puede ser enviada por el programa kinit después de que el usuario se registre.

El KDC verifica el principal en su base de datos. Si lo encuentra, el KDC crea un TGT,el cual es encriptado usando las llaves del usuario y devuelto al usuario.

El programa login en la máquina del cliente o kinit descifra el TGT usando la contraseña del usuario La contraseña del usuario es usada únicamente en la máquina del cliente y no es enviada sobre la red.

El TGT, se configura para que caduque después de un cierto período de tiempo (usualmente 10 horas) y es almacenado en la caché de credenciales de la máquina del cliente. Se coloca un tiempo de caducidad de manera que un TGT comprometido sólo es de utilidad para un intruso por un período corto de tiempo. Una vez que el TGT es emitido, el usuario no tiene que reingresar la contraseña al KDC sino hasta que el TGT caduque o se desconecte y vuelva a conectarse.

Cuando el usuario necesita acceder a un servicio de red, el software cliente usa el TGT para pedir un nuevo ticket para ese servicio en específico al servidor de otorgamiento de tickets, TGS. El ticket para el servicio es usado para autentificar el usuario a ese servicio de forma transparente.

Aviso
El sistema Kerberos se vuelve vulnerable cada vez que un usuario en la red se valida contra un servicio no kerberizado y envía una contraseña en la red en texto plano. Por lo tanto no se recomienda el uso de servicios no kerberizados. Estos servicios incluyen Telnet y FTP. Se acepta el uso de otro tipo de protocolos encriptados, tales como SSH o servicios seguros SSL, pero no es ideal.El sistema Kerberos se vuelve vulnerable cada vez que un usuario en la red se valida contra un servicio no kerberizado y envía una contraseña en la red en texto plano. Por lo tanto no se recomienda el uso de servicios no kerberizados. Estos servicios incluyen Telnet y FTP. Se acepta el uso de otro tipo de protocolos encriptados, tales como SSH o servicios seguros SSL, pero no es ideal.

Esto es sólo una descripción general de cómo funciona la autenticación Kerberos.

  Nota
  Kerberos depende de ciertos servicios de la red para trabajar correctamente. Primero, Kerberos necesita una sincronización de reloj entre los ordenadores de la red. Por lo tanto, se debería cofigurar un programa de sincronización de reloj para la red, como por ejemplo ntpd. Para más información sobre la configuración de ntpd, vea /usr/share/doc/ntp-<version-number>/index.htm para detalles sobre cómo configurar un servidor de protocolos de hora de red (reemplace <version-number> con el número de versión del paquete ntp instalado en su sistema).Ya que ciertos aspectos de kerberos se apoyan en el Servicio de nombres de dominio (Domain Name System, DNS), debe asegurarse de que las entradas DNS y los hosts en su red están configuradas correctamente. Vea el Manual del administrador de Kerberos V5 , proporcionado en PostScript y formatos HTML en /usr/share/doc/krb5-server-<version-number> para más información (reemplace <version-number> con el número de la versión del paquete krb5-server instalado en su sistema).

 

Kerberos y PAM

Actualmente, los servicios Kerberizados no hacen uso de PAM (Pluggable Authentication Modules) — un servidor kerberizado omite PAM completamente. Sin embargo, las aplicaciones que usan PAM pueden hacer uso de Kerberos para autentificación si el módulo pam_krb5 (proporcionado en el paquete pam_krb5) está instalado. El paquetepam_krb5 contiene archivos de configuración de ejemplo que permiten servicios como login y gdm autentificar usuarios así como obtener credenciales iniciales usando sus contraseñas. Si el acceso a los servidores de red siempre se realiza mediante servicios kerberizados (o servicios que usan GSS-API, como IMAP), la red puede ser considerada razonablemente segura.

  Sugerencia
  Los administradores deberían tener cuidado de no permitir a los usuarios autentificarse a servicios de red usando claves Kerberos. La mayoría de los protocolos no encriptan las contraseñas antes de enviarlas sobre la red, destruyendo así los beneficios del sistema Kerberos. Por ejemplo, a los usuarios no se les debería permitir autenticarse usando contraseñas Kerberos sobre Telnet.

Configurar un servidor Kerberos 5

Cuando esté configurando Kerberos, debe instalar el servidor primero. Si necesita instalar servidores esclavos, los detalles para configurar las relaciones entre servidores maestro y esclavo se cubren en Manual de instalación de Kerberos 5 localizado en el directorio /usr/share/doc/krb5-server-<version-number> (reemplace<version-number> con el número de versión del paquete krb5-server instalado en su sistema).

Para configurar un servidor Kerberos básico, siga estos pasos:

  1. Asegúrese de que tanto el reloj como el DNS funcionan correctamente en todas las máquinas servidores y clientes antes de configurar el Kerberos 5. Preste especial atención a la sincronización de la hora entre el servidor Kerberos y de sus clientes. Si la sincronización de los relojes del servidor y de los clientes se diferencia en más de cinco minutos ( la cantidad predeterminada es configurable en el Kerberos 5), los clientes de Kerberos no podrán autentificarse al servidor. La sincronización de los relojes es necesaria para evitar que un intruso use un ticket viejo de Kerberos para hacerse pasar como un usuario autorizado.

Se recomienda configurar una red cliente/servidor compatible con Network Time Protocol (NTP) aún si no está usando Kerberos. Red Hat Enterprise Linux incluye el paquete ntp para este propósito. Vea /usr/share/doc/ntp-<version-number>/index.htm para detalles sobre cómo configurar servidores Network Time Protocol y http://www.eecis.udel.edu/~ntp para información adicional sobre NTP.

  1. Instale los paquetes krb5-libskrb5-server, y krb5-workstation en una máquina dedicada que ejecutará el KDC. Esta máquina tiene que ser muy segura — si es posible, no debería ejecutar ningún otro servicio excepto KDC.

Si desea usar una utilidad de interfaz gráfica para administrar Kerberos, instale el paquete gnome-kerberos. Este contiene krb5, que es una herramienta tipo GUI para manejar tickets.

  1. Modifique los archivos de configuración /etc/krb5.conf y /var/kerberos/krb5kdc/kdc.conf para que reflejen el nombre de su reino y las correspondencias (mappings) de dominio a reino. Se puede construir un reino simple sustituyendo las instancias de EXAMPLE.COM y example.com con el nombre correcto del dominio — siempre y cuando se respete el formato correcto de los nombres escritos en mayúscula y en minúscula — y se cambie el KDC del kerberos.example.com con el nombre de su servidor Kerberos. En general, los nombres de reinos se escriben en mayúscula y todos los nombre DNS de host y nombres de dominio se escriben en minúscula. Para más detalles sobre los formatos de estos archivos, vea sus respectivas páginas man.
  2. Cree la base de datos usando la utilidad kdb5_util desde el intérprete de comandos del shell:
  3. El comando create crea la base de datos que será usada para almacenar las llaves para el reino Kerberos. La opción -s fuerza la creación de un archivo stash en el cual la llave maestra del servidor es guardada. Si no se presenta un archivo stash desde donde leer la llave, el servidor Kerberos (krb5kdc) le pedirá al usuario que ingrese la contraseña maestra del servidor (la cual puede ser usada para regenerar la llave) cada vez que arranca.
  4. Modifique el archivo /var/kerberos/krb5kdc/kadm5.acl. Este archivo es usado por kadmind para determinar cuales principales tienen acceso administrativo a la base de datos Kerberos y sus niveles de acceso. La mayoría de las organizaciones pueden resolverse con una sola línea:
  5. La mayoría de los usuarios serán presentados en la base de datos por un principal simple (con una instancia NULL, o vacía, tal como joe@EXAMPLE.COM). Con esta configuración, los usuarios con un segundo principal con una instancia de admin (por ejemplo, joe/admin@EXAMPLE.COM) podrán tener todo el acceso sobre la base de datos del reino Kerberos.
  6. Una vez que se arranca kadmind en el servidor, cualquier usuario puede accesar a sus servicios ejecutando kadmin en cualquiera de los clientes o servidores en el reino. Sin embargo, solamente los usuarios que aparecen en la lista del archivo kadm5.acl podrán modificar la base de datos, excepto por sus propias contraseñas.
/usr/kerberos/sbin/kdb5_util create -s
*/admin@EXAMPLE.COM  *
  Nota
  La utilidad kadmin se comunica con el servidor kadmind por la red y usa Kerberos para llevar a cabo la autentificación. Por esta razón, el primer principal ya debe existir antes de conectarse al servidor sobre la red para poder administrarla. Puede crear esta primera entrada con el comandokadmin.local, el cual se ha creado específicamente para usarlo en la misma máquina que el KDC y no usa Kerberos para la autenticación.
  1. Escriba el comando kadmin.local en una terminal KDC para crear la primera entrada como usuario principal:
/usr/kerberos/sbin/kadmin.local -q "addprinc username/admin"

10. Arranque Kerberos usando los siguientes comandos:

/sbin/service krb5kdc start
/sbin/service kadmin start
/sbin/service krb524 start

11. Agregue principals para sus usuarios con el comando addprinc y kadminkadmin y kadmin.local son interfaces de línea de comandos para el KDC. Como tales, muchos comandos están disponibles después de lanzar el programa kadmin. Vea la página del manual kadmin para más información.

12. Verifique que el servidor KDC esté creando tickets. Primero, ejecute kinit para obtener un ticket y guardarlo en un archivo de credenciales caché. Luego, use klistpara ver la lista de credenciales en su caché y use kdestroy para eliminar el caché y los credenciales que contenga.

  Nota
  Por defecto, kinit intenta autenticar el usuario usando el nombre de conexión (login) de la cuenta que usó cuando se conectó al sistema (no al servidor Kerberos). Si ese nombre de usuario no se corresponde a un principal en la base de datos Kerberos, kinitemite un mensaje de error. Si estó ocurre, indique a kinit el nombre de su principal correcto como un argumento en la línea de comandos (kinit <principal>).

Una vez que haya completado los pasos listados, el servidor Kerberos funcionará correctamente.

Configuración de un cliente Kerberos 5

La configuración de un cliente de Kerberos 5 no es tan complicada como la de un servidor. Lo que tiene que hacer es instalar los paquetes del cliente y proveer a cada cliente con un archivo de configuración krb5.conf válido. Las versiones kerberizadas de rsh y rlogin también requerirán algunos cambios en la configuración.

  1. Asegúrese que la sincronización sea correcta entre el cliente de Kerberos y el KDC. Además, verifique que el DNS esté funcionando correctamente en el cliente Kerberos antes de configurar los programas cliente de Kerberos.
  2. Instale los paquetes krb5-libs y krb5-workstation en todas las máquinas de clientes. Tiene que dar un archivo válido de /etc/krb5.conf para cada cliente; normalmente es el mismo archivo krb5.conf usado por el KDC.
  3. Antes de que una estación de trabajo del reino permita a los usuarios conectarse usando los comandos kerberizados rsh y rlogin, esa estación de trabajo tendrá que tener instalado el paquete xinetd y tener su propio host principal en la base de datos Kerberos. Los programas de servidor kshd y klogind también necesitan el acceso a las llaves para sus principal de servicios.

Usando el comando kadmin, añada un host principal para la estación de trabajo en el KDC. La instancia en este caso será el nombre de laestación de trabajo. Puede usar la opción -randkey para el comando kadmin addprinc para crear el principal y asignarle una llave aleatoria:

addprinc -randkey host/blah.example.com

Ahora que se ha creado el principal, puede extraer las claves para la estación de trabajo ejecutando kadmin en la estación de trabajo, y usando el comando ktadd enkadmin:

ktadd -k /etc/krb5.keytab host/blah.example.com
  1. Si desea utilizar otros servicios kerberizados de red, necesitará arrancarlos. Abajo hay una lista de algunos de los servicios kerberizados más comunes y las instrucciones para activarlos:
  • rsh y rlogin — Para usar las versiones kerberizadas de los comandos rsh y rlogin, deberá activar klogineklogin, y kshell.
  • Telnet — Para usar Telnet kerberizado, deberá activar krb5-telnet.
  • FTP — Para el acceso FTP, cree y extraiga una entrada para el principal con una raíz de ftp. Asegúrese de colocar la instancia al nombre de host del servidor FTP, luego active gssftp.
  • IMAP — Para utilizar un servidor IMAP kerberizado, el paquete cyrus-imap utiliza Kerberos 5 si también tiene el paquete cyrus-sasl-gssapi instalado. El paquete cyrus-sasl-gssapi contiene las extensiones Cyrus SASL las cuales soportan la autenticación GSS-API. Cyrus IMAP debería de funcionar adecuadamente con Kerberos siempre y cuando el usuario cyrus sea capaz de encontrar la llave correcta en /etc/krb5.keytab, y el root para el principal esté configurado a imap (creado con kadmin).

El paquete dovecot también tiene una alternativa de servidor IMAP para cyrus-imap, que también está incluida con Red Hat Enterprise Linux, pero que no es compatible con GSS-API ni Kerberos hasta ahora.

  • CVS — Para utilizar un servidor CVS kerberizado gserver utilice un principal con una raíz de cvs y es idéntica al CVS pserver.

Para detalles sobre como activar servicios, refiérase al capítulo titulado Control de acceso a los servicios en el Manual de administración del sistema de Red Hat Enterprise Linux.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s