 |
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. Introduzione
Se vuoi utilizzare l'interfaccia web di Checkmk tramite HTTPS, dovrai disporre di quanto segue sul tuo server di monitoraggio, indipendentemente dai siti:
Il modulo Apache
mod_sslsia installato e attivato.I moduli Apache
mod_rewriteemod_headerssono presenti e attivati.Hai un certificato valido del server.
Il server è accessibile tramite HTTPS.
Questo articolo spiega tutto ciò che è necessario per ottenere una configurazione di questo tipo.
2. Attivare i moduli Apache
L'accesso HTTPS all'interfaccia Checkmk richiede il modulo Apache mod_ssl. Nel prosieguo dell'installazione, si ipotizza anche che una connessione in arrivo sulla porta 80 non criptata debba essere inoltrata alla porta 443 criptata SSL. Ciò richiede il modulo mod_rewrite. Infine, mod_headers è necessario affinché l'Apache accessibile dall'esterno e configurato come Proxy inverso inoltri le intestazioni delle richieste all'Apache dell'istanza Checkmk.
Puoi visualizzare i moduli Apache attualmente installati con il comando apachectl. Le vecchie versioni di Red Hat Enterprise Linux (RHEL) e CentOS potrebbero necessitare di httpd. Utilizza grep per verificare immediatamente se tutti e tre i moduli richiesti sono presenti:
root@linux# apachectl -M | grep -E 'headers|rewrite|ssl'
headers_module (shared)
rewrite_module (shared)L'attivazione dei moduli mancanti può essere ottenuta sulla maggior parte delle distribuzioni con lo script a2enmod. Questo script crea dei soft link nella cartella /etc/apache2/mods-enabled. Il file con estensione .load contiene le istruzioni per caricare il modulo, mentre il file .conf contiene la configurazione effettiva del modulo:
root@linux# a2enmod ssl
Enabling module ssl.
To activate the new configuration, you need to run:
systemctl restart apache2Per le vecchie versioni di RHEL e le distribuzioni basate su di essa, mod_ssl è un pacchetto dedicato che deve essere installato separatamente:
root@linux# yum install -y httpd mod_sslSe il comando a2enmod non è disponibile, significa che stai lavorando con una distribuzione che mantiene la configurazione di Apache in un unico file di configurazione invece di suddividerla in directory e in molti file individuali. In questo caso, la riga commentata LoadModule ssl_module […] nel file di configurazione /etc/httpd/conf/httpd.conf deve essere rimossa da #. Procedi allo stesso modo per gli altri due moduli.
Se il server web Apache può essere riavviato ora o in seguito, dipende dal fatto che i certificati semplici self-signed sono stati generati automaticamente al momento dell'installazione di Apache.
Puoi scoprirlo cercando prima il file di configurazione che contiene i percorsi dei file del certificato e delle chiavi e poi verificando se questi file esistono (per RHEL, specifica /etc/httpd come directory di partenza per la ricerca):
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.keyControlla se i file specificati nel file di configurazione sono presenti. Se non esiste un certificato creato automaticamente, aspetta di averne ricevuto o creato uno tu stesso prima di riavviare il server web Apache, altrimenti il riavvio fallirà.
Se il certificato e la chiave esistono, riavvia il server web Apache, nel caso di systemd, che è ora utilizzato per impostazione predefinita, utilizzando il seguente comando:
root@linux# systemctl restart apache2Anche in questo caso, alcune distribuzioni non utilizzano apache2 come nome del servizio, bensì il più generico httpd. In questo caso, modifica il comando.
Nota: nell'appliance Checkmk, attiva l'HTTPS tramite l'interfaccia web!
3. Ricevere certificati
Per ottenere un certificato del server sono disponibili i seguenti metodi:
Utilizzi un provider esterno per l'emissione di certificati tramite CSR(Certificate Signing Request), il cui certificato radice è ritenuto affidabile dai produttori di browser e sistemi operativi. Con questa procedura, i certificati possono essere convalidati non solo a livello di dominio, ma anche a livello di organizzazione (Organization Validation) e più in alto (Extended Validation), come è obbligatorio in alcune categorie di aziende per motivi normativi. Maggiori informazioni su queste opzioni sono disponibili in Livelli di convalida.
Stai utilizzando certificati gratuiti di Let's Encrypt.Questo metodo consente la convalida solo a livello di dominio. Per poter richiedere i certificati, il server da proteggere deve essere accessibile dall'esterno o devi essere in grado di creare voci (automatizzate) nel DNS pubblico del dominio utilizzato.
Diventa la tua Autorità di Certificazione (CA) e genera i tuoi certificati. Il certificato radice della tua CA deve essere presente su tutti i computer che comunicano con i server che utilizzano certificati firmati con la chiave della CA. È necessario mantenere elevati standard di sicurezza quando si ha a che fare con la propria CA, poiché questa può essere utilizzata per autorizzare certificati per qualsiasi dominio.
3.1. Utilizzo di CA esterne
Per molto tempo, i certificati firmati da un'autorità di certificazione commerciale sono stati l'unico modo per ottenere certificati accettati da tutti i browser e gli operatori. Questa procedura è ancora oggi comune, soprattutto quando si desiderano lunghi periodi di validità.
La procedura consiste nel generare la chiave privata del server e creare una richiesta di firma del certificato (CSR) che viene trasferita al provider selezionato, il quale verifica la proprietà del dominio, conferma la CSR con la sua chiave e ti invia il certificato del server risultante.
Indipendentemente dagli esempi che seguono, assicurati di seguire le linee guida della tua Autorità di Certificazione e di modificare i comandi di conseguenza.
Generazione della chiave e del CSR
Per prima cosa, devi generare la chiave privata del server. Puoi eseguire questo passaggio direttamente sul server in cui si trova l'istanza Checkmk da proteggere.
La cartella /etc/certs utilizzata è quella predefinita per molte distribuzioni. Tuttavia, puoi utilizzare qualsiasi cartella a cui il processo Apache ha accesso in lettura. Il nome della chiave con il nome del dominio primario per cui viene utilizzata (qui checkmk.mydomain.com) fornisce una panoramica migliore in questo contesto. Soprattutto se in seguito vengono aggiunti altri nomi di server, per i quali vengono utilizzate chiavi/certificati propri, questo schema di denominazione facilita l'assegnazione.
La chiave privata viene utilizzata in seguito per crittografare il traffico di dati e deve essere gestita con la dovuta attenzione (ad esempio per quanto riguarda i diritti di accesso). Per poter riavviare automaticamente il server Apache, la maggior parte degli amministratori non assegna una passphrase.
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)Nel passo successivo, crei la Certificate Signing Request (CSR), una richiesta digitale per la creazione di un certificato di identità (in questo caso: un certificato a chiave pubblica):
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 []:Assicurati di inserire correttamente i dati dell'azienda e di inserire il nome del server come Common Name. Email Address deve trovarsi nello stesso dominio e appartenere a una casella di posta esistente che viene letta attivamente.
Creare un file di estensione
I browser moderni richiedono certificati che utilizzano l'estensione per nomi host alternativi, anche se i certificati sono emessi per un solo nome host. Ciò richiede un file di estensione, che alcuni provider creano e integrano automaticamente. Se non è questo il caso o se non sei sicuro, crea un file di questo tipo. Se un certificato deve essere valido per più nomi host, seguendo [alt_names] aggiungi altre righe, DNS.2 = e così via come richiesto:
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = checkmk.mydomain.comInvio della documentazione
A seconda del livello di convalida richiesto, potrebbe essere necessario compilare ulteriori documenti come estratti del registro commerciale o dati bancari. Poiché i documenti richiesti, le modalità di invio e le modalità di conferma variano da provider a provider, non è possibile fornire indicazioni generali. Ad esempio, la convalida estesa può anche comportare l'invio di un codice per posta raccomandata all'amministratore delegato o a un firmatario autorizzato, che dovrà poi inserire il codice tramite un'interfaccia web.
Nel caso più semplice di una convalida solo a livello di dominio, il file CSR e, se applicabile, il file EXT vengono caricati tramite un'interfaccia web. Ti viene quindi data la possibilità di selezionare un indirizzo e-mail: tra quelli memorizzati per l'Admin-C (proprietario del dominio) o per il Tech-C (responsabile tecnico del dominio), oppure un indirizzo e-mail generico come webmaster@domain.com. A questo indirizzo verrà inviato un link di conferma.
Ricevere il certificato
Il processo di convalida dura al massimo qualche minuto per la convalida a livello di dominio o può richiedere diversi giorni per una convalida estesa. Una volta completato il processo, riceverai il certificato appartenente alla tua chiave tramite e-mail o download. Oltre al certificato, riceverai anche un link per il download del file della catena del certificato. Assicurati di salvare anche questo file.
3.2. Crittografia
Se un server è accessibile da remoto o se hai accesso al nome del servizio, puoi far generare automaticamente i certificati tramite il provider no-profit Let's Encrypt, che appartiene alla Electronic Frontier Foundation (EFF). I certificati convalidati tramite DNS richiedono pochi minuti di attenzione ogni 90 giorni, mentre quelli convalidati tramite la directory del server possono essere rigenerati automaticamente per anni.
Per i certificati Let's Encrypt, la EFF mette a disposizione Certbot, un programma Python disponibile in diversi formati di pacchetto. Certbot crea la chiave, invia il CSR, controlla la proprietà del server o del dominio e infine scarica il certificato. Certbot comunica con i server EFF tramite il protocollo Automatic Certificate Management Environment (ACME).
Installazione dello script Certbot
L'installazione di Certbot può avvenire in tre modi: la scelta dipende principalmente dall'età della distribuzione che stai utilizzando e dalla policy della tua organizzazione sull'installazione di pacchetti da fonti terze:
Se la gestione dei pacchetti della tua distribuzione Linux fornisce Certbot versione 1.10 o superiore, è possibile utilizzare questa versione di Certbot.
Certbot può essere installato tramite lo strumento di installazione dei pacchetti Python
pip3dal Python Package Index. Il comandopip3 install certbotinstalla anche tutte le dipendenze necessarie.L'EFF preferisce l'installazione da un'immagine snap nella pagina di documentazione di Certbot. Si applicano i vantaggi e gli svantaggi noti del formato snap package.
Configurazione completamente automatizzata
Se il server Checkmk è accessibile da internet e non hai apportato alcuna modifica alla configurazione del server web Apache di sistema dopo l'installazione di Checkmk, puoi utilizzare l'"automatismo Apache" di Certbot, con il quale puoi generare chiavi, richiedere certificati, regolare automaticamente la configurazione di Apache e infine impostare un cronjob per rinnovare periodicamente i certificati che hanno una validità massima di 90 giorni, prima della loro scadenza.
root@linux# certbot --apacheLo script chiederà in modo interattivo alcune informazioni relative ai contatti (contatto e-mail per ulteriori informazioni come i richiami dei certificati necessari) e ai percorsi di installazione. Una volta terminato lo script, avrai una configurazione SSL funzionante. Non è necessario modificare il file di configurazione di mod_ssl, in quanto è già stato fatto da Certbot.
Configurazione semi-automatica
Se stai richiedendo dei certificati, come descritto nella sezione precedente, ma vuoi personalizzare la configurazione di Apache da solo, utilizza il comando:
root@linux# certbot certonly --apachePuoi quindi completare la configurazione come descritto di seguito nel file di configurazione di mod_ssl.
Altre opzioni
Ad esempio, se il server Checkmk è accessibile solo dall'intranet o tramite VPN, ma il server DNS è pubblico, puoi effettuare la convalida tramite una sfida DNS. In questo caso, la proprietà di un dominio non viene verificata per poter inserire file nel server web, ma per poter aggiungere voci nel DNS. Non si tratta di voci che risolvono un nome host in un indirizzo IP, ma delle cosiddette voci TXT, che possono contenere qualsiasi stringa di caratteri. Le voci TXT vengono utilizzate anche, ad esempio, per specificare quali server sono autorizzati a inviare e-mail per un dominio.
Le sfide DNS possono essere eseguite manualmente, il che di solito è pratico solo per i sistemi di prova individuali con validità di 90 giorni. Se il tuo provider DNS dispone di un'API supportata da Let's Encrypt, è possibile eseguire anche un rinnovo automatico. A tal proposito, leggi la panoramica sui tipi di sfida di Let's Encrypt.
3.3. Utilizzare le CA interne
Puoi assumere il ruolo di Autorità di Certificazione (CA) ed emettere certificati per qualsiasi dominio (i tuoi domini, domini stranieri e domini di fantasia). Il percorso attraverso la tua CA è particolarmente utile per gli ambienti di test o per i server Checkmk isolati con un numero gestibile di utenti. Questo è anche l'unico modo per ottenere certificati se utilizzi internamente uno dei cinque domini di primo livello (TLD) riservati .example, .invalid, .local, .localhost o .test. Non ci sono registrar per questi domini e di conseguenza non è possibile verificarne la proprietà.
In questo capitolo viene spiegato come emettere certificati con una CA interna di questo tipo. Si presume che i prerequisiti siano già in possesso della chiave privata della CA root o della CA intermedia e che ora la si debba utilizzare per emettere certificati per proteggere un server Checkmk.
La creazione delle chiavi CA, del certificato CA e del file di configurazione associato non sono inclusi in questo tutorial.
Generazione della chiave e del CSR
Per creare la chiave del server, la richiesta di firma del certificato (CSR) e il file di estensione, procedi come descritto nella sezione sull'emissione di certificati tramite una CA commerciale. La procedura e i file necessari sono identici.
Firmare il CSR
Per firmare i certificati da solo, hai bisogno almeno di una chiave privata (qui intermediate.key.pem) e del corrispondente certificato intermedio intermediate.pem. Se disponi anche di un file di configurazione, il percorso di quest'ultimo deve essere indicato con il parametro --config.
La firma basata sul file CSR checkmk.mydomain.com.csr, sul file di estensione checkmk.mydomain.com.ext e sul file di output checkmk.mydomain.com.crt viene eseguita con il seguente 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.extOltre al certificato del server checkmk.mydomain.com.crt creato qui, devi trasmettere anche il certificato della tua CA intermediate.pem. Se non sei una CA radice, devi trasmettere anche il certificato radice (indicato come ca_certificate_internal.pem nel resto del testo).
Importare il certificato
Le opzioni per importare un certificato CA come attendibile variano da browser a browser. Di solito è sufficiente aggiungere il certificato ca_certificate_intern.pem sotto Settings > Privacy e Security > Certificates > Import.
Affinché la gestione dei certificati non sia un ostacolo quando gli agenti vengono aggiornati automaticamente nelle edizioni commerciali, nell'Agent bakery abbiamo previsto l'opzione di passare un proprio certificato CA che viene utilizzato solo per gli aggiornamenti dell'agente. In questo caso i certificati di sistema non vengono toccati e gli aggiornamenti dell'agente sono ancora possibili.
In alternativa alla distribuzione tramite gli aggiornamenti dell'agente, puoi integrare il certificato radice nel database della CA locale dell'host. Per farlo, copia il file ca_certificate_intern.pem su /usr/local/share/ca-certificates/, quindi rigenera la cache:
root@linux# update-ca-certificatesIn Windows è possibile gestire i certificati di sistema tramite lo snap-in MMC "Certificati". Questo è necessario, ad esempio, se vuoi utilizzare un browser Microsoft per accedere a un Checkmk protetto dalla propria CA. Puoi leggere la procedura esatta nell'articolo della Microsoft Knowledge Base PKI. In alternativa, puoi distribuire i certificati tramite Intune.
4. Configurazione della connessione HTTPS per un sito
Per prima cosa, devi specificare i percorsi corretti per la chiave, il certificato e il certificato intermedio nel file di configurazione SSL. Nota che queste sono configurazioni per il server web apache2 e non sono specifiche per Checkmk. Pertanto, il file di configurazione utilizzato nei file system basati su Debian è solitamente quello predefinito /etc/apache2/sites-enabled/default-ssl.conf, ma il percorso del file potrebbe essere diverso nelle distribuzioni più vecchie.
Nell'esempio che segue, SSLCertificateKeyFile indica la chiave privata generata al momento della configurazione iniziale di questo server.SSLCertificateChainFile contiene il certificato intermedio o, se applicabile, una concatenazione di certificati intermedi dipendenti. Questo file viene omesso solo nel caso di una CA interna in cui la chiave della CA viene utilizzata direttamente per la firma.
Molti produttori commerciali utilizzano nomi di file piuttosto generici, quindi se li adotti la configurazione sarà simile alla seguente:
SSLEngine on
SSLCertificateKeyFile /etc/certs/checkmk.mydomain.com.key
SSLCertificateChainFile /etc/certs/ca_bundle.crt
SSLCertificateFile /etc/certs/certificate.crtSe hai utilizzato Let's Encrypt per generare certificati ma vuoi aggiornare la configurazione manualmente, individua i percorsi dei file memorizzati in /etc/letsencrypt/live e inseriscili:
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. Aggiungere l'inoltro HTTPS
Apache lavora con host virtuali per servire contenuti per molti nomi host sotto un unico indirizzo IP. Se il termine "sito" viene utilizzato nel contesto di Apache, si intende un host virtuale di questo tipo, non un sito Checkmk. Su un server Checkmk dedicato, di solito viene utilizzato un solo host virtuale con un nome server sotto il quale possono essere raggiunti tutti i siti Checkmk. La configurazione di VirtualHost si trova in uno dei seguenti file, a seconda della distribuzione utilizzata:
Debian, Ubuntu |
|
RHEL, CentOS |
|
SLES |
|
L'esempio seguente presuppone l'utilizzo di un unico file di configurazione per le connessioni non criptate sulla porta 80 e per quelle criptate sulla 443. In questo caso, aggiungi le seguenti righe alla sezione 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>Le due linee RequestHeader set X-Forwarded… assicurano che il sito Apache sulla porta 5000 riceva la notifica che una chiamata è stata effettuata tramite SSL, confermando che le regole di sicurezza sono state rispettate.
Dopo la modifica della configurazione, il server web deve essere riavviato:
root@linux# systemctl restart apache2Anche in questo caso, alcune distribuzioni non utilizzano apache2 come nome del servizio, ma il più generico httpd. In questo caso, è sufficiente modificare il comando.
5. Opzioni aggiuntive
5.1. Impostazione di UPTS
Rendere il server Checkmk accessibile solo tramite HTTPS è il primo e più importante passo per rendere sicure le connessioni al monitoraggio. Tuttavia, puoi aumentare ulteriormente la sicurezza con impostazioni aggiuntive e opzionali. Ad esempio, il server web può indicare al browser che in futuro si potrà accedere solo tramite HTTPS e che una connessione non protetta tramite HTTP verrà sempre rifiutata.
Questa tecnica è chiamata "HTTP Strict Transport Security" (HSTS) ed è definita per un certo periodo di tempo in secondi. Una volta scaduto questo periodo, il browser verifica nuovamente se la limitazione via HSTS è ancora valida.
Caratteristiche dell'HSTS
L'impostazione dell'HSTS non ha solo il vantaggio di garantire l'utilizzo di connessioni sicure, ma comporta anche alcune condizioni di cui bisogna essere a conoscenza prima di effettuare lo switch:
Una volta che il browser dell'utente ha creato un accesso all'HSTS, è possibile rimuoverlo - almeno prima della scadenza del tempo specificato - solo con una conoscenza approfondita del browser in questione. Si noti che questo non vale per molti utenti.
La connessione verrà rifiutata se, tra le altre cose, il certificato è scaduto o è stato sostituito da un certificato self-signed. Tali pagine non possono essere aggirate nemmeno con un'eccezione per la fiducia temporanea di un certificato.
Al contrario, l'HSTS viene preso in considerazione solo se il certificato è attendibile quando la connessione viene stabilita per la prima volta. In caso contrario, il browser non crea una voce per l'HSTS, quindi il meccanismo di protezione aggiuntivo non viene utilizzato.
Configurazione del server web Apache
Per impostare l'opzione, aggiungi la seguente voce alla configurazione HTTPS. In Debian/Ubuntu, per impostazione predefinita si tratta del file default-ssl.conf:
Header always set Strict-Transport-Security "max-age=43200"Importante: Per prima cosa imposta un breve periodo di tempo - ad es. 600 secondi - per testare l'impostazione, altrimenti la connessione potrebbe essere rifiutata in modo permanente in caso di errore! Per saperne di più, consulta le Funzioni speciali qui sotto.
Per verificare se la nuova impostazione funziona, puoi utilizzare il programma curl per recuperare il server. In questo esempio vengono mostrate solo le prime 4 righe dell'output:
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