Red Hat Network Satellite 5.4 Guía de configuración de cliente. Red Hat Network Satellite

Transcripción

1 Red Hat Network Satellite 5.4 Guía de configuración de cliente Red Hat Network Satellite

2 Guía de configuración de cliente Red Hat Network Satellite 5.4 Guía de configuración de cliente Red Hat Network Satellite Edición 1 Copyright 2010 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux is the registered trademark of Linus Torvalds in the United States and other countries. Java is a registered trademark of Oracle and/or its affiliates. XFS is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL is a registered trademark of MySQL AB in the United States, the European Union and other countries. All other trademarks are the property of their respective owners Varsity Drive Raleigh, NC USA Phone: Phone: Fax: Bienvenido a la Guía de configuración de cliente de Red Hat Network Satellite.

3 1. Introducción 1 2. Aplicaciones de cliente Implementación de los últimos RPM clientes de Red Hat Network Configuración de las aplicaciones cliente Registro con las llaves de activación Opción up2date --configure Actualización manual de los archivos de configuración Implementación del servidor alternativo Programa actualizador de paquetes Configuración de la Red Hat Network Alert Notification Tool con Satélite Infraestructura del SSL Una breve introducción al SSL Uso de RHN SSL Maintenance Tool Explicación de la generación de SSL Opciones de RHN SSL Maintenance Tool Generación del par de llaves CA SSL Generación del juego de llaves SSL del servidor web Implementación del certificado público CA SSL a los clientes Configuración de los sistemas cliente Importación de las llaves GPG personalizadas Uso de RHN Bootstrap Preparación Generación Uso del script Opciones de RHN Bootstrap Creación manual del script de configuración Implementación de Kickstart 29 A. Script de ejemplo Bootstrap 31 B. Historial de revisiones 35 Índice 37 iii

4 iv

5 Introducción Este manual tiene la intención de asistir de una forma sencilla a los usuarios del RHN Satellite Server y del RHN Proxy Server en la configuración de sus sistemas clientes. Por defecto, todas las aplicaciones cliente de Red Hat Network están configuradas para comunicarse con los servidores centrales de Red Hat Network. Algunos de los parámetros de los sistemas cliente deben ser alterados cuando se conectan con el servidor satélite de RHN o el RHN Proxy Server. Es sencillo modificar uno o dos sistemas; pero un entorno empresarial grande puede contener cientos o miles de sistemas que podrían beneficiarse de los pasos de reconfiguración en masa descritos en este manual. Debido a la complejidad de esta tarea, los usuarios podrían utilizar un script existente que automatice muchas de las tareas necesarias para tener acceso a sus servidores satélite o Proxy. Consulte el Capítulo 5, Uso de RHN Bootstrap para obtener mayor información. Red Hat cree que es importante entender las implicaciones de estos cambios de configuración, por ello describe los pasos de reconfiguración manual en los primeros capítulos. Tenga en cuenta las necesidades de su organización para determinar la solución ideal. Aunque muchos de los comandos proporcionados dentro de esta guía pueden ser aplicados tal y como aparecen, es imposible predecir todas las posibilidades de configuraciones de red adoptados por los usuarios. Por lo tanto, Red Hat recomienda usar estos comandos como referencias que deben ser tenidas en cuenta en la configuración individual de su empresa. Nota La información de la configuración de los clientes Unix puede encontrarse en la Guía de referencia del RHN Satellite Server en el capítulo Soporte para Unix. 1

6 2

7 Aplicaciones de cliente Para poder utilizar la mayoría de las funciones de clase empresarial de Red Hat Network, tales como el registro de sistemas con el satélite de RHN, se requiere la configuración de las aplicaciones cliente más recientes. El obtener estas aplicaciones antes de que el cliente se haya registrado con Red Hat Network puede ser difícil. Esta paradoja es especialmente problemática para usuarios que migran un número amplio de antiguos sistemas a Red Hat Network. Este capítulo identifica varias técnicas para resolver este problema. Importante Red Hat recomienda que los clientes conectados al RHN Proxy Server o al servidor satélite de RHN estén ejecutando la actualización más reciente de Red Hat Enterprise Linux para asegurar una apropiada conectividad. Adicionalmente, si el cortafuegos del cliente está configurado, los puertos 80 y 443 deben estar abiertos para permitir una apropiada funcionalidad con Red Hat Network Implementación de los últimos RPM clientes de Red Hat Network El Actualizador de paquete (pup), yum, y Red Hat Network Registration Client (rhn_register) en Red Hat Enterprise Linux 5 (up2date en versiones anteriores a Red Hat Enterprise Linux) son prerrequisitos para utilizar muchas de las funciones empresariales de Red Hat Network. Es importante instalarlos en sistemas de cliente antes de intentar utilizar RHN Proxy Server o RHN Satellite Server en su entorno. Hay varios métodos para abordar la actualización del software cliente RHN. Uno de ellos tiene que ver con el almacenamiento de los RPM en un lugar accesible a todos los sistemas cliente y la implementación de paquetes con el comando más sencillo. En casi todos los casos, la implementación manual de yum, pup, y rhn_register (up2date si existe una versión anterior a Red Hat Enterprise Linux) no es necesaria. Dichas herramientas de cliente no deben tener ningún problema para conectarse al satélite de RHN o su entorno Proxy. La discusión a continuación asume que yum "out of box", pup, y rhn_register (o up2date) no son las últimas y no funcionan para su entorno. Recuerde, únicamente los sistemas que están ejecutando Red Hat Enterprise Linux 5 deben estar registrados con RHN en firstboot después de la instalación o utilizar rhn_register. Los sistemas en ejecutando Red Hat Enterprise Linux 3 y 4 pueden utilizar la función de registro dentro de Red Hat Update Agent. Este documento presupone que el usuario ha instalado al menos un RHN Satellite Server y/o un RHN Proxy Server en su red. El siguiente ejemplo demuestra una manera sencilla de implementar por primera vez yum, pup, y rhn_register (o up2date) por un administrador asumiendo que las máquinas no tienen aún el RHN funcionando. El administrador ha poblado el directorio /var/www/ html/pub/ con una copia de los RPM yum, pup, y rhn_register (o up2date) que los sistemas de cliente necesitan y luego simplemente ha implementado los RPM en los sistemas de cliente con un comando simple rpm -Uvh. Ejecutado desde un cliente, este comando instala los RPM para ese cliente, asumiendo que el nombre de dominio, rutas, y versiones de RPM son correctas (observe que este comando se ha dividido en varias líneas para propósitos de impresión y PDF, pero se debe escribir como una línea en el shell de intérprete de comandos): 3

