 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Introducción
Si quieres utilizar la interfaz web de Checkmk a través de HTTPS, tendrás que configurar lo siguiente en tu servidor de monitorización, independientemente de tus sitios:
El módulo de Apache
mod_sslestá instalado y activado.Los módulos de Apache
mod_rewriteymod_headersestén presentes y también activados.Tienes un certificado de servidor válido.
Se puede acceder al servidor a través de HTTPS.
Este artículo explica todo lo que se necesita para lograr dicha configuración.
2. Activación de los módulos de Apache
El acceso HTTPS a la interfaz de Checkmk requiere el módulo de Apache mod_ssl.
Además, en el resto de la configuración, asumimos que una conexión entrante por el puerto no cifrado 80 debe redirigirse al puerto cifrado con SSL 443.
Para ello se necesita el módulo mod_rewrite.
Por último, se necesita mod_headers para que el Apache accesible desde el exterior, configurado como proxy inverso, reenvíe los encabezados de las solicitudes al Apache del site.
Puedes ver los módulos de Apache instalados actualmente con el comando `apachectl`. Las versiones antiguas de Red Hat Enterprise Linux (RHEL) y CentOS pueden necesitar `httpd` en su lugar.
Usa `grep` para checkear inmediatamente si los tres módulos necesarios están presentes:
La activación de los módulos que faltan se puede realizar en la mayoría de las distribuciones con el script a2enmod.
Este script crea soft links en la carpeta /etc/apache2/mods-enabled.
El archivo con la extensión .load contiene instrucciones para cargar el módulo, y el archivo .conf contiene la configuración real del módulo:
Para versiones anteriores de RHEL y distribuciones basadas en ella, mod_ssl es un paquete específico que hay que instalar por separado:
Si el comando `a2enmod` no está disponible, estás trabajando con una distribución que guarda la configuración de Apache en un único archivo de configuración en lugar de dividirla en directorios y muchos archivos individuales.
En tal caso, hay que eliminar `#` de la línea comentada `LoadModule ssl_module […]` en el archivo de configuración `/etc/httpd/conf/httpd.conf`.
Haz lo mismo con los otros dos módulos.
Que el servidor web Apache se pueda reiniciar ahora o más tarde depende de si se generaron automáticamente certificados simples y autofirmados al instalar Apache.
Puedes averiguarlo buscando primero el archivo de configuración que contiene las rutas de los certificados y las claves, y luego checking si estos archivos existen (para RHEL, especifica /etc/httpd como directorio de inicio para la búsqueda):
root@linux# find /etc/apache2/ -type f -exec grep -Hn '^\s*SSLCertificate.*File' {} \;
/etc/apache2/sites-available/default-ssl.conf:32: SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
/etc/apache2/sites-available/default-ssl.conf:33: SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.keyComprueba si los archivos especificados en el archivo de configuración están presentes. Si no existe ningún certificado creado automáticamente, espera hasta que hayas recibido o creado un certificado tú mismo antes de reiniciar el servidor web Apache; de lo contrario, el reinicio fallará.
Si el certificado y la clave existen, reinicia el servidor web Apache, en el caso de systemd, que ahora se utiliza por defecto, utilizando el siguiente comando:
Una vez más, algunas distribuciones no utilizan apache2 como nombre del servicio, sino el algo más genérico httpd.
En este caso, edita el comando.
Nota: ¡En la Appliance Checkmk, habilita HTTPS a través de la interfaz web!
3. Obtención de certificados
Básicamente, existen los siguientes métodos para obtener un certificado de servidor:
Recurres a un proveedor de servicios externo para la emisión de certificados mediante CSR (solicitud de firma de certificado), cuyo certificado raíz cuenta con la confianza de los fabricantes de navegadores y sistemas operativos. Con este procedimiento, los certificados pueden validarse no solo a nivel de dominio, sino también a nivel de organización (validación de organización) y superior (validación extendida), tal y como es obligatorio en algunos sectores por motivos normativos. Puedes encontrar más información sobre estas opciones en Niveles de validación.
Utilizas certificados gratuitos de Let’s Encrypt. Este método solo permite la validación a nivel de dominio. Para poder solicitar certificados, el servidor que se va a proteger debe ser accesible desde el exterior o debes poder crear entradas (automatizadas) en el DNS público del dominio utilizado.
Te conviertes en tu propia Autoridad de Certificación (CA) y generas tus propios certificados. El certificado raíz de tu propia CA debe estar presente en todas las máquinas que se comuniquen con servidores que utilicen certificados firmados con la clave de la CA. Se deben mantener altos estándares de seguridad al gestionar tu propia CA, ya que esta CA se puede utilizar para emitir certificados para cualquier dominio.
3.1. Uso de CA externas
Durante mucho tiempo, contar con certificados firmados por una autoridad de certificación comercial era la única forma de obtener certificados aceptados por todos los navegadores y sistemas operativos. Este procedimiento sigue siendo habitual hoy en día, especialmente cuando se desean largos periodos de validez.
El procedimiento consiste en generar primero la clave privada del servidor y, a continuación, crear una solicitud de firma de certificado (CSR) para ella, que se envía al proveedor seleccionado. A continuación, el proveedor verifica la propiedad del dominio, confirma la CSR con su clave y te envía el certificado de servidor resultante.
Independientemente de los ejemplos que aparecen a continuación, asegúrate de seguir las directrices de tu autoridad de certificación y de modificar los comandos en consecuencia.
Generación de la clave y la CSR
Primero, generas la clave privada del servidor. Puedes realizar este paso directamente en el servidor donde se encuentra el site de Checkmk que deseas proteger.
La carpeta /etc/certs utilizada es la predeterminada en muchas distribuciones.
Sin embargo, puedes utilizar cualquier carpeta a la que el proceso de Apache tenga acceso de lectura.
Nombrar la clave con el nombre de dominio principal para el que se utiliza (en este caso, checkmk.mydomain.com) proporciona una mejor vista general en este contexto.
Especialmente si más adelante se añaden nombres de servidores adicionales, para los que se utilizan claves o certificados propios, este esquema de nomenclatura facilita la asignación.
La clave privada se utiliza posteriormente para cifrar el tráfico de datos y debe manejarse con el debido cuidado (por ejemplo, en lo que respecta a los derechos de acceso). Para poder reiniciar el servidor Apache automáticamente, la mayoría de los administradores no asignan una frase de contraseña.
En el siguiente paso, creas la solicitud de firma de certificado (CSR), una solicitud digital para la creación de un certificado de identidad (en este caso: un certificado de clave pública):
Asegúrate de introducir correctamente los datos de la empresa e introduce el nombre del servidor como Common Name.
El Email Address debe estar en el mismo dominio y pertenecer a un buzón existente que se lea activamente.
Creación de un archivo de extensión
Los navegadores modernos requieren certificados que utilicen la extensión para nombres del host alternativos, incluso si los certificados se han emitido para un solo nombre del host.
Esto requiere un archivo de extensión, que algunos proveedores crean e integran automáticamente.
Si no es así o si no estás seguro, crea dicho archivo.
Si un certificado debe ser válido para varios nombres del host, añade líneas adicionales después de [alt_names], DNS.2 = y así sucesivamente según sea necesario:
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = checkmk.mydomain.comEnvío de la documentación
Dependiendo del nivel de validación que se busque, puede ser necesario recopilar documentos adicionales, como extractos del registro mercantil o datos bancarios. Dado que los documentos solicitados, las formas de transmisión y las formas de confirmación varían de un proveedor a otro, no se puede ofrecer aquí una guía de aplicación general. Por ejemplo, la validación extendida (Extended Validation) también puede implicar que se envíe un código por correo certificado al director general o a un firmante autorizado, quien deberá introducir el código a través de una interfaz web.
En el caso más sencillo de una validación solo a nivel de dominio, el archivo CSR y, si procede, el archivo EXT se suben a través de una interfaz web.
A continuación, se te ofrece la opción de seleccionar una dirección de correo electrónico: entre las almacenadas para el Admin-C (propietario del dominio) o para el Tech-C (responsable técnico del dominio), o una dirección de correo electrónico genérica como webmaster@domain.com.
A continuación, se enviará un enlace de confirmación a esta dirección.
Recepción del certificado
El proceso de validación en sí suele tardar como máximo unos minutos para la validación a nivel de dominio, o a veces puede tardar varios días para una validación extendida. Una vez completado este proceso, recibirás el certificado correspondiente a tu clave por correo electrónico o mediante descarga. Además del certificado, también recibirás un enlace de descarga al archivo de la cadena de certificados. Asegúrate de guardar también este archivo.
3.2. Let’s Encrypt
Si se puede acceder al servidor de forma remota o si tienes acceso al servidor de nombres, puedes generar certificados automáticamente a través del proveedor de servicios sin ánimo de lucro Let’s Encrypt, que pertenece a la Electronic Frontier Foundation (EFF). No hay ningún coste asociado. Los certificados validados a través de DNS requieren unos minutos de atención cada 90 días; los certificados validados a través del directorio del servidor pueden regenerarse automáticamente durante años.
Para los certificados de Let’s Encrypt, la EFF ofrece Certbot, un programa en Python disponible en varios formatos de paquete. Certbot crea la clave, envía la CSR, checka la propiedad del servidor o dominio y, por último, descarga el certificado. Certbot se comunica con los servidores de la EFF a través del protocolo ACME (Automatic Certificate Management Environment).
Instalación del script Certbot
Hay tres formas de instalar Certbot. La que elijas dependerá principalmente de la antigüedad de la distribución que estés utilizando y de la directiva de tu organización sobre la instalación de paquetes de fuentes de terceros:
Si el administrador de paquetes de tu distribución de Linux ofrece Certbot versión 1.10 o superior, puedes usar esta versión de Certbot.
La EFF recomienda la instalación desde una imagen snap, tal y como se indica en su página de documentación de Certbot. Se aplican las ventajas y desventajas conocidas del formato de paquete snap.
Certbot se puede instalar mediante la herramienta de instalación de paquetes de Python
pipdesde el Índice de paquetes de Python. Primero crea un entorno virtual de Python (venv) para evitar dañar los módulos de Python proporcionados por la distribución. En el entorno virtual, ejecuta el comandopip install certbotpara instalar Certbot y todas las dependencias necesarias.
Configuración totalmente automatizada
Si se puede acceder al servidor Checkmk desde internet y no has realizado ningún cambio en la configuración del servidor web Apache a nivel del sistema desde que instalaste Checkmk, puedes utilizar la «automatización de Apache» de Certbot. Con esto puedes generar claves, solicitar certificados, ajustar automáticamente la configuración de Apache y, por último, configurar un cronjob para realizar la renovación periódica de los certificados que tienen una validez máxima de 90 días, antes de que caduquen.
El script te pedirá ahora de forma interactiva algunos datos de contacto (una dirección de correo electrónico para información adicional, como posibles renovaciones de certificados) y las rutas de instalación.
Una vez que el script haya terminado, tendrás una configuración SSL operativa.
No es necesario modificar el archivo de configuración de mod_ssl, ya que Certbot lo ha hecho por ti.
Configuración semiautomática
Si estás solicitando certificados, tal y como se describe en la sección anterior, pero quieres personalizar tú mismo la configuración de Apache, utiliza el comando:
A continuación, puedes completar la configuración tal y como se describe a continuación en el archivo de configuración de mod_ssl.
Más opciones
Por ejemplo, si solo se puede acceder al servidor Checkmk desde la intranet o a través de una VPN, pero el servidor DNS es público, puedes validarlo mediante un desafío DNS. En este caso, la propiedad de un dominio no se checka para poder subir archivos al servidor web, sino para poder añadir entradas en el DNS. No se trata de entradas que resuelvan el nombre del host a una dirección IP, sino de las llamadas entradas TXT, que pueden contener cualquier cadena de caracteres. Las entradas TXT también se utilizan, por ejemplo, para especificar qué servidores pueden enviar correos electrónicos para un dominio.
Los desafíos DNS se pueden realizar manualmente, lo que suele ser práctico solo para sistemas de prueba individuales con una validez de 90 días. Si tu proveedor de DNS tiene una API compatible con Let’s Encrypt, también se puede realizar una renovación automática. Para ello, lee la Vista general de los tipos de desafío en Let’s Encrypt.
3.3. Uso de CA internas
Puedes asumir el papel de una autoridad de certificación (CA) y emitir certificados para cualquier dominio (tus dominios, dominios ajenos y dominios ficticios).
La ruta a través de tu propia CA resulta especialmente útil para entornos de prueba o servidores Checkmk aislados con un número manejable de usuarios.
Esta es también la única forma de obtener certificados si utilizas internamente uno de los cinco dominios de nivel superior (TLD) reservados: .example, .invalid, .local, .localhost o .test.
No hay registradores para estos dominios, por lo que no se puede verificar la propiedad.
En este capítulo se explica cómo emitir certificados con una CA interna de este tipo. Se da por supuesto que ya dispones de la clave privada raíz de la CA o de la clave intermedia de la CA y que ahora debes usarla para emitir certificados con el fin de proteger un servidor Checkmk.
La creación de las claves de la CA, el certificado de la CA y el archivo de configuración asociado no se incluyen en este tutorial.
Generación de la clave y la CSR
Para crear la clave del servidor, la solicitud de firma de certificado (CSR) y el archivo de extensión, sigue los pasos descritos en la sección sobre emisión de certificados a través de una CA comercial. El procedimiento y los archivos necesarios son idénticos.
Firmar la CSR
Para firmar certificados tú mismo, necesitas al menos una clave privada (aquí intermediate.key.pem) y el certificado intermedio correspondiente intermediate.pem.
Si también tienes un archivo de configuración, debes especificar la ruta de acceso al mismo con el parámetro --config.
La firma basada en el archivo CSR checkmk.mydomain.com.csr, el archivo de extensión checkmk.mydomain.com.ext y el archivo de salida checkmk.mydomain.com.crt se realiza entonces con el siguiente comando:
Además del certificado de servidor checkmk.mydomain.com.crt creado aquí, también tienes que pasar tu certificado de CA intermediate.pem.
Si no eres una CA raíz, también debes reenviar el certificado raíz (denominado ca_certificate_internal.pem en el resto del texto).
Importar el certificado
Las opciones para importar un certificado de CA como de confianza varían de un navegador a otro.
Normalmente basta con añadir el certificado ca_certificate_internal.pem en Settings > Privacy y Security > Certificates > Import.
Para que la gestión de certificados no sea un obstáculo cuando los agentes se actualizan automáticamente en las ediciones comerciales, en Agent bakery hemos incluido la opción de pasar un certificado de CA propio que solo se usa para las actualizaciones de los agentes. En este caso, los certificados del sistema no se modifican y las actualizaciones de los agentes siguen siendo posibles.
Como alternativa a la distribución a través de las actualizaciones de los agentes, puedes integrar el certificado raíz en la base de datos de CA local del host.
Para ello, copia el archivo ca_certificate_internal.pem en /usr/local/share/ca-certificates/ y, a continuación, regenera la caché:
En Windows es posible gestionar los certificados del sistema a través del snap-in «Certificados» de MMC. Esto es necesario, por ejemplo, si quieres usar un navegador de Microsoft para acceder a un Checkmk protegido con su propia CA. Puedes leer el procedimiento exacto en el artículo de la Base de Conocimiento de Microsoft sobre PKI. Como alternativa, puedes distribuir certificados a través de Intune.
4. Configuración de la conexión HTTPS para un site
Primero, debes especificar las rutas de archivo correctas a la clave, el certificado y el certificado intermedio en el archivo de configuración SSL. Ten en cuenta que estas son configuraciones para el servidor web apache2 y no son específicas de Checkmk. Por lo tanto, el archivo de configuración que se usa en sistemas basados en Debian suele ser el predeterminado /etc/apache2/sites-enabled/default-ssl.conf, aunque la ruta del archivo puede ser diferente en distribuciones más antiguas.
En el ejemplo siguiente, SSLCertificateKeyFile hace referencia a la clave privada generada durante la configuración inicial de este servidor.
SSLCertificateChainFile contiene el certificado intermedio o, si procede, una concatenación de certificados intermedios dependientes.
Esto solo se omite en el caso de una CA interna en la que la clave de la CA se utiliza directamente para la firma.
Muchos proveedores comerciales usan nombres de archivo bastante genéricos, así que si los adoptas, la configuración se verá similar a la siguiente:
Si has usado Let’s Encrypt para generar certificados pero quieres actualizar la configuración manualmente, identifica las rutas de los archivos almacenados en /etc/letsencrypt/live e introdúcelas:
4.1. Añadir redireccionamiento HTTPS
Apache utiliza hosts virtuales para servir contenido para muchos nombres del host bajo una única dirección IP.
Si se utiliza el término «site» en el contexto de Apache, se refiere a un host virtual, no a un sitio de Checkmk.
En un servidor Checkmk dedicado, normalmente solo se utiliza un host virtual con un nombre de servidor bajo el cual se puede acceder a todos los sitios de Checkmk.
La configuración de VirtualHost se encuentra en uno de los siguientes archivos, dependiendo de la distribución que se utilice:
Debian, Ubuntu |
|
RHEL, CentOS |
|
SLES |
|
El siguiente ejemplo asume que utilizas un único archivo de configuración para conexiones sin cifrar en el puerto 80 y conexiones cifradas en el 443.
En este caso, añade las siguientes líneas a la sección VirtualHost:
Las dos líneas de «RequestHeader set X-Forwarded…» aquí garantizan que se notifique al site Apache en el puerto 5000 que se ha realizado una llamada a través de SSL, confirmando que se han seguido las reglas de seguridad.
Tras el cambio de configuración, hay que reiniciar el servidor web:
Una vez más, algunas distribuciones no utilizan apache2 como nombre del servicio, sino el más genérico httpd.
En tal caso, simplemente edita el comando.
5. Opciones adicionales
5.1. Configuración de HSTS
Hacer que el servidor Checkmk solo sea accesible a través de HTTPS es el primer paso y el más importante para proteger las conexiones a la monitorización. Sin embargo, puedes aumentar aún más la seguridad con ajustes adicionales opcionales. Por ejemplo, el servidor web puede indicar al navegador web que, en el futuro, solo se podrá acceder a él a través de HTTPS y que siempre se rechazará una conexión no segura a través de HTTP.
Esta técnica se llama «HTTP Strict Transport Security» (HSTS) y se define para un periodo de tiempo determinado en segundos. Una vez que este periodo haya expirado, el navegador checkea de nuevo si la restricción a través de HSTS sigue siendo válida.
Características de HSTS
Configurar HSTS no solo tiene la ventaja de garantizar que solo se puedan usar conexiones seguras, sino que su uso también conlleva ciertas condiciones que debes tener en cuenta antes de dar el switch:
Una vez que el navegador del usuario ha creado la entrada en el HSTS, solo se puede eliminar —al menos antes de que expire el tiempo especificado— con un conocimiento detallado del navegador en cuestión. Ten en cuenta que esto no se aplica a muchos usuarios.
La conexión será rechazada si, entre otras cosas, el certificado ha caducado o ha sido sustituido por uno autofirmado. Estas páginas no se pueden eludir ni siquiera con una excepción de confianza temporal de un certificado.
Por el contrario, el HSTS solo se tiene en cuenta si el certificado es de confianza cuando se establece la conexión por primera vez. De lo contrario, el navegador no crea una entrada para el HSTS, por lo que no se utiliza el mecanismo de protección adicional.
Configuración del servidor web Apache
Para configurar la opción, añade la siguiente entrada a la configuración HTTPS.
En Debian/Ubuntu, por defecto este es el archivo default-ssl.conf:
Importante: Primero configura un periodo de tiempo corto —por ejemplo, 600 segundos— para probar la configuración; de lo contrario, la conexión podría rechazarse permanentemente en caso de error. Más información al respecto en las Funciones especiales más abajo.
Para comprobar si la nueva configuración funciona, puedes usar el programa «curl» para consultar el servidor.
En este ejemplo solo se muestran las primeras 4 líneas de la salida: