 |
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 proporcionar lo siguiente en tu servidor de monitorización, independientemente de tus sites:
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.
El servidor es accesible a través de HTTPS.
En este artículo se explica todo lo necesario para conseguir una configuración de este tipo.
2. Activar los módulos Apache
El acceso HTTPS de la interfaz Checkmk requiere el módulo Apache mod_ssl. También supondremos en el curso posterior de la configuración que una conexión que llegue por el puerto 80 sin cifrar debe reenviarse al puerto 443 cifrado SSL. Esto requiere el módulo mod_rewrite. Por último, mod_headers es necesario para que el Apache de acceso externo configurado como Proxy inverso reenvíe las cabeceras de las peticiones al Apache del site.
Puedes mostrar los módulos de Apache instalados actualmente con el comando apachectl. Las versiones antiguas de Red Hat Enterprise Linux (RHEL) y CentOS pueden necesitar en su lugar httpd. Utiliza grep para comprobar inmediatamente si están presentes los tres módulos necesarios:
root@linux# apachectl -M | grep -E 'headers|rewrite|ssl'
headers_module (shared)
rewrite_module (shared)La activación de los módulos que faltan se puede conseguir 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:
root@linux# a2enmod ssl
Enabling module ssl.
To activate the new configuration, you need to run:
systemctl restart apache2Para versiones antiguas de RHEL y distribuciones basadas en él, mod_ssl es un paquete dedicado que debe instalarse por separado:
root@linux# yum install -y httpd mod_sslSi el comando a2enmod no está disponible, es que estás trabajando con una distribución que mantiene 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, la línea comentada LoadModule ssl_module […] del archivo de configuración /etc/httpd/conf/httpd.conf debe eliminarse de #. Procede del mismo modo para los otros dos módulos.
Que el servidor web Apache pueda reiniciarse ahora o más tarde depende de si al instalar Apache se generaron automáticamente certificados simples autofirmados.
Puedes averiguarlo buscando primero el archivo de configuración que contiene las rutas de los archivos del certificado y las claves, y comprobando después si esos archivos existen (para RHEL, especifica /etc/httpd como directorio de inicio de 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.keyCheck whether the files specified in the configuration file are present. If no automatically created certificate exists, wait until you have received or created a certificate yourself before restarting the Apache web server - otherwise the restart will fail.
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:
root@linux# systemctl restart apache2De nuevo, 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 el appliance Checkmk, activa HTTPS a través de la interfaz web!
3. Recibir certificados
Básicamente, existen los siguientes métodos para obtener un certificado de servidor:
Utilizas un proveedor de servicios externo para la emisión de certificados mediante CSR(Certificate Signing Request), en cuyo certificado raíz confían los fabricantes de navegadores y sistemas operativos. Con este procedimiento, los certificados pueden validarse no sólo a nivel de dominio, sino también a nivel de organización (Validación de organización) y superior (Validación ampliada), como es obligatorio en algunas clases de empresas 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 sólo permite la validación a nivel de dominio. Para poder solicitar certificados, el servidor 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 ( AC) y generas tus propios certificados. El certificado raíz de tu propia AC debe estar presente en todas las máquinas que se comuniquen con servidores que utilicen certificados firmados con la clave de la AC. Deben mantenerse altos niveles de seguridad al tratar con la propia AC, ya que ésta puede utilizarse para emitir certificados para cualquier dominio.
3.1. Utilizar CAs externas
Durante mucho tiempo, tener certificados firmados por una autoridad de certificación comercial fue la única forma de obtener certificados aceptados por todos los navegadores y sistemas operativos. Este procedimiento sigue siendo habitual hoy en día, sobre todo cuando se desean largos periodos de validez.
El procedimiento consiste en que primero generas la clave privada del servidor y luego creas una Solicitud de Firma de Certificado (CSR) para ella, que transfieres al proveedor seleccionado. A continuación, el proveedor verifica la titularidad del dominio, confirma la CSR con su clave y te envía el certificado del servidor resultante.
Independientemente de los ejemplos siguientes, asegúrate de seguir las directrices de tu Autoridad de Certificación y modifica los comandos en consecuencia.
Generar clave y CSR
En primer lugar, genera la clave privada del servidor. Puedes realizar este paso directamente en el servidor donde se encuentra el site Checkmk que quieres proteger.
La carpeta /etc/certs utilizada es la predeterminada para muchas distribuciones. Sin embargo, puedes utilizar cualquier carpeta a la que el proceso Apache tenga acceso de lectura. Nombrar la clave con el nombre del dominio principal para el que se utiliza (aquí checkmk.mydomain.com) proporciona una mejor visión general en este contexto. Especialmente si más adelante se añaden nombres de servidores adicionales, para los que se utilizan claves/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.
root@linux# openssl genrsa -out /etc/certs/checkmk.mydomain.com.key 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
.....++
...............................................................++
e is 65537 (0x010001)En el siguiente paso, creas la Solicitud de Firma de Certificado (CSR) - una solicitud digital para la creación de un certificado de identidad (aquí: un certificado de clave pública):
root@linux# openssl req -new -key checkmk.mydomain.com.key -out checkmk.mydomain.com.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
---
Country Name (2 letter code) [AU]: DE
State or Province Name (full name) [Some-State]: Bavaria
Locality Name (eg, city) []: Munich
Organization Name (eg, company) [Internet Widgits Pty Ltd]: Yoyodyne Inc.
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []: checkmk.mydomain.com
Email Address []: webmaster@mydomain.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []: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.
Crear un archivo de extensión
Los navegadores modernos exigen certificados que utilicen la extensión para nombres de host alternativos, aunque los certificados se emitan 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, en [alt_names] añade líneas adicionales, DNS.2 =, etc., según sea necesario:
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = checkmk.mydomain.comPresentar la documentación
Dependiendo del nivel de validación que se busque, puede ser necesario recopilar más documentos, como extractos del registro mercantil o datos bancarios. Dado que los documentos solicitados, las formas de transmisión y las formas de confirmación difieren de un proveedor a otro, no se pueden dar aquí orientaciones de aplicación general. Por ejemplo, la Validación Extendida también puede significar que se envíe un código por correo certificado al director general o a un firmante autorizado, que luego debe introducir el código a través de una interfaz web.
En el caso más sencillo de una validación sólo a nivel de dominio, el archivo CSR y, si procede, el archivo EXT se cargan a través de una interfaz web. A continuación, se te da 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 durar como máximo unos minutos para una validación a nivel de dominio, o a veces puede tardar varios días para una validación ampliada. Una vez finalizado 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 del certificado. Asegúrate de guardar también este archivo.
3.2. Encriptemos
Si se puede acceder a un servidor de forma remota o si tienes acceso al servidor de nombres, puedes hacer que se generen 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 tiene ningún coste. 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 Let's Encrypt, la EFF proporciona Certbot, un programa en Python disponible en varios formatos de paquetes. Certbot crea la clave, envía la CSR, comprueba la propiedad del servidor o dominio y, por último, descarga el certificado. Certbot se comunica con los servidores de la EFF mediante el protocolo Automatic Certificate Management Environment (ACME).
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 utilices 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 proporciona la versión 1.10 o superior de Certbot, se puede utilizar esta versión de Certbot.
Certbot puede instalarse mediante la herramienta de instalación de paquetes de Python
pip3desde el Índice de Paquetes de Python. El comandopip3 install certbottambién instala todas las dependencias necesarias.La FEP prefiere la instalación desde una imagen snap en su página de documentación de Certbot. Se aplican las ventajas e inconvenientes conocidos del formato de paquete snap.
Configuración totalmente automatizada
Si el servidor Checkmk es accesible desde internet y no has hecho ningún cambio en la configuración del servidor web Apache de todo el sistema desde la instalación de Checkmk, puedes utilizar el "automatismo Apache" de Certbot, con el que puedes generar claves, solicitar certificados, ajustar automáticamente la configuración de Apache y, por último, configurar un cronjob para renovar periódicamente los certificados que son válidos durante un máximo de 90 días, antes de que caduquen.
root@linux# certbot --apacheAhora, el script te pedirá de forma interactiva algunos datos relativos a los datos de contacto (contacto por correo electrónico para obtener información adicional, como la retirada necesaria de certificados) y las rutas de instalación. Una vez que el script haya finalizado, tendrás una configuración SSL en funcionamiento. No es necesario modificar el archivo de configuración para mod_ssl, esto ya lo ha hecho el Certbot.
Configuración semiautomatizada
Si vas a solicitar certificados, como se describe en la sección anterior, pero quieres personalizar tú mismo la configuración de Apache, utiliza el comando:
root@linux# certbot certonly --apacheA continuación, puedes completar la configuración como se describe a continuación en el archivo de configuración para mod_ssl.
Más opciones
Por ejemplo, si el servidor Checkmk sólo es accesible desde la intranet o a través de una VPN, pero el servidor DNS es público, puedes validarlo mediante un Desafío DNS. Aquí no se comprueba la propiedad de un dominio para poder poner archivos en el servidor web, sino para poder añadir entradas en el DNS. No se trata de entradas que resuelven un nombre del host en 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 están autorizados a enviar correos electrónicos para un dominio.
Las impugnaciones de DNS se pueden realizar manualmente, lo que normalmente sólo es práctico 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 Vista general de los tipos de impugnación en Let's Encrypt.
3.3. Utilizar CAs internas
Puedes ponerte en el papel de una Autoridad de Certificación (AC) y emitir certificados para cualquier dominio (tus dominios, dominios extranjeros y dominios de fantasía). La ruta a través de tu propia AC es especialmente útil para entornos de prueba o servidores Checkmk aislados con un número manejable de usuarios. También es 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 su titularidad.
En este capítulo se explica cómo emitir certificados con una CA interna de este tipo. Se supone que ya tienes la clave raíz privada de la CA o la clave intermedia de la CA y que ahora debes utilizarla para emitir certificados que aseguren un servidor Checkmk.
La creación de las claves de CA, el certificado de CA y el archivo de configuración asociado no se incluyen en este tutorial.
Generar clave y CSR
Para crear la clave del servidor, la solicitud de firma de certificado (CSR) y el archivo de extensión, procede como se describe en la sección 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 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:
user@host:~$ openssl x509 -CAcreateserial -req \
-in checkmk.mydomain.com.csr \
-CA intermediate.pem -CAkey intermediate.key.pem \
-out checkmk.mydomain.com.crt -days 365 \
-sha256 -extfile checkmk.mydomain.com.extAdemás del certificado de servidor checkmk.mydomain.com.crt creado aquí, también tienes que transmitir tu certificado de CA intermediate.pem. Si no eres una CA raíz, también debes transmitir 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_intern.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 el Agent bakery hemos previsto la opción de pasar un certificado de CA propio que sólo se utiliza para las actualizaciones de los agentes. En este caso, los certificados del sistema no se tocan, y las actualizaciones de los agentes siguen siendo posibles.
Como alternativa a la distribución mediante actualizaciones de agentes, puedes integrar el certificado raíz en la base de datos de CA local del host. Para ello, copia el archivo ca_certificate_intern.pem en /usr/local/share/ca-certificates/, y luego regenera el caché:
root@linux# update-ca-certificatesEn Windows es posible gestionar los certificados del sistema a través del snap-in "Certificados" de la MMC. Esto es necesario, por ejemplo, si quieres utilizar 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 conocimientos PKI de Microsoft. Como alternativa, puedes distribuir certificados a través de Intune.
4. Configurar la conexión HTTPS para un site
En primer lugar, debes especificar las rutas de archivo correctas para la clave, el certificado y el certificado intermedio en el archivo de configuración SSL. Ten en cuenta que éstas son configuraciones para el servidor web apache2 y no son específicas de Checkmk. Por lo tanto, el archivo de configuración utilizado en los 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 denota la clave privada generada en la configuración inicial de este servidor.SSLCertificateChainFile contiene el certificado intermedio o, en su caso, una concatenación de certificados intermedios dependientes. Esto sólo se omite en el caso de una CA interna en la que la clave de la CA se utiliza directamente para firmar.
Muchos proveedores comerciales utilizan nombres de archivo bastante genéricos, por lo que si los adoptas, la configuración tendrá un aspecto similar al siguiente:
SSLEngine on
SSLCertificateKeyFile /etc/certs/checkmk.mydomain.com.key
SSLCertificateChainFile /etc/certs/ca_bundle.crt
SSLCertificateFile /etc/certs/certificate.crtSi has utilizado 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:
SSLEngine on
SSLCertificateKeyFile /etc/letsencrypt/live/checkmk.mydomain.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/checkmk.mydomain.com/chain.pem
SSLCertificateFile /etc/letsencrypt/live/checkmk.mydomain.com/cert.pem4.1. Añadir reenvío HTTPS
Apache trabaja con hosts virtuales para servir contenido para muchos nombres de 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 de este tipo, no a un site Checkmk. En un servidor Checkmk dedicado, normalmente sólo se utiliza un host virtual con un nombre de servidor bajo el cual se puede acceder a todos los sites 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 supone que utilizas un único archivo de configuración para las conexiones sin cifrar en el puerto 80 y las conexiones cifradas en el 443. En este caso, añade las siguientes líneas a la sección VirtualHost:
RewriteEngine On
# Never forward request for .well-known (important when using Let's Encrypt)
RewriteCond %{REQUEST_URI} !^/.well-known
# Next 2 lines: Force redirection if incoming request is not on 443
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}$1 [L]
# This section passes the system Apaches connection mode to the
# instance Apache. Make sure mod_headers is enabled, otherwise it
# will be ignored and "Analyze configuration" will issue "WARN".
<IfModule headers_module>
RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME}
RequestHeader set X-Forwarded-SSL expr=%{HTTPS}
</IfModule>Las dos líneas RequestHeader set X-Forwarded… de 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:
root@linux# systemctl restart apache2De nuevo, 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. Configurar HSTS
Hacer que el servidor Checkmk sólo sea accesible a través de HTTPS es el primer paso y el más importante para asegurar las conexiones a la monitorización. Sin embargo, puedes aumentar aún más la seguridad con configuraciones adicionales y opcionales. Por ejemplo, el servidor web puede indicar al navegador que en el futuro sólo 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 denomina "HTTP Strict Transport Security" (HSTS) y se define para un determinado periodo de tiempo en segundos. Una vez transcurrido este periodo, el navegador vuelve a comprobar si la limitación mediante HSTS sigue siendo válida.
Características de HSTS
Configurar HSTS no sólo tiene la ventaja de garantizar que sólo se pueden utilizar conexiones seguras, su uso también conlleva ciertas condiciones que hay que conocer antes de hacer el cambio:
Una vez que el navegador del usuario ha creado la entrada al HSTS, sólo se puede eliminar -al menos antes de que expire el tiempo especificado- con un conocimiento debidamente 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 pueden evitarse ni siquiera con una excepción de confianza temporal de un certificado.
Por el contrario, HSTS sólo 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 HSTS, por lo que no se utiliza el mecanismo de protección adicional.
Configuración del servidor web Apache
Para establecer la opción, añade la siguiente entrada a la configuración HTTPS. En Debian/Ubuntu, por defecto es el archivo default-ssl.conf:
Header always set Strict-Transport-Security "max-age=43200"Importante: Establece primero un periodo de tiempo corto -por ejemplo, 600 segundos- para probar la configuración, ¡de lo contrario la conexión puede ser rechazada permanentemente en caso de error! Más sobre esto en las Funciones especiales más abajo.
Para comprobar si la nueva configuración funciona, puedes utilizar el programa curl para recuperar el servidor. En este ejemplo sólo se muestran las 4 primeras líneas de salida:
root@linux# curl -I \https://mycmkserver/mysite/check_mk/login.py
HTTP/1.1 200 OK
Date: Tue, 01 Jun 2021 09:30:20 GMT
Server: Apache
Strict-Transport-Security: max-age=3600