8 Capítulo 2. Aplicaciones de cliente rpm -Uvh Observe que la arquitectura (en este caso, i386) puede necesitar algunas alteraciones dependiendo del los sistemas que va a servir Configuración de las aplicaciones cliente No todos los usuarios deben estar conectados de forma segura a su RHN Satellite Server o RHN Proxy Server dentro de su organización. No todos los clientes necesitan construir e implementar una llave GPG para los paquetes personalizados. (Estos dos temas se explicarán con más detalle posteriormente). Cada usuario que utilice el servidor satélite de RHN o el RHN Proxy Server debe reconfigurar el Red Hat Update Agent (up2date) y posiblemente el Red Hat Network Registration Client (rhn_register) para redirigirlo desde Red Hat Network a su RHN Satellite Server o RHN Proxy Server. Importante Aunque no sea configurable, observe que el puerto usado por up2date es 80 para HTTP y 443 para secure HTTP (HTTPS). Por defecto, yum en Red Hat Enterprise Linux 5 usa SSL únicamente. Por esta razón, los usuarios deben asegurarse de que sus cortafuegos permitan conexiones al puerto 443. Para desviar u omitir SSL, cambie el protocolo para serverurl desde https a http en /etc/sysconfig/rhn/up2date. Igualmente, para utilizar la función Monitoring de RHN y sondeos que requieren Red Hat Network Monitoring Daemon, observe que los sistemas de cliente deben permitir conexiones en puerto 4545 (o puerto 22, si se utiliza sshd en su lugar). Por defecto, el rhn_register y up2date se refieren a los servidores Red Hat Network principales. Los usuarios deben reconfigurar los sistemas de cliente para referirser a sus RHN Satellite Server o RHN Proxy Server. Observe que las últimas versiones del Red Hat Update Agent pueden ser configuradas para acomodar varios servidores RHN, para así proporcionar protección contra fallos en caso de que el servidor primario sea inaccesible. Consulte la Sección 2.2.4, Implementación del servidor alternativo para obtener instrucciones sobre cómo activar esta función. Las secciones siguientes describen tres métodos para configurar los sistemas de cliente para acceder a su RHN Satellite Server o RHN Proxy Server. Para ver cómo poner virtualmente en script toda la reconfiguración, consulte el Capítulo 6, Creación manual del script de configuración Registro con las llaves de activación Red Hat recomienda el uso de llaves de activación para registrar y configurar los sistemas cliente que se conectan con un RHN Proxy Server o RHN Satellite Server. Las llaves de activación sirven para registrar, autorizar, y suscribir sistemas por lotes. Para mayor información, consulte la sección sobre "llaves de activación" en la Guía de referencia de RHN Satellite Server. El proceso de registro con llaves de activación tiene cuatro pasos básicos: 1. Generar una llave de activación. 2. Importar llaves GPG personales 4

9 Opción up2date --configure 3. Descargar e instalar el RPM del certificado SSL del directorio /pub/ del RHN Proxy Server o servidor satélite de RHN. El comando para este paso es similar a: rpm -Uvh 4. Registrar el sistema con si RHN Proxy Server o servidor satélite de RHN. El comando para este paso es similar a: rhnreg_ks --activationkey mykey --serverurl Alternativamente, la mayoría de los pasos anteriores pueden combinarse en un script de shell que incluya las siguientes líneas (observe que este comando ha sido dividido en varias líneas para propósitos de impresión y PDF, pero debe escribirse en una sola línea en el shell de intérprete de comandos). wget bash && rhnreg_ks --activation-key my_key --serverurl El script bootstrap, generado al momento de la instalación y disponible tanto para el RHN Satellite Server como para el RHN Proxy Server es el script mencionado. La discusión sobre el script y RHN Bootstrap que lo genera se aborda en detalle en el Capítulo 5, Uso de RHN Bootstrap. Advertencia Los sistemas que están ejecutando Red Hat Enterprise Linux 2.1 y versiones de Red Hat Linux anteriores a la 8.0 pueden experimentar problemas al usar las llaves de activación para migrar la configuración del certificado SSL de rhn_register a up2date. Por lo cual, la información del certificado SSL en esos sistemas debe ser establecida manualmente. Todas las otras transferencias de parámetros, como la URL del servidor, funcionan correctamente Opción up2date --configure Red Hat Update Agent en Red Hat Enterprise Linux 3 y 4 proporciona una interfaz para establecer varias configuraciones. Para ver una lista completa de estas configuraciones, consulte la página de manual up2date (man up2date en la línea de comandos). Para reconfigurar el Red Hat Update Agent, ejecute el siguiente comando como root: up2date --configure Se le presentará una caja de diálogo con varios parámetros que pueden ser reconfigurados. En la pestaña General, bajo Seleccionar servidor de Red Hat Network a utilizar remplace el valor por defecto con su nombre de dominio completamente calificado (FQDN) del RHN Satellite Server o el RHN Proxy Server, tal como XMLRPC. Mantenga el /XMLRPC al final. Al finalizar, haga clic en OK. 5

