Changeset View
Changeset View
Standalone View
Standalone View
documentation/content/es/books/handbook/security/_index.adoc
Show First 20 Lines • Show All 1,228 Lines • ▼ Show 20 Lines | |||||
[NOTE] | [NOTE] | ||||
==== | ==== | ||||
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 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 [.filename]#sshd_config# o de lo contrario sus tickets serán eliminados cuando termine la sesión. | * 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 [.filename]#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. | * 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 [.filename]#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 [.filename]#krb5.dict# es simple: una cadena de texto por línea. Puede serle útil crear un enlace simbólico a [.filename]#/usr/shared/dict/words#. | * Cuando esté configurando un fichero [.filename]#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 [.filename]#krb5.dict# es simple: una cadena de texto por línea. Puede serle útil crear un enlace simbólico a [.filename]#/usr/share/dict/words#. | ||||
=== Diferencias con el port del MIT | === Diferencias con el port del MIT | ||||
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 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/[http://web.mit.edu/Kerberos/www/]). Sea cuidadoso con los parches: el port del MIT se instala por defecto en [.filename]#/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. | 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/[http://web.mit.edu/Kerberos/www/]). Sea cuidadoso con los parches: el port del MIT se instala por defecto en [.filename]#/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. | ||||
[NOTE] | [NOTE] | ||||
==== | ==== | ||||
Si usa el port del MITpackage:security/krb5[] proporcionado por FreeBSD asegúrese de leer el fichero [.filename]#/usr/local/shared/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. | Si usa el port del MITpackage:security/krb5[] proporcionado por FreeBSD asegúrese de leer el fichero [.filename]#/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. | ||||
==== | ==== | ||||
=== Mitigación de limitaciones encontradas en Kerberos | === Mitigación de limitaciones encontradas en Kerberos | ||||
==== Kerberos es un enfoque "todo o nada" | ==== Kerberos es un enfoque "todo o nada" | ||||
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. | 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. | ||||
▲ Show 20 Lines • Show All 1,152 Lines • Show Last 20 Lines |