2.1 Particionar el disco duro para compartimentar datos
El propósito de esta sección es discutir las cuestiones de seguridad presentes antes y durante el proceso de instalación inicial del sistema operativo Solaris 10. una cuidadosa revisión de estas cuestiones es recomendable con el fin de no tener que reinstalar el sistema operativo.
Teniendo en cuenta el uso que se le va a dar al servidor, se deben crear las particiones durante el proceso de instalación. El número de particiones configurables está limitado a siete en plataformas SPARC y nueve en plataformas Intel. Sin embargo, Solaris permite tener particiones soft que pueden ser usadas para subdividir discos en 8192 volúmenes lógicos. Las divisiones que son utilizadas para particiones soft no pueden ser usadas para otros propósitos.
Las siguientes particiones son comúnmente usadas y deben ser creadas en el sistema por separado.
/
La raíz de todo el sistema de archivos, contiene archivos y directorios principales que componen el sistema operativo; una vez instalado, muy poco se agrega a este directorio.
swap
Como mínimo, debe ser de 512 MB; una buena regla es establecer la swap de acuerdo a la memoria física del sistema, en cuyo caso un valor de 1.5 veces de la memoria RAM es apropiada para aplicaciones estándar. La partición swap se monta típicamente como /tmp.
/usr
El directorio que contiene documentación, programas del sistema, scripts y librerías que serán usadas por todos los usuarios del sistema.
Los siguientes directorios pueden ser creados en particiones duras o suaves.
/var
Este directorio contiene una serie de archivos, los cuales usualmente incluyen archivos temporales, bitácoras y archivos de estado. En la versión de Solaris 10 es más usado y muy pesado a diferencia de versiones anteriores. Es muy importante que este directorio tenga suficiente espacio y que sea montado en una partición aparte, para evitar fallas por la saturación de logs que consuman el espacio en disco.
/opt
Directorio destinado para software de terceros adicional al sistema; el software que más frecuentemente se añade a este directorio son las nuevas aplicaciones y herramientas, así que es necesario que esta partición tenga espacio suficiente para alojar el nuevo software.
/usr/local
Directorio utilizado para software local del sistema, por ejemplo software de código abierto como Perl, herramientas de GNU, etc.
Las siguientes particiones tienen nombres sugeridos que pueden ser modificados si se desea. Estos directorios pueden o no ser necesarios, dependiendo de los servicios de la máquina.
/var/spool/mqueue
Para colas locales de correos antes de ser envidos; recordar evitar usar el mismo nombre de este directorio como el directorio usado por el servidor de correo.
/export/home
Es el directorio por defecto para los sistemas de archivos compartidos para todo el sistema, como todos los directorios home de los usuarios, aplicaciones, etc. Cada usuario debe tener espacio adecuado para el trabajo que realicen; se debe estimar el número de usuarios y planear acorde a ello.
/anonftp/incoming
Si está permitido subir con ftp anónimo, se necesita entonces crear una partición propia para este directorio. Una vez creadas e instaladas las particiones, establecer los permisos recomendados.
Las particiones ayudan a la seguridad en un sinnúmero de formas, entre ellas la protección contra denegación de servicio, fallo del sistema por llenar el espacio en disco por los usuarios en sus directorios home o por llenar las bitácoras; haciendo más fácil la administración del espacio y rutinas de respaldo, la protección contra las debilidades de NFS y facilitar la protección de datos y prevenir la modificación desautorizada de datos separándolos en su propia partición. El administrador debe tener un plan para el tamaño que cada partición deba tener.
Esto requiere que se tenga conocimiento de cuál grupo de software es necesario, el uso destinado para el sistema y quiénes van a usarlo. Las particiones suaves pueden ser incrementadas después de su creación si se requiere de más espacio, siempre que haya espacio libre en el dispositivo subyacente. Una vez agrandadas, no pueden ser reducidas.
1.2 Aplicar parches al sistema operativo
Actualizar el sistema operativo mediante la aplicación de parches de software es el primer paso para garantizar la seguridad y la fiabilidad del sistema. Los proveedores desarrollan actualizaciones del sistema operativo cuando son advertidos de vulnerabilidades de seguridad y otras cuestiones de funcionalidad, pero es a los clientes a quienes les corresponde descargar e instalar estos parches. La estrategia recomendada de parcheo de Sun está documentada en el documento "Solaris Patch Management: Recommended Strategy" disponible en http://www.sun.com/blueprints/browsesubject.html#dcp.
1.2.1 Aplicar los parches más recientes al sistema operativo
Crear un directorio para extraer los parches. Este directorio debe ser propiedad de root y en modo 755, puede ser el directorio /var/tmp/patches. Obtener el clúster de parches de Sun del sitio http://sunsolve.sun.com/pub-cgi/show.pl?target=patchpage y localizar archivos con el nombre
Para llevar a cabo esta acción, se deben ejecutar los siguientes comandos:
# mkdir /var/tmp/patches
# chmod 755 /var/tmp/patches
# cd /var/tmp/patches
# unzip -qq *_SunAlert_Patch_Cluster.zip
# cd *_SunAlert_Patch_Cluster
# ./install_cluster -q
# cd ..
# rm -rf *_SunAlert_Patch_Cluster*
Durante el proceso de instalación del clúster, los administradores pueden ignorar instalaciones de parches individuales que fallan y que regresan un código 2, que indica que el parche ya ha sido instalado en el sistema; o regresan un código 8, que indica que el parche se aplica a un paquete del sistema que aún no está instalado en la máquina. Si una instalación de un parche falla con algún otro código de retorno, se deberá consultar la bitácora de la instalación del parche en /var/sadm/install_data.
Se debe tener en cuenta que además de instalar el clúster de parches como se ha descrito anteriormente, los administradores pueden revisar el archivo Solaris
Las mejores prácticas recomiendan verificar la integridad del software y parches descargados usando el archivo o paquete de firmas. El no hacerlo, puede resultar en que el sistema comience a ser comprometido por un caballo de Troya creado por un atacante con acceso no autorizado a los archivos del sitio. Sun proporciona firmas digitales para sus parches. Si es posible, se recomienda que los parches se apliquen en modo de usuario único.
Recursos adicionales
Solaris Patches and Updates
http://sunsolve.sun.com/show.do?target=patchpage
Solaris Patch Management Strategy
http://docs-pdf.sun.com/817-0574-12/817-0574-12.pdf
Solaris Patch Testing Overview
http://sunsolve.sun.com/search/document.do?assetkey=1-9-81064-1
Sun Software Update (Patch) Access Policy
http://sunsolve.sun.com/search/document.do?assetkey=1-9-83061-1
(ver http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/spfaq)
2.1.2 Instalar el kit de encriptación de Solaris 10
Para Solaris 10/06 y versiones anteriores, obtener el Kit de encriptación de Solaris 10 de:
http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=8&PartDetailId=Sol10-GA-Encryption-G-F&TransactionId=try
Para implementar esta acción, se deben ejecutar estos comandos:
# unzip -qq sol-10-encrypt-GA-iso.zip
# lofiadm -a `pwd`/sol-10-encrypt-GA.iso
/dev/lofi/1
Hay que tener en cuenta que el dispositivo devuelto en el paso anterior, será utilizado en el siguiente paso.
# mount -F hsfs -o ro /dev/lofi/1 /mnt
# cd /mnt/Encryption_10/`uname -p`/Packages
# pkgadd -d . all
[respond to pkgadd questions]
# cd
# umount /mnt
# lofiadm -d /dev/lofi/1
El Kit de cifrado de Solaris 10 contienen módulos del kernel que implementan diversos algoritmos de de cifrado para IPSec y Kerberos, utilidades que encriptan y desencriptan archivos desde la línea de comandos, y librerías con funciones que esas aplicaciones llaman para realizar el cifrado. El Kit de cifrado permite tamaños de llave más grandes (>128) para los siguientes algoritmos:
- AES (128, 192 y 256 bits)
- Blowfish (
- ARCFOUR/RC4 (
Es recomendable leer la documentación incluida en con los paquetes para mayor información. Los reglamentos para la exportación del software de cifrado están sujetos a cambios.
1.3 Instalar TCP Wrappers
TCP Wrappers permite al administrador controlar que hosts tienen acceso a varios servicios de red basado en el nombre de host y la dirección IP de la máquina. TCP Wrappers también proporciona información de bitácoras por medio de syslog sobre conexiones exitosas y fallidas.
El concepto de operación es la inclusión de un intermediario entre el servicio y el cliente, el cual verifica reglas de control de acceso para permitir o rechazar el establecimiento de la conexión.
El control de acceso se realiza a través de dos archivos de configuración /etc/hosts.allow y /etc/hosts.deny. Se verifican secuencialmente las reglas del archivo hosts.allow. Si se encuentra una coincidencia, se permite la conexión, y TCP Wrappers cede el control al servicio. En caso contrario, se verifican secuencialmente las reglas del archivo hosts.deny. Si se encuentra una coincidencia la conexión es rechazada. Si no existe una coincidencia en cualquiera de los dos archivos, la conexión es permitida.
Crear el archivo /etc/hosts.allow:
# echo "ALL:
Donde cada combinación
Crear el archivo /etc/hosts.deny:
# echo "ALL: ALL " > /etc/hosts.deny
Poner en marcha TCP Wrappers:
# cd /etc/default
# awk '/#ENABLE_TCPWRAPPERS/ { $1 = "ENABLE_TCPWRAPPERS=YES" }; \
{ print }' inetd > inetd.new
# mv inetd.new inetd
# chown root:sys inetd
# chmod 444 inetd
# pkill -HUP -u 0 -P 1 -x inetd
Las acciones anteriores solo proporcionan filtrado sobre servicios pasados en TCP que son generados por inetd. Para proteger servicios basados en UDP y RPC que son generados por inetd, se debe considerar implementar un cortafuegos local, como ipfilter. Revisar la información suministrada con el código fuente de TCP Wrappers para información sobre cómo utilizar filtrado TCP Wrappersstyle con demonios independientes que no son generados por inetd.
1.4 Generador de números aleatorios de referencia del sistema
Para aplicaciones que necesiten números aleatorios, éstos se deben configurar usando /dev/random o /dev/urandom, según corresponda.
Solaris viene con los dispositivos generadores de números aleatorios /dev/random y /dev/urandom. Éstos son preferibles a generadores como prngd, los cuales no son nativos del sistema operativo.
1.5 configurar IPsec
IPsec es un protocolo de la capa de red que emplea un robusto conjunto de mecanismos de seguridad a fin de proteger tráfico de red. IPsec consiste en dos paquetes de protocolos: Authentication Header (AH), que proporciona integridad de datos y autenticación de origen; y Encapsulating Security Payload (ESP), que proporciona confidencialidad, integridad de datos y autenticación de origen.
IPSec proporciona servicios de seguridad en la capa IP. Permite: seleccionar los protocolos de seguridad requeridos, determinar los algoritmos a utilizar, utilizar las claves criptográficas requeridas. Es utilizado para proteger uno o más “caminos” entre un par de hosts, un par de gateways de seguridad, un gateway de seguridad y un host.
La autenticación se logra utilizando los algoritmos MD-5 o SHA-1 para producir una suma de comprobación basada en los datos y la llave. El protocolo Authentication Header proporciona una integridad fuerte, autenticación de datos y secuencias parciales de integridad de datos (protección de repetición).
El protocolo Encapsulating Security Payload usa los algoritmos de encriptación DES, 3DES (Triple DES) o AES para proporcionar confidencialidad de datos y protección de análisis de tráfico. Además, ESP es capaz de proporcionar autenticación. Tanto AH y ESP implementan control de acceso mediante la distribución de claves públicas. Cada protocolo soporta dos modos, modo de transporte y modo de túnel.
Dado que IPsec opera sobre la capa de red, es transparente a las aplicaciones de red y protege todo el tráfico incluyendo TCP, UDP e ICMP.
1.5.1 Instalar el suplemento de encriptación de datos
Con el fin de utilizar el algoritmo de cifrado AES, es necesario instalar el suplemento de encriptación de Solaris. Los algoritmos de cifrado DES y 3DES son proporcionados como parte de la instalación base de Solaris.
Antes de instalar el suplemento de encriptación de datos de Solaris, se deben verificar que los paquetes necesarios no se encuentren instalados aún. El siguiente comando puede utilizarse para ello:
# for ver in SUNWcry SUNWcry64 SUNWcryrx SUNWcryr ;
do echo $ver VERSION `pkginfo -x $ver | sed 1d | awk '{ print $2 }' | cut -f1 -d,`; done
Si alguno de los cuatro paquetes son versión 11.9.0 o mayor, entonces el algoritmo de cifrado AES está ya instalado. Si no, entonces debe descargarse e instalarse.
1.5.2 Configuración de IPsec
Solaris 10 soporta Seguridad IP (IPsec) para IPv4 e IPv6. Originalmente introducido en el sistema operativo Solaris 8, IPsec y su protocolo de intercambio de llaves, IKE, se han mejorado en Solaris 10 para ofrecer soporte completo para el modo túnel, recorrido IKE NAT (RFC 3947 y RFC 3948), y el marco de trabajo de cifrado de Solaris.
En particular, el marco de trabajo criptográfico de Solaris proporciona un almacén de llaves softtoken para aplicaciones que usan el metaslot. Cuando IKE es configurado para usar el metaslot, las organizaciones tienen la opcion de almacenar la llave en disco, o en el almacén de claves softtoken.
Cómo proteger el tráfico entre dos sistemas con IPsec
IPsec de Solaris proporciona varias formas para proteger el tráfico de red. Puede proteger todo el tráfico entre dos hosts, proteger servicios individuales, ser usado como una red privada virtual (VPN) y también realizar filtrado simple de paquetes. Lo siguiente es un procedimiento para proteger todo el tráfico entre dos hosts con IPv4 utilizando ESP (usando su propia autenticación) con llaves compartidas. En este ejemplo, el tráfico entre 10.1.1.2 (textbox1) y 10.1.1.3 (textbox2) será asegurado.
Configurar las Políticas de Seguridad
Para propósitos de seguridad, este procedimiento debe realizarse encontrándose en la zona global para poder configurar la política IPsec. En la consola del sistema, asumir el rol de administrador principal o convertirse en superusuario.
Los siguientes comandos deben ejecutarse para crear el archivo de políticas de seguridad. Éste puede ser cualquier archivo; sin embargo, debe tener los correctos permisos y propiedades. Para este ejemplo, será usado el archivo /etc/inet/ipsec.pol.
En el primer host (textbox1), se deben ejecutar los siguientes comandos:
# cat <
{ saddr 10.1.1.2 daddr 10.1.1.3 } apply \
{ encr_algs 3des encr_auth_algs md5 sa shared }
{ saddr 10.1.1.3 daddr 10.1.1.2 } permit \
{ encr_algs 3des encr_auth_algs md5 }
EOF
Establecer la propiedad y los permisos del archivo:
# chown root:root /etc/inet/ipsec.pol
# chmod 600 /etc/inet/ipsec.pol
El archivo /etc/inet/ipsec.pol podrá leerse así:
{ saddr 10.1.1.2 daddr 10.1.1.3 } apply { encr_algs 3des encr_auth_algs md5 sa shared }
{ saddr 10.1.1.3 daddr 10.1.1.2 } permit { encr_algs 3des
encr_auth_algs md5 }
la primera línea especifica la política para el tráfico saliente. Ella indica que todo el tráfico con dirección IP origen (left) 10.1.1.2 (textbox1) y dirección IP destino (right) utilizará el algoritmo de encriptación 3DES, el algoritmo de autenticación MD-5 y llaves compartidas. La segunda línea especifica la política para tráfico entrante. Indica que todo el tráfico con dirección IP origen (right) 10.1.1.3 y dirección IP destino (left) 10.1.1.2 debe usar el algoritmo de encriptación 3DES y el algoritmo de autenticación MD-5.
En el segundo host (textbox2) se deben ejecutar líneas similares, invirtiendo las direcciones IP origen y destino.
Generar llaves aleatorias
Se puede configurar el intercambio de claves de Internet (IKE) para crear las SA automáticamente. También se pueden agregar las SA de forma manual. Se debe utilizar IKE a menos que se tenga una razón de peso para generar y mantener las claves manualmente. La administración de claves IKE es más segura que la administración manual.
Si está especificando claves manualmente, el material de claves debe ser aleatorio. El formato del material de claves de un sistema Solaris es hexadecimal. Otros sistemas operativos pueden requerir material de claves ASCII. Para generar material de claves para un sistema Solaris que se comunica con otro sistema operativo que requiera ASCII.
Se puede utilizar el comando od con el dispositivo Solaris /dev/random como entrada. Para más información, consulte la página del comando man od.
Para generar las llaves para AH y ESP en formato hexadecimal, se utiliza el siguiente comando:
# od -x|-X -A n
- -x Muestra el vaciado octal en formato hexadecimal. El formato hexadecimal resulta útil para el material de claves. Dicho formato se imprime en bloques de 4 caracteres.
- -X Muestra el vaciado octal en formato hexadecimal. Dicho formato se imprime en bloques de 8 caracteres.
- -A n Elimina la base de desfase de entrada de la pantalla.
Actúa como origen para los números aleatorios. - head –
Limita el resultado de la pantalla a las primeras n líneas.
Combinar el resultado para crear una clave con la longitud adecuada. Eliminar los espacios entre los números de una línea para crear una clave de 32 caracteres. Una clave de 32 caracteres tiene 128 bits. En el caso de un índice de parámetros de seguridad (SPI), debe utilizar una clave de 8 caracteres. La clave debe utilizar el prefijo 0x.
Generación de material de claves para IPsec
El ejemplo siguiente muestra dos líneas de claves en grupos de ocho caracteres hexadecimales cada uno.
# od -X -A n /dev/random | head -2
d54d1536 4a3e0352 0faf93bd 24fd6cad
8ecc2670 f3447465 20db0b0c c83f5a4b
Al combinar los cuatro números de la primera línea, puede crear una clave de 32 caracteres. Un número de 8 caracteres precedido de 0x proporciona un valor de SPI adecuado, por ejemplo, 0xf3447465.
Cada algoritmo requiere una llave de tamaño específico. El número de caracteres usado para el resultado anterior depende del algoritmo usado. La siguiente lista muestra las longitudes de las llaves para cada algoritmo de encriptación y autenticación:
MD-5 (128 bits) 32 caracteres
SHA-1 (160 bits) 40 caracteres
DES (64 bits) 16 caracteres
3DES (192 bits) 48 caracteres
AES (128, 192, 256 bits) 32, 48, 68 caracteres
Por ejemplo, si se va a utilizar MD-5 como algoritmo de autenticación, la siguiente cadena de 32 caracteres resultante puede ser utilizada para la llave.
48078bfa312893bbb7b0ac133449f71f
Para generar las llaves para cada SPI, se utiliza el siguiente comando:
# od -X -A n –N 4 /dev/random | head -2
La salida debe ser de 8 caracteres pseudo aleatorios similar a:
06075310
Los SPI tienen una llave de tamaño de 8 caracteres octales. Cada SPI debe ser único. Se debe ejecutar este comando para cada SPI único requerido. En el ejemplo se requieren dos SPIs únicos, uno para textbox1 y otro para textbox2.
Cada una de estas llaves deben ser idénticas en cada host para que IPsec funcione apropiadamente.
Configurar la asociación de seguridad
Antes de comenzar, se debe estar en la zona global para administrar material de claves para una zona no global.
Se necesitan tres números aleatorios hexadecimales para el tráfico saliente y tres para el tráfico entrante. Por tanto, un sistema necesita generar los siguientes números:
- Dos números aleatorios hexadecimales como valor para la palabra clave spi.Un número es para el tráfico saliente. Otro es para el tráfico entrante. Cada número puede tener hasta ocho caracteres de longitud.
- Dos números aleatorios hexadecimales para el algoritmo MD5 para AH. Cada número debe tener 32 caracteres de longitud. Un número es para dst textbox1. Un número es para dst textbox2.
- Dos números aleatorios hexadecimales para el algoritmo 3DES para ESP. Para una clave de 192 bits, cada numero debe tener 48 caracteres de longitud. Un número es para dst textbox1.Un número es para dst textbox2.
En la consola del sistema de uno de los sistemas, se debe asumir el rol de administrador principal o convertirse en superusuario
Active el modo de comando ipseckey.
# ipseckey >
>
El símbolo del sistema > indica que se encuentra en modo de comando ipseckey.
Vaciar las SA existentes:
> flush
>
Para evitar que un intruso interrumpa las SA, debe sustituir el material de claves. Es necesario coordinar la sustitución de claves en los sistemas que se comunican. Al sustituir las SA en un sistema, también deben sustituirse las del sistema remoto.
Para crear SA, se debe jecutar el comando siguiente.
> add protocolo spi cadena_hex_aleatoria \
src dir dst dir2 \
prefijo_protocolo_alg algoritmo_protocolo \
prefijo_protocolokey cadena_hex_aleatoria_de_longitud_algoritmo_especificada
Esta sintaxis también se utiliza para sustituir las SA que acaba de vaciar.
- protocolo Especifica esp o ah.
- cadena_hex_aleatoria Especifica un número aleatorio de hasta ocho caracteres en formato hexadecimal. Preceda los caracteres con 0x. Si especifica más números de los que acepta el índice de parámetros de seguridad (SPI), el sistema omitirá los números adicionales. Si especifica menos números de los que acepta el SPI, el sistema rellena la entrada.
- dir Especifica la dirección IP de un sistema.
- dir2 Especifica la dirección IP del sistema equivalente a dir.
- prefijo_protocolo Especifica un prefijo encr o auth. El prefijo encr se utiliza con el protocolo esp. El prefijo auth se utiliza con el protocolo ah, y para autenticar el protocolo esp.
- algoritmo_protocolo Especifica un algoritmo para ESP o AH. Cada algoritmo requiere una clave de una longitud específica. Los algoritmos de autenticación incluyen MD5 y SHA. Los algoritmos de cifrado incluyen 3DES y AES.
- cadena_hex_aleatoria_de_longitud_algoritmo_especificada Especifica un número hexadecimal aleatorio de la longitud que requiere el algoritmo. Por ejemplo, el algoritmo MD5 requiere una cadena de 32 caracteres para su clave de 128 bits. El algoritmo 3DES requiere una cadena de 48 caracteres para su clave de 192 bits.
Por ejemplo, en el sistema textbox1, proteja los paquetes salientes, se utilizan los números aleatorios generados.
Para Solaris 10 1/06:
> add esp spi 0x8bcd1407 \
src 10.1.12 dst 10.1.1.3 \
encr_alg 3des \
auth_alg md5 \
encrkey d41fb74470271826a8e7a80d343cc5aae9e2a7f05f13730d \
authkey e896f8df7f78d6cab36c94ccf293f031
>
El sistema equivalente debe utilizar el mismo material de claves y el mismo SPI.
Continuando en modo de comando ipseckey en el sistema textbox1, para proteger los paquetes entrantes. Escribir los siguientes comandos para proteger los paquetes:
> add esp spi 0x122a43e4 \
src 192.168.13.213 dst 192.168.116.16 \
encr_alg 3des \
auth_alg md5 \
encrkey dd325c5c137fb4739a55c9b3a1747baa06359826a5e4358e \
authkey ad9ced7ad5f255c9a8605fba5eb4d2fd
>
Las claves y el SPI pueden ser diferentes para cada SA. Se deben asignar claves y SPI distintos para cada SA.
Para salir del modo de comando ipseckey, pulsar Control-D o escribir quit. Para asegurarse de que el material de claves esté disponible para IPsec tras el rearranque, agregar el material de claves al archivo /etc/inet/secret/ipseckeys.
Las líneas del archivo /etc/inet/secret/ipseckeys son idénticas al lenguaje de la línea de comandos.
Por ejemplo, el archivo /etc/inet/secret/ipseckeys del sistema textbox1tendría un aspecto similar al siguiente:
# ipseckeys - This file takes the file format documented in
# ipseckey(1m).
# Note that naming services might not be available when this file
# loads, just like ipsecinit.conf.
#
# for outbound packets on enigma
add esp spi 0x8bcd1407 \
src 192.168.116.16 dst 192.168.13.213 \
encr_alg 3des \
auth_alg md5 \
encrkey d41fb74470271826a8e7a80d343cc5aae9e2a7f05f13730d
authkey e896f8df7f78d6cab36c94ccf293f031
#
# for inbound packets
add esp spi 0x122a43e4 \
src 192.168.13.213 dst 192.168.116.16 \
encr_alg 3des \
auth_alg md5 \
encrkey dd325c5c137fb4739a55c9b3a1747baa06359826a5e4358e
authkey ad9ced7ad5f255c9a8605fba5eb4d2fd
Proteger el archivo con permisos de sólo lectura.
# chmod 400 /etc/inet/secret/ipseckeys
2.6 Configurar servidor SSH
Originalmente basado en una instancia del software OpenSSH, Solaris Secure Shell permite a usuarios o servicios acceder o transferir archivos entre sistemas remotos sobre un canal de comunicación encriptado. En Solaris Secure Shell, la autenticación es proporcionada por el usuario por medio de passwords, llaves públicas o ambos. Todo el tráfico de red es encriptado. Por lo tanto, Solaris Secure Shell previene una intrusión capaz de leer una comunicación encriptada. Solaris Secure Shell incluso puede ser usado como una red privada virtual bajo demanda que puede pasar tráfico del sistema X Window o conectar números de puertos individuales entre máquinas locales y máquinas remotas sobre un enlace encriptado.
La configuración de Solaris Secure Shell está contenida en los siguientes archivos:
- /etc/ssh/ssh_config. Este archivo proporciona todo el sistema de ajustes por defecto para la porción de software del cliente de Solaris Secure Shell, ssh. Para mayor información sobre qué ajustes están disponibles, consultar ssh_config. Estos ajustes también pueden ser anulados por un usuario mediante la creación de un fichero $HOME/.ssh/config.
- /etc/ssh/sshd_config. Este archivo proporciona todo el sistema de ajustes por defecto de la porción de software para servidor de Solaris Secure Shell, sshd. Para más información sobre los ajustes disponibles, consultar sshd_config.
2.6.1 Cómo crear autenticación basada en host para Solaris Secure Shell
El siguiente procedimiento establece un sistema de llave pública donde la llave pública del cliente es usada para autenticarse en el servidor. El usuario también debe crear un par de llaves pública y privada.
Los términos cliente y host local se refieren a la máquina donde el usuario escribe el comando ssh. Los términos servidor y host remoto se refieren a la máquina que el cliente está tratando de alcanzar.
Asumir la función de Administrador Primario, o convertirse en superusuario
La principal función de Administrador Primario incluye el perfil de Administrador.
Habilitar la autenticación basada en host en el cliente
En el archivo de configuración del cliente, /etc/ssh/ssh_config, escribir la siguiente entrada:
HostbasedAuthentication yes
En el servidor, habilitar la autenticación basada en host
En el archivo de configuración del servidor, /etc/ssh/sshd_config, escribir la misma entrada:
HostbasedAuthentication yes
En el servidor, configurar un archivo que habilita al cliente para ser reconocido como un host confiable.
Para mayor información, consultar la sección FILES del manual de sshd.
Agregar los clientes como una entrada en el archivo del servidor /etc/shosts.equiv.
cliente-host
O se puede instruir a los usuarios a añadir una entrada para el cliente su archivo ~/.shosts en el servidor.
cliente-host
En el servidor, asegurarse de que el demonio sshd puede a la lista de hosts de confianza. Establecer IgnoreRhosts a no en el archivo /etc/ssh/sshd_config.
# sshd_config
IgnoreRhosts no
Asegurar que los usuarios de Solaris Secure Shell tengan cuentas en ambos hosts.
Hacer alguna de estas acciones para colocar la llave pública del cliente en el servidor:
- Modificar el archivo sshd_config en el servidor. Posteriormente, instruir a los usuarios a agregar la llave pública del host cliente a su archivo ~/.ssh/known_hosts.
# sshd_config
IgnoreUserKnownHosts no
- Copiar la llave pública del cliente al servidor. Las llaves de los hosts se guardan en el directorio /etc/ssh. Las llaves son generadas generalmente por el demonio sshd en el primer arranque.
- Agregar la llave al archivo /etc/ssh/ssh_known_hosts en el servidor. En el cliente, escribir el siguiente comando en una sola línea sin la barra invertida.
# cat /etc/ssh/ssh_host_dsa_key.pub | ssh \
RemoteHost ’cat >> /etc/ssh/ssh_known_hosts && \
echo "Host key copied"’
- Cuando se solicite, suministrar el password de login. Cuando el archivo se haya copiado, se mostrará el mensaje “Host key copied”
2.6.2 Habilitar Solaris Secure Shell v1
Este procedimiento es muy útil cuando un host interactúa con otro que corren v1 y v2 respectivamente.
Antes que nada, se debe asumir el rol de administrador o convertirse en súper usuario.
Configurar el host que utilizará ambos protocolos. Editar el archivo /etc/ssh/sshd_config.
# Protocol 2
Protocol 2,1
Suministrar un archivo aparte para la llave del host para la versión v1. Agregar una entrada HostKey al archivo /etc/ssh/sshd_config.
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_rsa1_key
Generar una llave de host para la versión v1.
# ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_rsa1_key -N ’’
-t rsa1 Indica el algoritmo RSA para v1.
-f Indica el archivo que tiene la llave de host.
-N ’’ Indica que no requiere passphrase.
Reiniciar el demonio sshd. Incluso se puede reiniciar el sistema.
# svcadm restart network/ssh:default
2.6.3 Configurar el forward de puertos en Solaris Secure Shell
El forward de puertos permite a un puerto local ser transmitido a un host remoto. Efectivamente, un socket es colocado para escuchar el puerto en el lado local. Similarmente, un puerto puede ser especificado en el lado remoto.
El forward de puertos de Solaris Secure Shell debe utilizar conexiones TCP. Solaris Secure Shell no soporta forward de puertos para conexiones UDP.
Para configurar el forwarding, se debe asumir el rol de administrador o convertirse en súper usuario.
Configurar Solaris Secure Shell en el servidor remoto para permitir forward de puertos. Cambiar el valor de AllowTcpForwarding a yes en el archivo /etc/ssh/sshd_config.
# Port forwarding
AllowTcpForwarding yes
Reiniciar el servicio ssh de Solaris.
remoteHost# svcadm restart network/ssh:default
Verificar que el forward de puertos pueda utilizarse.
remoteHost# /usr/bin/pgrep -lf sshd
1296 ssh -L 2001:remoteHost:23 remoteHost
2.7 Configurar Kerberos
El servicio Kerberos es una arquitectura cliente-servidor que proporciona transacciones seguras en una red. El servicio proporciona una autenticación fuerte de usuarios, así como integridad y privacidad. La autenticación garantiza que las identidades del emisor y del receptor en una red son ciertas. El servicio incluso verifica la validez de los datos que se transmiten en uno y otro sentido (integridad) y encripta los datos durante la transmisión (privacidad). Usando el servicio Kerberos, se puede acceder a otras máquinas, intercambiar información y transferir archivos de forma segura. Adicionalmente, el servicio proporciona autorización de servicios, los cuales permiten a los administradores a restringir acceso a servicios y a máquinas. Por otra parte, como usuario de Kerberos, se puede regular el acceso de otros usuarios a la cuenta propia.
El servicio Kerberos es una señal simple en el sistema, lo que significa que solamente se necesita autenticarse así mismo una vez por sesión, y automáticamente todas las transacciones subsecuentes serán seguras durante la sesión. Después de que el servicio Kerberos ha autenticado a un usuario, no necesitará autenticarse cada vez que utilice un comando basado en Kerberos como ftp o rsh, o acceder datos en un sistema NFS. Por lo tanto, no se tiene que enviar el password por la red, donde puede ser interceptado cada vez que se utilicen esos servicios.
El servicio Kerberos de Solaris está basado en el protocolo de autenticación de red Kerberos V5 que fue desarrollado en el Instituto de Tecnología de Massachussets (MIT). Debido a que el protocolo Kerberos es una norma industrial estándar generalmente aceptada y ampliamente utilizada para seguridad en redes, la versión de Solaris promueve la compatibilidad con otros sistemas que utilicen la versión V5 del protocolo Kerberos, el servicio permite proteger transacciones en redes heterogéneas. Por otra parte, el servicio proporciona la autenticación y seguridad entre dominios y dentro de un único dominio.
El servicio Solaris permite flexibilidad en la gestión de aplicaciones de Solaris. Se puede configurar el servicio para permitir peticiones basadas o no en kerberos para servicios de red, como el servicio NFS, telnet, ftp, rlogin y Secure Shell. Como resultado, las aplicaciones de Solaris actuales siguen funcionando incluso si están corriendo en sistemas en los cuales el servicio Kerberos no esté habilitado. Por supuesto, también se puede configurar Kerberos para permitir peticiones de red basadas en Kerberos únicamente.
Kerberos proporciona un mecanismo de seguridad el cual permite el uso de Kerberos para autenticación, integridad y privacidad cuando se utilizan aplicaciones que usan el servicio de seguridad genérico de interfaz de programación de aplicaciones (GSS-API). Sin embargo, las aplicaciones no tienen que mantener compromiso con Kerberos si otro mecanismo de seguridad es desrrollado. Dado que el servicio está diseñado para integrar modularidad dentro de GSS-API, las aplicaciones que usen GSS-API pueden utilizar cualquier mecanismo de seguridad que mejor se adapte a sus necesidades.
2.7.1 Configurar un servidor KDC
Asumir el rol de administrador o convertirse en súper usuario.
Crear el KDC
Ejecutar la utilidad kdcmgr para crear el KDC. Se necesita suministrar el password para la llave maestra y el password para el director administrativo.
kdc1# kdcmgr -a kws/admin -r EXAMPLE.COM create master
Starting server setup
---------------------------------------
Setting up /etc/krb5/kdc.conf
Setting up /etc/krb5/krb5.conf
Initializing database ’/var/krb5/principal’ for realm ’EXAMPLE.COM’,
master key name ’K/M@EXAMPLE.COM’
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:
Authenticating as principal root/admin@EXAMPLE.COM with password.
WARNING: no policy specified for kws/admin@EXAMPLE.COM; defaulting to no policy
Enter password for principal "kws/admin@EXAMPLE.COM":
Re-enter password for principal "kws/admin@EXAMPLE.COM":
Principal "kws/admin@EXAMPLE.COM" created.
Setting up /etc/krb5/kadm5.acl.
---------------------------------------------------
Setup COMPLETE.
kdc1#
Configurar el KDC Maestro
En este procedimiento se condigura la propagación incremental. Además se utilizan los siguientes parámetros de configuración:
- Realm name = EXAMPLE.COM
- DNS domain name = example.com
- Master KDC = kdc1.example.com
- admin principal = kws/admin
- Online help URL = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956
Antes de comenzar, este procedimiento requiere que el host esté configurado para utilizar DNS.
Asumir el rol de administrador o convertirse en súper usuario.
Editar el archivo de configuración de Kerberos (krb5.conf).
Es necesario cambiar el reino de nombres y los nombres de los servidores. Véase el manual de krb5.conf para una completa descripción de este archivo.
kdc1 # cat /etc/krb5/krb5.conf
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = kdc1.example.com
admin_server = kdc1.example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
#
# if the domain name and realm name are equivalent,
# this entry is not needed
#
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
[appdefaults]
gkadmin = {
help_url = \ http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956
}
En este ejemplo, las entradas de las líneas default_realm, kdc, admin_server, y all domain_realm fueron cambiadas. En adición, la línea que define help_url fue editada.
Editar el archivo de configuración de KDC (kdc.conf)
Es necesario cambiar el nombre del reino. Revisar el manual de kdc.conf para mayor información acerca de este archivo.
kdc1 # cat /etc/krb5/kdc.conf
[kdcdefaults]
kdc_ports = 88,750
[realms]
EXAMPLE.COM = {
profile = /etc/krb5/krb5.conf
database_name = /var/krb5/principal
admin_keytab = /etc/krb5/kadm5.keytab
acl_file = /etc/krb5/kadm5.acl
kadmind_port = 749
max_life = 8h 0m 0s
max_renewable_life = 7d 0h 0m 0s
sunw_dbprop_enable = true
sunw_dbprop_master_ulogsize = 1000
}
En este ejemplo, la definición del nombre del reino en la sección realms fue modificada. También en la sección realms, fueron agregadas líneas que permiten propagación incremental y el número de actualizaciones que el KDC Maestro mantiene en la bitácora.
Crear la base de datos del KDC usando el comando kdb5_util
El comando kdb5_util crea la base de datos de KDC. Además, cuando se utiliza con la opción-s, este comando crea un archivo oculto que se utiliza para autenticar el KDC a sí mismo antes que los demonios kadmind y krb5kdc se inicien.
kdc1 # /usr/sbin/kdb5_util create -s
Initializing database ’/var/krb5/principal’ for realm ’EXAMPLE.COM’
master key name ’K/M@EXAMPLE.COM’
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:
Editar el archive de la lista de control de acceso de Kerberos (kadm5.acl)
Una vez pobladas, el archivo /etc/krb5/kadm5.acl debe contener todos los nombres principales que son permitidos para administrar el KDC.
kws/admin@EXAMPLE.COM *
La entrada da al principal kws/admin la habilidad de modificar directivas o políticas en el KDC en el reino EXAMPLE.COM. la instalación por defecto incluye un asterisco para seleccionar todos los administradores principales, esto es un riesgo de seguridad, por lo que es más recomendable incluir una lista de todos los administradores principales.
Iniciar el comando kadmin.local y agregar principales.
El siguiente paso crea principales que son usados por el servicio Kerberos.
kdc1 # /usr/sbin/kadmin.local
kadmin.local:
añadir los principales de administración a la base de datos. Se pueden agregar los principales que se necesiten. Se debe agregar al menos un administrador principal para completar el proceso de configuración de KDC. Para este ejemplo, se agregó el principal kws/admin. Se puede sustituir “kws” por un nombre apropiado para el principal.
kadmin.local: addprinc kws/admin
Enter password for principal kws/admin@EXAMPLE.COM: \
Re-enter password for principal kws/admin@EXAMPLE.COM: \
Principal "kws/admin@EXAMPLE.COM" created.
kadmin.local:
Crear los principales kiprop
El principal kiprop es utilizado para autorizar actualizaciones para el KDC maestro.
kadmin.local: addprinc -randkey kiprop/kdc1.example.com
Principal "kiprop/kdc1.example.com@EXAMPLE.COM" created.
kadmin.local:
Crear el archivo keytab para el servicio kadmin
Esta secuencia de comandos crea un archivo especial keytab con las entradas principales para kadmin/
kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc1.example.com kadmin.local: ktadd -k /etc/krb5/kadm5.keytab changepw/kdc1.example.com
kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/changepw
kadmin.local:
Agregar el principal kiprop para el servidor KDC maestro al archivo keytab de kadmind
Añadiendo el principal kiprop al archivo kadm5.keytab se permite al kadmind autenticarse a sí mismo cuando la propagación incremental inicia.
kadmin.local: ktadd -k /etc/krb5/kadm5.keytab \
kiprop/kdc1.example.com
kadmin.local:
Salir de kadmin.local, ya se han agregado todos los principales para los siguientes pasos.
kadmin.local: quit
Iniciar los demonios de Kerberos
kdc1 # svcadm enable -r network/security/krb5kdc
kdc1 # svcadm enable -r network/security/kadmin
Iniciar kadmin y agregar más principales
En este punto, se pueden agregar principales mediante la herramienta de administración gráfica de Kerberos. Para ello, se necesita registrarse en ella con uno de los nombres de los principales que se crearon antes en este procedimiento. Sin embargo, el siguiente comando es mostrado por simplicidad.
kdc1 # /usr/sbin/kadmin -p kws/admin
Enter password:
kadmin:
Crear el principal de host del KDC maestro
El principal de host es usado por aplicaciones Kerberizadas, como kprop para propagar cambios a los esclavos KDCs. Este principal también se utiliza para proporcionar acceso remoto seguro al servidor KDC usando aplicaciones como ssh. Nótese que cuando la instancia del principal es un nombre de host, el FQDN debe ser especificado en minúsculas, independientemente de cómo se encuentre escrito el nombre de dominio en el archivo /etc/resolv.conf.
kadmin: addprinc -randkey host/kdc1.example.com
Principal "host/kdc1.example.com@EXAMPLE.COM" created.
kadmin:
Agregar el principal de host del KDC maestro al archivo keytab del KDC maestro.
Agregar el principal de host al archivo keytab, permite a este principal ser usado por aplicaciones del servidor, como sshd, automáticamente.
kadmin: ktadd host/kdc1.example.com
kadmin:
Cerrar kadmin
kadmin: quit
2.7.2 Configurar un esclavo KDC
En este procedimiento se configura un nuevo esclavo KDC llamado kdc2. Además, se configura la propagación incremental. Este procedimiento utiliza los siguientes parámetros de configuración:
Realm name = EXAMPLE.COM
DNS domain name = example.com
Master KDC = kdc1.example.com
Slave KDC = kdc2.example.com
admin principal = kws/admin
Antes de comenzar, el KDC maestro debe estar configurado y se debe asumir el rol de root o de súper usuario.
Iniciar kadmin en el KDC maestro. El usuario debe registrarse usando uno de los nombres de los principales del admin. creados cuando se configuró el KDC maestro.
kdc1 # /usr/sbin/kadmin -p kws/admin
Enter password:
kadmin:
Añadir los principales de host del esclavo en la base de datos en el KDC maestro. Para que el esclavo funcione, debe tener un principal de host. Nótese que mientras la instancia del principal es un nombre de host, el FQDN debe ser especificado en minúsculas, sin importar cómo este el nombre de dominio en el archivo /etc/resolv.conf.
kadmin: addprinc -randkey host/kdc2.example.com
Principal "host/kdc2.example.com@EXAMPLE.COM" created.
kadmin:
Crear el principal kiprop en el KDC maestro. El principal kiprop se utiliza para autorizar la propagación incremental del KDC maestro.
kadmin: addprinc -randkey kiprop/kdc2.example.com
Principal "kiprop/kdc2.example.com@EXAMPLE.COM" created.
kadmin:
Salir del kadmin.
kadmin: quit
Editar el archivo de configuración de Kerberos (krb5.conf) en el KDC maestro. Es necesario agregar una entrada para cada esclavo. Véase el manual del archivo krb5.conf para una descripción completa de este archivo.
kdc1 # cat /etc/krb5/krb5.conf
.
.
[realms]
EXAMPLE.COM = {
kdc = kdc1.example.com
kdc = kdc2.example.com
admin_server = kdc1.example.com
}
Añadir una entrada para kiprop en el archivo kadm5.acl en el KDC maestro. Esta entrada permite al KDC maestro recibir solicitudes para propagación incremental para el servidor kdc2.
kdc1 # cat /etc/krb5/kadm5.acl
*/admin@EXAMPLE.COM *
kiprop/kdc2.example.com@EXAMPLE.COM p
En el KDC maestro, reiniciar el kadmind las nuevas entradas en el archivo kadm5.acl.
kdc1 # svcadm restart network/security/kadmin
En todos los KDC esclavos, copiar los archivos de administración de KDCdel servidor KDC maestro.Este paso debe ser seguido en todos los KDC esclavos, debido a que el servidor KDC maestro ha actualizado información que cada servidor KDC necesita. Se puede utilizar ftp o un mecanismo de transferencia similar para realizar copias de los siguientes archivos desde el servidor KDC maestro.
- /etc/krb5/krb5.conf
- /etc/krb5/kdc.conf
En todos los KDCs esclavos, agregar una entrada para el KDC maestro y cada KDC esclavo dentro del archivo de configuración de propagación kpropd.acl. Esta información debe actualizarse en todos los servidores KDC esclavos.
kdc2 # cat /etc/krb5/kpropd.acl
host/kdc1.example.com@EXAMPLE.COM
host/kdc2.example.com@EXAMPLE.COM
Asegurarse de que el archivo de control de acceso de Kerberos, kadm5.acl, en todos los KDC esclavos, no tenga acceso público. Un archivo kadm5.acl sin modificar se vería así:
kdc2 # cat /etc/krb5/kadm5.acl
*/admin@___default_realm___ *
Si el archivo contiene entradas kiprop, entonces hay que removerlas.
En el nuevo esclavo, modificar una entrada en kdc.conf. Reemplazar la entrada sunw_dbprop_master_ulogsize con una entrada que defina sunw_dbprop_slave_poll. La entrada fija el tiempo de encuesta a 2 minutos.
kdc1 # cat /etc/krb5/kdc.conf
[kdcdefaults]
kdc_ports = 88,750
[realms]
EXAMPLE.COM= {
profile = /etc/krb5/krb5.conf
database_name = /var/krb5/principal
admin_keytab = /etc/krb5/kadm5.keytab
acl_file = /etc/krb5/kadm5.acl
kadmind_port = 749
max_life = 8h 0m 0s
max_renewable_life = 7d 0h 0m 0s
sunw_dbprop_enable = true
sunw_dbprop_slave_poll = 2m
}
En el nuevo esclavo, iniciar el comando kadmin. Se debe registrar utilizando un nombre de un principal de admin que se crearon cuando se configuró el KDC maestro.
kdc2 # /usr/sbin/kadmin -p kws/admin
Enter password:
kadmin:
Agregar el principal de host del esclavo al archivo keytab del esclavo usando kadmin. Esta entrada permite funcionar a kprop y a otras aplicaciones Kerberizadas. Cuando la instancia del principal es un nombre de host, el FQDN debe especificarse en minúsculas sin importar cómo esté escrito el dominio en el archivo /etc/resolv.conf.
kadmin: ktadd host/kdc2.example.com
Entry for principal host/kdc2.example.com with kvno 3, encryption type AES-256 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc2.example.com with kvno 3, encryption type AES-128 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc2.example.com with kvno 3, encryption type Triple DES cbc
mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc2.example.com with kvno 3, encryption type ArcFour
with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc2.example.com with kvno 3, encryption type DES cbc mode
with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:
Agregar el principal de kiprop al archivo krb5.keytab del KDC esclavo. Agregar el principal kiprop al archivo krb5.keytab permite al comando kpropd autenticarse a sí mismo cuando se propagación se inicia.
kadmin: ktadd kiprop/kdc2.example.com
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type AES-256 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type AES-128 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type Triple DES cbc
mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type ArcFour
with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type DES cbc mode
with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:
Salir del kadmin
kadmin: quit
En el nuevo demonio, iniciar el demonio de propagación.
kdc2 # /usr/lib/krb5/kpropd
En el nuevo esclavo, crear un archivo oculto usando kdb5_util.
kdc2 # /usr/sbin/kdb5_util stash
kdb5_util: Cannot find/read stored master key while reading master key
kdb5_util: Warning: proceeding without master key
Enter KDC database master key:
Matar el demonio de propagación de Kerberos.
kdc2 # pkill kpropd
En el nuevo esclavo, iniciar el demonio KDC (krb5kdc). Cuando el servicio krb5kdc es habilitado, también se inicia kpropd si el sistema está configurado como un esclavo.
kdc2 # svcadm enable network/security/krb5kdc