10 Capítulo 2. Aplicaciones de cliente Figura 2.1. Configuración de la interfaz gráfica de usuario Red Hat Update Agent Asegúrese de haber introducido el nombre de dominio correcto de su RHN Satellite Server o RHN Proxy Server. La introducción incorrecta de un nombre de dominio o si se deja el campo vacío, prevendrá que se lance up2date --configure. Sin embargo, puede esto se puede solucionar al editar el valor en el archivo de configuración up2date. Consulte la Sección 2.2.3, Actualización manual de los archivos de configuración para obtener instrucciones precisas. Advertencia Sistemas ejecutando Red Hat Enterprise Linux 3 o 4 tienen incorporada la función de registro Red Hat Update Agent y por lo tanto no se necesita instalar Red Hat Network Registration Client. Los sistemas ejecutando Red Hat Enterprise Linux 5 no usan up2date, y necesitan rhn_register para registrar sus sistemas a RHN o Satélite y yum y pup para actualizar sus paquetes Actualización manual de los archivos de configuración Como una alternativa a la interfaz GUI descrita en la sección anterior, los usuarios pueden también reconfigurar Red Hat Update Agent al editar los archivos de configuración de la aplicación. Para configurar el Red Hat Update Agent en los sistemas cliente que se conectan a un RHN Proxy Server o un servidor satélite de RHN, edite como root los valores de los parámetros serverurl y nosslserverurl en el archivo de configuración /etc/sysconfig/rhn/up2date. Remplace el valor predeterminado de la URL de Red Hat Network con el nombre de dominio completamente calificado (FQDN) del RHN Proxy Server o el servidor satélite de RHN. Por ejemplo: 6

11 Implementación del servidor alternativo serverurl[comment]=remote server URL serverurl= nosslserverurl[comment]=remote server URL without SSL nosslserverurl= Advertencia El parámetro httpproxy en /etc/sysconfig/rhn/up2date no hace referencia al RHN Proxy Server. Sirve para configurar un proxy HTTP opcional para el cliente. Con un RHN Proxy Server en lugar, el parámetro httpproxy debe estar en blanco (no debe tener ningún valor establecido) Implementación del servidor alternativo Desde up2date , el Red Hat Update Agent puede ser configurado para buscar actualizaciones desde una serie de servidores RHN. Esto puede ser bastante útil para mantener el abastecimiento de actualizaciones en caso de que su RHN Proxy Server o su servidor satélite de RHN primario estén desconectados. Para usar esta función, asegúrese de estar usando la versión requerida del up2date. Luego añada como root los servidores secundarios a los parámetros serverurl y nosslserverurl en el archivo de configuración /etc/sysconfig/rhn/up2date. Añada los nombres de dominio completamente calificado (FQDN) del Proxy o el satélite inmediatamente después del servidor primario, separados por puntos y comas (;). Por ejemplo: serverurl[comment]=remote server URL serverurl= nosslserverurl[comment]=remote server URL without SSL nosslserverurl= La conexión al servidor se intenta según el orden provisto aquí. Puede incluir tantos servidores como desee. Puede también incluir los servidores centrales de RHN. Esto solo funciona, si los sistemas clientes tienen acceso directo a la Internet Programa actualizador de paquetes Red Hat Enterprise Linux 5 ofrece un programa de ejecución en el panel gráfico de escritorio que periódicamente busca actualizaciones desde el servidor de RHN o Satélite y alerta a los usuarios cuando hay una nueva actualización disponible. 7

12 Capítulo 2. Aplicaciones de cliente Figura 2.2. Programa actualizador de paquetes La aplicación del programa actualizador de paquetes permanece en la bandeja de notificaciones del panel de escritorio y busca periódicamente nuevas actualizaciones. La aplicación también permite realizar tareas de mantenimiento de paquetes haciendo clic y eligiendo dentro de las siguientes acciones: Refresh Busca nuevas actualizaciones de RHN o Satélite View Updates lanza la aplicación de actualizador de paquetes para que se puedan ver detalladamente las actualizaciones disponibles y configurar las actualizaciones para sus especificaciones. Apply Updates Descarga e instala todos los paquetes actualizados. Quit cierra la aplicación 2.4. Configuración de la Red Hat Network Alert Notification Tool con Satélite. La Red Hat Network Alert Notification Tool, el icono circular en el panel de su escritorio Red Hat Enterprise Linux 3 o 4, puede configurarse en sistemas que ejecutan Red Hat Enterprise Linux 3 o posteriores para que reconozcan actualizaciones disponibles en los canales personalizados en su RHN Satellite Server. Debe asegurarse de que el RHN Satellite Server esté configurado para soportar esta función. (RHN Proxy Server soporta la aplicación sin modificación de cliente o servidor.) Los pasos para configurar la Red Hat Network Alert Notification Tool son los siguientes: 1. Asegúrese de que la versión de su RHN Satellite Server sea 3.4 o superior y de que el paquete rhns-applet esté instalado en el satélite. El paquete puede encontrarse en el canal de software del satélite de RHN para las versiones 3.4 y posteriores. 2. Obtenga el paquete rhn-applet-actions con up2date o a través del canal de herramientas de software Red Hat Network. Instale el paquete en todos los sistemas de cliente Red Hat Enterprise Linux 3 y posteriores para ser notificado de actualizaciones personalizadas con los sistemas de cliente Red Hat Network Alert Notification Tool. Los sistemas de cliente deben estar actualizados para los niveles de servicio Management o Provisioning. 3. Dentro de la versión del satélite del sitio web de RHN, vaya a la página Información del sistema para cada sistema cliente y haga clic en el enlace dentro del área RHN Applet para redirigir la Red Hat Network Alert Notification Tool al satélite. La próxima vez que la aplicación sea iniciada, se aplicará la nueva configuración y la conexión para actualizaciones se realizará al RHN Satellite Server. 8

13 Infraestructura del SSL Para los usuarios de Red Hat Network, la seguridad es un tema de suma importancia. Una de las fortalezas de Red Hat Network es la habilidad de procesar cada una de las solicitudes a través de SSL (Secure Sockets Layer). Para mantener este nivel de seguridad, los usuarios que instalan Red Hat Network dentro de sus infraestructuras deben generar las llaves y certificados SSL personalizados. La creación e implementación manual de las llaves y certificados SSL puede llegar a ser bastante engorrosa. Tanto el RHN Proxy Server como el servidor satélite de RHN le permitirán construir sus propias llaves y certificados SSL durante la instalación, basándose en sus propios certificados de Autoridad Certificadora (conocidos como CA por sus siglas en inglés). Además, una herramienta para la línea de comando, la RHN SSL Maintenance Tool, ha sido creada para este fin. Estas llaves y certificados deben ser implementados en todos los sistemas dentro de su infraestructura. En muchos casos, la implementación de estas llaves y certificados SSL es automatizada. Este capítulo describe métodos eficientes para conducir todas estas tareas. Por favor tenga en cuenta que este capítulo no explica SSL en detalle. La RHN SSL Maintenance Tool fue diseñada para ocultar la complejidad que envuelve la creación y mantenimiento de esta infraestructura de llaves públicas (PKI). Para mayor información, consulte algunas de las referencias disponibles en la librería más cercana Una breve introducción al SSL SSL, por Secure Sockets Layer, es un protocolo que permite a los clientes pasar información de una forma segura. SSL utiliza un sistema de pares de llaves pública y privada para encriptar la comunicación pasada entre el cliente y el servidor. Los certificados públicos pueden ser accesibles a cualquier persona, pero las llaves privadas deben permanecer en un lugar seguro. Es la relación matemática (una firma digital) entre el certificado público y la llave privada lo que hace que este sistema funcione. A través de esta relación se establece una conexión confiable. Nota A lo largo de este documento se discutirá sobre las llaves privadas y los certificados públicos de SSL. Técnicamente, ambos pueden llamarse llaves (pública y privada). Pero por convención, cuando se habla de SSL, se refiere a la parte pública de un par de llaves de SSL (o juego de llaves) como el certificado público SSL. La infraestructura SSL de una organización está conformada generalmente por estas llaves y certificados: Llave privada y certificado público SSL de Autoridad certificadora (CA) generalmente se crea un solo par por organización. El certificado público es firmado digitalmente por su llave privada. El certificado público se distribuye a cada sistema. Llaves privadas y certificados públicos SSL del servidor web un set por servidor de aplicaciones. El certificado público es firmado digitalmente tanto por su llave privada como por su llave privada CA SSL. Generalmente nos referimos al juego de llaves del servidor web; ya que hay una petición a un certificado SSL intermediario que es generado. Los detalles de uso no son importante en esta discusión. Todos los tres son implementados en un servidor de RHN. Por ejemplo: si tiene un satélite y cinco Proxies, generará un par de llaves CA SSL y seis juegos de llaves SSL del servidor web. El certificado público CA SSL es distribuido a todos los sistemas y usado 9

14 Capítulo 3. Infraestructura del SSL por todos los clientes para establecer una conexión a sus respectivos servidores. Cada servidor tiene su propio juego de llaves SSL que está específicamente ligado al nombre de host del servidor y generado con la llave privada SSL y la llave privada CA SSL en conjunto. Esto establece una asociación digital verificable entre el certificado público SSL del servidor web y el par de llaves CA SSL y la llave privada del servidor. El juego de llaves del servidor de web no puede ser compartido con otros servidores. Importante La parte más crítica de este sistema es el par de llaves CA SSL. Desde esa llave privada y el certificado público un administrador puede regenerar cualquier juego de llaves SSL del servidor web. Este par de llaves CA SSL debe guardarse en un lugar seguro. Se recomienda que una vez la infraestructura de servidores RHN esté configurada y en ejecución, usted archive el directorio SSL creado generado por esta herramienta y/o el instalador en un medio independiente, escriba la contraseña CA y guarde el medio y la contraseña en un lugar seguro Uso de RHN SSL Maintenance Tool Red Hat Network proporciona una herramienta de la línea de comandos para administrar de una manera fácil la infraestructura de seguridad: La RHN SSL Maintenance Tool comúnmente conocida por su comando rhn-ssl-tool. Esta herramienta está disponible como parte del paquete rhnscerts-tools. Este paquete puede encontrarse dentro de los canales de software para las últimas versiones del RHN Proxy Server y el servidor satélite de RHN (también para el ISO del servidor satélite de RHN). La RHN SSL Maintenance Tool le permite generar su propio par de llaves CA SSL, así como el juego de llaves SSL del servidor web (algunas veces llamada par de llaves). Esta herramienta es solamente una herramienta de construcción. Genera todas las llaves y certificados SSL que se requieren. También empaqueta los archivos en formato RPM para una rápida distribución e instalación de las máquinas cliente. Sin embargo, no las implementa. Esta tarea es asignada al administrador, o en muchas ocasiones, automatizada por el RHN Satellite Server. Nota El rhns-certs-tools, que contiene rhn-ssl-tool, puede ser instalado y ejecutado en cualquier sistema Red Hat Enterprise Linux con los mínimos requerimientos. Esto es conveniente para los administradores que deseen manejar su infraestructura SSL desde su estación de trabajo o cualquier otro sistema diferente al servidor RHN. Estos son los casos en los que se requiere la herramienta: Cuando se actualizan los certificados públicos CA - esto es raro. Cuando se instala un RHN Proxy Server versión 3.6 o posterior que se conecta con los servidores centrales de RHN como su servicio de nivel superior - el servicio hospedado, por razones de seguridad, no puede ser un repositorio de su certificado y llave CA SSL, los cuales son privativos de su organización. Cuando se reconfigura una infraestructura RHN para usar SSL donde no existía. Cuando se añade algún RHN Proxy Server de una versión anterior a la 3.6 dentro de su infraestructura RHN. 10

15 Explicación de la generación de SSL Cuando se añade más de un RHN Satellite Server a una infraestructura RHN - consulte con su representante Red Hat para obtener instrucciones al respecto. Estos son los casos en los que no se requiere la herramienta: Durante la instalación de un RHN Satellite Server - todos los parámetros SSL son configurados durante el proceso de instalación. Las llaves y certificados SSL son construidos e implementados automáticamente. Durante la instalación de un RHN Proxy Server versión 3.6 o superior conectado a un servidor satélite de RHN 3.6 o superior como su servidor de nivel superior - el servidor satélite de RHN contiene toda la información SSL necesaria para configurar, construir e implementar los certificados y llaves SSL del RHN Proxy Server. El proceso de instalación del RHN Satellite Server y del RHN Proxy Server aseguran que el certificado público SSL sea implementado en el directorio /pub de cada servidor. Este certificado público es usado por los sistemas cliente para conectarse a los servidores RHN. Consulte la Sección 3.3, Implementación del certificado público CA SSL a los clientes para obtener mayor información. En resumen, si la infraestructura RHN de su organización implementa la última versión del RHN Satellite Server como el servicio de nivel superior, usted no tendrá necesidad de usar la herramienta. De lo contrario, deberá familiarizarse con su uso Explicación de la generación de SSL Seguridad, flexibilidad y portabilidad son los beneficios primarios del uso de la RHN SSL Maintenance Tool. La seguridad se consigue mediante la creación de certificados y llaves SSL del servidor web para cada servidor de RHN, todos firmados por un único par de llaves CA SSL creado por su organización. La flexibilidad se consigue gracias a la posibilidad de ejecutar la herramienta en cualquier máquina que tenga el paquete rhns-certs-tools instalado. La portabilidad nace en la existencia de una estructura construida que puede ser almacenada por seguridad en cualquier lugar y luego instalada cuando sea necesario. Nuevamente, si su infraestructura RHN utiliza la última versión del RHN Satellite Server como servidor de nivel superior, lo único que usted tendrá que hacer es restaurar su árbol ssl-build desde un archivo al directorio /root y utilizar las herramientas de configuración provistas dentro del sitio web del RHN Satellite Server. Para Utilizar la RHN SSL Maintenance Tool de la forma más adecuada, complete las siguientes tareas de nivel superior siguiendo aproximadamente el orden dado. Consulte las secciones restantes para obtener mayor información: 1. Instale el paquete rhns-certs-tools en un sistema dentro de su organización; por ejemplo en un RHN Satellite Server o un RHN Proxy Server. 2. Cree un par de llaves CA SSL para su organización e instale el RPM resultante o certificado público en todos los sistemas cliente. 3. Cree un juego de llaves SSL de servidor web para cada uno de los Proxies y satélites que serán implementados e instale los RPM resultantes en los servidores de RHN; reinicie el servicio httpd después de esta acción: /sbin/service httpd restart 11

16 Capítulo 3. Infraestructura del SSL 4. Archive el árbol de construcción SSL - conformado por el directorio de construcción primario y todos los subdirectorios y archivos - en un medio de almacenamiento, por ejemplo un disquete (los requerimientos de espacio de disco son insignificantes). 5. Verifique y luego almacene este archivo en un lugar seguro, tal como el descrito en la sección sobre copias de seguridad en Requerimientos adicionales de la Guía de instalación de Proxy o satélite. 6. Registre y asegure la contraseña CA para un uso futuro. 7. Borrar el árbol de construcción del sistema donde fue construido por razones de seguridad, pero únicamente después de que la infraestructura RHN ha sido establecida y esté configurada. 8. Cuando se necesiten llaves SSL de servidor web adicionales, restaure el árbol de construcción en el sistema ejecutando la RHN SSL Maintenance Tool y repita los pasos del 3 al Opciones de RHN SSL Maintenance Tool La RHN SSL Maintenance Tool ofrece una cantidad de opciones para la línea de comandos para generar su par de llaves CA SSL y administrar sus llaves y certificados SSL del servidor. La herramienta ofrece esencialmente tres opciones de listas de ayudas para la línea de comando: rhnssl-tool --help (general), rhn-ssl-tool --gen-ca --help (CA - Certificate Authority), y rhn-ssl-tool --gen-server --help (Servidor web). Las dos tablas siguientes dividen las opciones de acuerdo a su tarea respectiva, ya sea CA o la generación del juego de llaves de servidor web. Este conjunto de opciones debe estar precedido por el argumento --gen-ca: Tabla 3.1. Opciones SSL de Autoridad certificadora (CA) (rhn-ssl-tool --gen-ca --help) Opción --gen-ca -h, --help -f, --force -p=, --password=contraseña Descripción Genera un par de llaves CA (Autoridad certificadora) y RPM público. Este debe ser ejecutado con cualquiera de las opciones restantes de la tabla. Muestra la pantalla de ayuda con una lista de opciones básicas específicas para generar y administrar un CA (Autoridad certificadora). Fuerza la creación de una llave privada CA y/o de un certificado público. La contraseña CA. Se le pedirá que introduzca esta opción si no se encuentra. Guárdela de una forma segura. -d=, --dir=directorio Requerido para la mayoría de comandos - El directorio donde el certificado y el RPM serán construidos. Por defecto es./sslbuild. --ca-key=archivo El nombre del archivo de la llave privada CA. Por defecto es RHN-ORG-PRIVATE- SSL-KEY. 12

17 Opciones de RHN SSL Maintenance Tool Opción --ca-cert=archivo --cert-expiration=expir_cert --set-country=código_país --set-state=estado_o_provincia --set-city=ciudad_o_localidad --set-org=organización --set-org-unit=config_unidad_org --set-common-name=nombredehost --set- =correo-e --rpm-packager=empaquetador --rpm-vendor=distribuidor -v, --verbose --ca-cert-rpm=cert_rpm --key-only --cert-only --rpm-only Descripción El nombre del archivo del certificado público CA. Por defecto es RHN-ORG- TRUSTED-SSL-CERT. La fecha de caducidad del certificado público CA. Por defecto es el número de días hasta un día antes del cambio de época (o ). El código de dos letras del país. Por defecto es US. El estado o provincia del CA. Por defecto es ''. La ciudad o localidad. Por defecto es ''. La compañía u organización, tal como Red Hat. Por defecto es Example Corp. Inc. La unidad corporativa, tal como RHN. Por defecto es ''. Generalmente no se establece para el CA. - El nombre común. Generalmente no se establece para el CA. - dirección de correo-e. Empaquetador del RPM generado, tal como "RHN Admin (rhnadmin@example.com)." El distribuidor del RPM generado, tal como "IS/IT Example Corp." Muestra mensajes verbosos. Esta opción es acumulativa - por cada "v" añadida se conseguirá un mayor grado de verbosidad. Rara vez cambia - el nombre del RPM que contiene el certificado CA (El nombre de archivo base únicamente, no el nombre que incluye la versión: filename-versionrelease.noarch.rpm) Rara vez usado - Genera una llave privada CA únicamente. Revise --gen-ca -- key-only --help para obtener mayor información. Rara vez usado - Genera un certificado público CA únicamente. Revise --genca --cert-only --help para obtener mayor información. Rara vez usado - Genera un RPM para implementación solamente. Revise -- gen-ca --rpm-only --help para obtener mayor información. 13

18 Capítulo 3. Infraestructura del SSL Opción --no-rpm Descripción Rara vez usado - Realiza todos los pasos relacionados con el CA excepto la generación del RPM. El siguiente set de opciones debe estar precedido de un argumento --gen-server: Tabla 3.2. Opciones del SSL de servidor web (rhn-ssl-tool --gen-server --help) Opción --gen-server -h, --help -p=, --password=contraseña Descripción Genera el juego de llaves SSL de servidor web, el RPM y el archivo tar. Esta opción debe ser usada con cualquiera de las opciones restantes de esta tabla. Muestra la pantalla de ayuda con una lista de opciones básicas especificas para la generación y administración de un par de llaves de servidor. La contraseña CA. Se le pedirá que introduzca esta opción si no se encuentra. Guárdela de una forma segura. -d=, --dir=directorio Requerido para la mayoría de comandos - El directorio donde el certificado y el RPM serán construidos. Por defecto es./sslbuild. --server-key=archivo --server-cert-req=archivo --server-cert=archivo --startdate=yymmddhhmmssz --cert-expiration=expir_cert_servidor --set-country=código_país --set-state=estado_o_provincia --set-city=ciudad_o_localidad El nombre del archivo de la llave privada SSL de servidor web. Por defecto es server.key. El nombre de archivo solicitado del certificado SSL de servidor web. Por defecto es server.csr. El nombre de archivo del certificado SSL del servidor web. Por defecto es server.crt. La fecha de inicio para validar el certificado de servidor en el formato ejemplificado: año, mes, día, hora, minuto, segundo (dos caracteres por valor). Z significa Zulú y es requerido. Por defecto es una semana antes de la generación. La fecha de caducidad del certificado de servidor. Por defecto es el número de días hasta un día antes del cambio de época (o ). El código de dos letras del país. Por defecto es US. El estado o provincia. Por defecto es "North Carolina". La ciudad o localidad. Por defecto es Raleigh. 14

19 Opciones de RHN SSL Maintenance Tool Opción --set-org=organización --set-org-unit=config_unidad_org --set-hostname=nombredehost --set- =correo-e --rpm-packager=empaquetador --rpm-vendor=distribuidor -v, --verbose --key-only --cert-req-only --cert-only --rpm-only --no-rpm --server-rpm=servidor_rpm --server-tar=servidor_tar Descripción La compañía u organización, tal como Red Hat. Por defecto es Example Corp. Inc. La unidad corporativa, tal como RHN. Por defecto es "unit." El nombre de host del servidor de RHN que recibirá la llave. Por defecto se establece dinámicamente con el nombre de host de la máquina de construcción. La dirección de correo-e del contacto del certificado. Por defecto es admin@example.corp. Empaquetador del RPM generado, tal como "RHN Admin (rhnadmin@example.com)." El distribuidor del RPM generado, tal como "IS/IT Example Corp." Muestra mensajes verbosos. Esta opción es acumulativa - por cada "v" añadida se conseguirá un mayor grado de verbosidad. Rara vez usado - Genera únicamente una llave privada de servidor. Revise --genserver --key-only --help para obtener mayor información. Rara vez usado - Genera únicamente una petición de certificado de servidor. Revise --gen-server --cert-req-only -- help para mayor información. Rara vez usado - Genera únicamente un certificado de servidor. Revise --genserver --cert-only --help para obtener mayor información. Rara vez usado - Genera únicamente un RPM para implementación. Revise -- gen-server --rpm-only --help para obtener mayor información. Rara vez usado - Ejecuta todos los pasos relacionados con el servidor excepto la generación del RPM. Rara vez cambiado - El nombre del RPM que contiene el juego de llaves SSL del servidor web (el nombre de archivo base, no el nombre de archivo y versión: filename-version-release.noarch.rpm). Rara vez se cambia - Nombre del archivo tar del juego de llaves SSL de servidor web y certificado CA que es utilizado únicamente por las rutinas de instalación 15

20 Capítulo 3. Infraestructura del SSL Opción Descripción del RHN Proxy Server hospedado (el nombre de archivo de base no el nombre y versión: filename-version-release.tar) Generación del par de llaves CA SSL. Antes de crear el juego de llaves del servidor web, usted debe generar un par de llaves SSL de Autoridad certificadora (CA). Un certificado público CA SSL se distribuye a los sistemas cliente del satélite o del Proxy. La RHN SSL Maintenance Tool le permitirá generar un par de llaves CA SSL cuando sea necesario y reutilizarlas para todas las implementaciones de servidores de RHN posteriores. El proceso de construcción crea automáticamente el par de llaves y el RPM público para ser distribuido a los sistemas cliente. Todos los componentes terminan en el directorio de construcción especificado en la línea de comandos, generalmente /root/ssl-build (o /etc/sysconfig/ rhn/ssl para satélites y Proxies antiguos). Para generar un par de llaves CA SSL, ejecute un comando como el siguiente: rhn-ssl-tool --gen-ca --password=my_ca_password --dir="/root/ssl-build" \ --set-state="north Carolina" --set-city="raleigh" --set-org="example Inc." \ --set-org-unit="ssl CA Unit" Remplace los valores de este ejemplo con los de su organización. Esto dará como resultado los siguientes archivos relevantes en el directorio de construcción especificado: RHN-ORG-PRIVATE-SSL-KEY la llave privada CA SSL RHN-ORG-TRUSTED-SSL-CERT El certificado público CA SSL rhn-org-trusted-ssl-cert-vers-lanzamiento.noarch.rpm El RPM preparado para ser distribuido a los sistemas cliente. Contiene el certificado público CA SSL y lo instala en: /usr/ share/rhn/rhn-org-trusted-ssl-cert rhn-ca-openssl.cnf el archivo de configuración CA SSL latest.txt siempre lista la versión más reciente de los archivos pertinentes. Una vez finalizado, usted podrá distribuir el RPM a los sistemas cliente. Consulte la Sección 3.3, Implementación del certificado público CA SSL a los clientes Generación del juego de llaves SSL del servidor web Aunque debe generar un par de llaves CA SSL, es probable que usted genere el juego de llaves del servidor web con mayor frecuencia, especialmente si se está implementando más de un Proxy o satélite. Observe que el valor de --set-hostname es diferente para cada servidor. En otras palabras, un juego único de llaves y certificados SSL debe ser generado e instalado por cada nombre de host de servidor RHN. El proceso de construcción del certificado de servidor funciona de un modo muy similar al usado para generar el par de llaves CA SSL. Hay, sin embargo, una excepción: todos los componentes del servidor terminan en subdirectorios del directorio creado que indican el nombre de la máquina del sistema creado, tal como /root/ssl-build/nombre_maquina. Para generar certificados de servidor, ejecute un comando similar al siguiente: 16

21 Implementación del certificado público CA SSL a los clientes rhn-ssl-tool --gen-server --password=my_ca_password --dir="/root/ssl-build" \ --set-state="north Carolina" --set-city="raleigh" --set-org="example Inc." \ --set-org-unit="is/it" --set- ="admin@example.com" \ --set-hostname="rhnbox1.example.com Remplace los valores del ejemplo con aquellos apropiados para su organización. Como resultado se obtendrán los siguientes archivos relevantes en el subdirectorio específico a la máquina en el directorio de construcción: server.key la llave de servidor privada SSL de servidor web. server.csr la petición de certificado SSL de servidor web. server.crt el certificado público SSL de servidor web. rhn-org-httpd-ssl-key-pair-nom-vers-lanz_máquina.noarch.rpm el RPM preparado para ser distribuido a los servidores de RHN. También se genera el archivo src.rpm asociado. Este RPM contiene los siguientes tres archivos. Se instalarán en estos lugares: /etc/httpd/conf/ssl.key/server.key /etc/httpd/conf/ssl.csr/server.csr /etc/httpd/conf/ssl.crt/server.crt rhn-server-openssl.cnf el archivo de configuración SSL de servidor web latest.txt siempre lista la versión más reciente de los archivos pertinentes. Una vez finalizado, usted podrá distribuir e instalar el RPM en los respectivos servidores de RHN. Observe que el servicio httpd debe ser reiniciado después de la instalación: /sbin/service httpd restart 3.3. Implementación del certificado público CA SSL a los clientes Tanto el proceso de instalación del RHN Proxy Server como del servidor satélite de RHN facilitan relativamente la implementación de los sistemas cliente al generar el RPM y el certificado público CA SSL. Ambos procesos de instalación dejan a disposición pública una copia del RPM y/o del certificado en el directorio /var/www/html/pub/ del servidor RHN. Este directorio público puede ser fácilmente inspeccionado a través del navegador de web: proxy-or-sat.example.com/pub/. El certificado público CA SSL en ese directorio puede ser descargado a un sistema cliente mediante wget o curl. Por ejemplo: curl -O wget Alternativamente, si el RPM del certificado público CA SSL está en el directorio /pub, puede ser instalado en un sistema cliente directamente: 17

22 Capítulo 3. Infraestructura del SSL rpm -Uvh \ Confirme el nombre real del certificado o RPM antes de ejecutar este comando Configuración de los sistemas cliente Una vez el RPM o certificado crudo ha sido implementado al sistema cliente, el administrador de ese sistema debe modificar el archivo de configuración del Red Hat Update Agent y el Red Hat Network Registration Client (de ser necesario) para usar el nuevo archivo de certificado CA SSL y para conectarse al RHN Proxy Server o el servidor satélite de RHN apropiado. El lugar generalmente aceptado para el certificado público CA SSL es el directorio /usr/share/rhn. El RHN Proxy Server y el servidor satélite de RHN tienen la aplicación RHN Bootstrap instalada por defecto, lo cual puede reducir en gran medida estos pasos repetitivos y simplificar el proceso de registro y configuración de sistemas cliente. Por favor consulte el Capítulo 5, Uso de RHN Bootstrap para obtener mayor información. 18

23 Importación de las llaves GPG personalizadas Para los usuarios que desean construir y distribuir sus propios RPM de una forma segura, se recomienda que todos los RPM personalizados estén firmados con GPG (GNU Privacy Guard). La generación y construcción de llaves GPG y la construcción de paquetes firmados con GPG se tratan en la Guía de administración de canales de Red Hat Network. Una vez el paquete haya sido firmado, la llave pública puede ser implementada en todos los sistemas que reciben esos RPM. Esta tarea tiene dos pasos: primero, crear una ubicación central para la llave pública con el fin de que los clientes puedan obtenerla; y segundo, añadir la llave al llavero de GPG local para cada sistema. El primer paso es común y puede ser manejado mediante el método recomendado para implementar aplicaciones cliente de RHN a través del sitio web. (Consulte la Sección 2.1, Implementación de los últimos RPM clientes de Red Hat Network.). Para llevar a cabo este procedimiento, cree un directorio público en el servidor web y coloque en él la firma pública GPG: cp /some/path/your-rpm-gpg-key /var/www/html/pub/ La llave puede ser descargada desde los sistemas cliente mediante wget: wget -O- -q La opción -O- envía los resultados a la salida estándar mientras que la opción -q activa el modo silencioso en wget. No olvide remplazar la variable SU-LLAVE-GPG-RPM por el nombre de archivo de su llave. Una vez la llave está disponible en el sistema de archivos del sistema cliente, impórtela al llavero de GPG local. Sistemas operativos diferentes requieren diferentes métodos. Para Red Hat Enterprise Linux 3 o superior, utilice el siguiente comando: rpm --import /path/to/your-rpm-gpg-key Para Red Hat Enterprise Linux 2.1, use el siguiente comando: gpg $(up2date --gpg-flags) --import /path/to/your-rpm-gpg-key Una vez la llave GPG ha sido exitosamente añadida al cliente, el sistema debe estar en la capacidad de validar RPM personalizados firmados con la llave correspondiente. 19

24 20

25 Uso de RHN Bootstrap Red Hat Network proporciona una herramienta que automatiza muchos de los pasos de la reconfiguración manual descrita en los capítulos previos: RHN Bootstrap. Esta herramienta juega un rol integral en el Programa de instalación del servidor satélite de RHN, permitiendo la generación del script bootstrap durante la instalación. Los usuarios del RHN Proxy Server y aquellos con la configuración actualizada del satélite requieren una herramienta bootstrap que pueda ser usada independientemente. RHN Bootstrap, la cual se invoca con el comando /usr/bin/rhn-bootstrap, está diseñada para cumplir esta tarea y viene instalada por defecto tanto en el servidor satélite de RHN como en el RHN Proxy Server. Si se utiliza correctamente, el script generado por esta herramienta puede ser ejecutado desde cualquier sistema para realizar las siguientes tareas: Redirigir aplicaciones cliente al Proxy o satélite de RHN Importar llaves GPG personalizadas Instalar certificados SSL Registrar el sistema a RHN y a los grupos de sistemas y canales particulares con ayuda de las llaves de activación. Realizar diferentes actividades posteriores a la instalación, incluyendo la actualización de paquetes, ejecución de reinicios y la modificación de la configuración de RHN. Los usuarios deben tener en cuenta, sin embargo, los riesgos inherentes de la utilización de un script para llevar a cabo la configuración. Las herramientas de seguridad, como los certificados SSL, son instaladas por el mismo script; por lo cual no existen aún y no sirven para procesar transacciones. Esto conlleva a la posibilidad de que alguien se haga pasar por el satélite y envíe datos nocivos. El uso de los cortafuegos del usuario y el hecho de que tanto el satélite como todos los sistemas cliente están restringidos de tráfico exterior mitiga este problema. El proceso de registro se lleva a cabo a través de SSL, siendo así protegido. El script bootstrap bootstrap.sh se ubica automáticamente en el directorio /var/www/html/ pub/bootstrap/ del servidor de RHN. Desde allí puede ser descargado y ejecutado en todos los sistemas cliente. Observe que es necesario una preparación previa y una edición tras la generación del script, tal y como se muestra en las siguientes secciones. Consulte la Sección 5.4, Opciones de RHN Bootstrap para ver la lista completa de opciones de la herramienta. Finalmente, consulte el Apéndice A, Script de ejemplo Bootstrap para ver un ejemplo Preparación Ya que RHN Bootstrap (rhn-bootstrap) depende de otros componentes de la infraestructura de Red Hat Network para configurar apropiadamente los sistemas cliente, esos componentes deben prepararse antes de la generación del script. La siguiente lista identifica las medidas iniciales que se deberían tomar: Generar las llaves de activación que serán llamadas por el script. Las llaves de activación sirven para registrar sistemas Red Hat Enterprise Linux, concederles derechos a uno de los niveles de servicio RHN y suscribirlos a un canal y grupo de sistemas específico. Todo ello en tan solo una acción. Tenga en cuenta que debe tener derechos Management disponibles para usar una llave de activación, mientras que la inclusión de múltiples llaves de activación requiere derechos Provisioning. Genere las llaves de activación a través de la página Llaves de activación dentro de la categoría Sistemas del sitio web de RHN (ya sean los servidores centrales de RHN para el 21

26 Capítulo 5. Uso de RHN Bootstrap Proxy o el nombre de dominio completamente calificado del satélite). Consulte los capítulos sobre el Red Hat Update Agent y el sitio web de RHN en la Guía de referencia de RHN para instrucciones sobre creación y uso. Red Hat le recomienda firmar sus RPM con una llave GPG (GNU Privacy Guard) personalizada. La llave debe estar disponible para que el script pueda referirse a ella. Genere la llave tal y como se describe en la Guía de administración de canales de RHN y ubíquela en el directorio /var/ www/html/pub/ del servidor de RHN, consulte el Capítulo 4, Importación de las llaves GPG personalizadas. Si desea utilizar el script para implementar su certificado público CA SSL, tenga disponible el certificado o el paquete RPM que lo contiene en el servidor de RHN e inclúyalo durante la generación del script con la opción --ssl-cert. Consulte el Capítulo 3, Infraestructura del SSL para obtener mayor información. Tenga los valores a mano para desarrollar uno o más script bootstrap, dependiendo de la variedad de sistemas a ser reconfigurados. Ya que RHN Bootstrap, proporciona un conjunto completo de opciones de reconfiguración, puede usarlas para generar diferentes script bootstrap para acomodar cada tipo de sistemas. Por ejemplo, bootstrap-web-servers.sh puede servir para reconfigurar los servidores de web y bootstrap-app-servers.sh puede manejar el servidor de aplicaciones. Consulte la Sección 5.4, Opciones de RHN Bootstrap. para obtener una lista completa de opciones Generación Ahora que todos los componentes necesarios están en su lugar, puede usar RHN Bootstrap para generar los scripts requeridos. Inicie una sesión como root en su servidor satélite de RHN o RHN Proxy Server y ejecute el comando rhn-bootstrap seguido por las opciones y valores deseados. Si no se incluye ninguna opción, se creará un archivo bootstrap.sh en el subdirectorio bootstrap/ que contiene los valores esenciales derivados del servidor, incluyendo el nombre de host, el certificado SSL, las configuraciones SSL y GPG, si éstas existen, y una llamada al archivo client-config-overrides.txt. Como mínimo, Red Hat recomienda que su script contenga también las llaves de activación, llaves GPG y opciones avanzadas de configuración de la siguiente manera: Utilice la opción --activation-keys para incluir las llaves, teniendo en cuenta los derechos requeridos señalados en la Sección 5.1, Preparación. Utilice la opción --gpg-key para identificar la ruta de la llave y el nombre del archivo durante la generación del script. De lo contrario, utilice la opción --no-gpg para desactivar esta verificación en los sistemas cliente. Red Hat le recomienda retener esta medida de seguridad. Incluya la opción --allow-config-actions para habilitar la administración de configuración remota en todos los sistemas cliente influenciados por el script. Esta función es útil para reconfigurar varios sistemas simultáneamente. Incluya la opción --allow-remote-commands para habilitar el uso de scripts remotos en todos los sistemas cliente. Como la administración de configuración, esta función facilita la reconfiguración simultánea de varios sistemas. Al finalizar, su comando se verá así: rhn-bootstrap --activation-keys KEY1,KEY2 \ --gpg-key /var/www/html/pub/my_corporate_public_key \ 22