 |
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 configurare quanto segue sul tuo server di monitoraggio, indipendentemente dalle tue istanze:
Il modulo Apache
mod_sslè installato e attivato.I moduli Apache
mod_rewriteemod_headerssiano presenti e anch’essi attivati.Hai un certificato del server valido.
Il server è accessibile tramite HTTPS.
Questo articolo spiega tutto ciò che è necessario per ottenere tale configurazione.
2. Attivazione dei moduli Apache
L'accesso HTTPS all'interfaccia di Checkmk richiede il modulo Apache mod_ssl.
Nel prosieguo del Setup, partiamo inoltre dal presupposto che una connessione in entrata sulla porta non crittografata 80 debba essere inoltrata alla porta crittografata SSL 443.
Ciò richiede il modulo mod_rewrite.
Infine, è necessario mod_headers affinché l'Apache accessibile dall'esterno e configurato come proxy inverso inoltri le intestazioni delle richieste all'istanza Apache del sito.
Puoi visualizzare i moduli Apache attualmente installati con il comando apachectl. Le vecchie versioni di Red Hat Enterprise Linux (RHEL) e CentOS potrebbero invece richiedere httpd.
Usa grep per checkare immediatamente se tutti e tre i moduli richiesti sono presenti:
L'attivazione dei moduli mancanti può essere effettuata sulla maggior parte delle distribuzioni con lo script a2enmod.
Questo script crea soft links 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:
Per le versioni precedenti di RHEL e le distribuzioni basate su di essa, mod_ssl è un pacchetto dedicato che deve essere installato separatamente:
Se il comando a2enmod non è disponibile, stai lavorando con una distribuzione che conserva la configurazione di Apache in un unico file di configurazione invece di suddividerla in directory e molti file singoli.
In tal caso, la riga commentata LoadModule ssl_module […] nel file di configurazione /etc/httpd/conf/httpd.conf deve essere privata di #.
Procedi allo stesso modo per gli altri due moduli.
La possibilità di riavviare il server web Apache subito o in un secondo momento dipende dal fatto che, al momento dell'installazione di Apache, siano stati generati automaticamente dei certificati semplici self-signed.
Puoi verificarlo cercando prima il file di configurazione che contiene i percorsi dei file relativi al certificato e alle chiavi, quindi checkando 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.keyVerifica se i file specificati nel file di configurazione sono presenti. Se non esiste alcun certificato creato automaticamente, attendi di aver ricevuto o creato tu stesso un certificato 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 viene utilizzato di default, utilizzando il seguente comando:
Anche in questo caso, alcune distribuzioni non utilizzano apache2 come nome del servizio, ma il nome un po' più generico httpd.
In questo caso, modifica il comando.
Nota: nel dispositivo Checkmk, abilita HTTPS tramite l'interfaccia web!
3. Ottenere i certificati
In sostanza, sono disponibili i seguenti metodi per ottenere un certificato per il server:
Utilizzi un fornitore di servizi esterno per l'emissione del certificato tramite CSR (Certificate Signing Request), il cui certificato radice è considerato attendibile 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 a livelli superiori (Extended Validation), come richiesto in alcuni settori di attività per motivi normativi. Maggiori informazioni su queste opzioni sono disponibili nella sezione Livelli di convalida.
Utilizzi certificati gratuiti di Let’s Encrypt. Questo metodo consente solo la convalida al livello di dominio. Per poter richiedere i certificati, il server da proteggere deve essere accessibile dall’esterno oppure devi essere in grado di creare voci (automatizzate) nel DNS pubblico del dominio utilizzato.
Diventi la tua Autorità di Certificazione (CA) e generi i tuoi certificati. Il certificato root della tua CA deve essere presente su tutte le macchine che comunicano con i server che utilizzano certificati firmati con la chiave della CA. Quando si ha a che fare con la propria CA, è necessario mantenere elevati standard di sicurezza, poiché questa CA può essere utilizzata per emettere certificati per qualsiasi dominio.
3.1. Utilizzo di CA esterne
Per molto tempo, avere certificati firmati da un'autorità di certificazione commerciale era l'unico modo per ottenere certificati accettati da tutti i browser e sistemi operativi. Questa procedura è ancora comune oggi, specialmente quando si desiderano lunghi periodi di validità.
La procedura prevede che tu generi prima la chiave privata del server e poi crei una richiesta di firma del certificato (CSR) per essa, che trasferisci al provider selezionato. Il provider verifica quindi la proprietà del dominio, conferma la CSR con la sua chiave e ti invia il certificato del server risultante.
Indipendentemente dagli esempi riportati di seguito, assicurati di seguire le linee guida della tua autorità di certificazione e di modificare i comandi di conseguenza.
Generazione della chiave e della CSR
Per prima cosa, genera 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 abbia accesso in lettura.
Assegnare alla chiave il nome del dominio principale per cui viene utilizzata (in questo caso checkmk.mydomain.com) offre una migliore panoramica in questo contesto.
Soprattutto se in seguito vengono aggiunti ulteriori nomi di server, per i quali vengono utilizzate chiavi/certificati propri, questo schema di denominazione facilita l’assegnazione.
La chiave privata viene successivamente utilizzata per crittografare il traffico 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.
Nel passaggio successivo, creerai la Certificate Signing Request (CSR) — una richiesta digitale per la creazione di un certificato di identità (in questo caso: un certificato a chiave pubblica):
Assicurati di inserire correttamente i dati dell'azienda e di inserire il nome del server come Common Name.
L'Email Addresse deve trovarsi nello stesso dominio e appartenere a una casella di posta esistente che viene letta attivamente.
Creazione di un file di estensione
I browser moderni richiedono certificati che utilizzino 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 così non fosse o se non ne sei sicuro, crea un file di questo tipo.
Se un certificato deve essere valido per più nomi host, aggiungi ulteriori righe dopo [alt_names], DNS.2 = e così via, secondo necessità:
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 delle imprese o dati bancari. Poiché i documenti richiesti, le modalità di invio e le modalità di conferma variano da provider a provider, non è possibile fornire qui indicazioni generali. Ad esempio, la convalida estesa (Extended Validation) può anche significare che un codice viene inviato tramite raccomandata all’amministratore delegato o a un firmatario autorizzato, che deve poi inserire il codice tramite un’interfaccia web.
Nel caso più semplice di una convalida solo al livello di dominio, il file CSR e, se del caso, 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à quindi inviato un link di conferma.
Ricezione del certificato
Il processo di convalida richiede solitamente al massimo pochi minuti per la convalida al livello di dominio, oppure può talvolta richiedere diversi giorni per una convalida estesa. Una volta completato questo processo, riceverai il certificato associato alla tua chiave via e-mail o tramite scaricamento. Oltre al certificato, riceverai anche un link per scaricare il file della catena di certificati. Assicurati di salvare anche questo file.
3.2. Let’s Encrypt
Se è possibile accedere al server da remoto o se hai accesso al server dei nomi, puoi far generare i certificati automaticamente tramite il provider di servizi senza scopo di lucro Let’s Encrypt, che appartiene alla Electronic Frontier Foundation (EFF). Non ci sono costi. I certificati convalidati tramite DNS richiedono qualche minuto di attenzione ogni 90 giorni, mentre quelli convalidati tramite directory del server possono essere rigenerati automaticamente per anni.
Per i certificati Let’s Encrypt, l’EFF fornisce Certbot, un programma Python disponibile in vari formati di pacchetto. Certbot crea la chiave, invia la CSR, verifica la proprietà del server o del dominio e infine effettua lo scaricamento del certificato. Certbot comunica con i server dell’EFF tramite il protocollo ACME (Automatic Certificate Management Environment).
Installazione dello script Certbot
Ci sono tre modi per installare Certbot. La scelta dipende principalmente dall'età della distribuzione che stai usando e dalla policy della tua organizzazione sull'installazione di pacchetti da fonti terze:
Se il gestore di pacchetti della tua distribuzione Linux fornisce Certbot versione 1.10 o superiore, puoi utilizzare questa versione di Certbot.
L'EFF preferisce l'installazione da un'immagine snap, come indicato nella loro pagina di documentazione su Certbot. Si applicano i vantaggi e gli svantaggi noti del formato del pacchetto snap.
Certbot può essere installato tramite lo strumento di installazione dei pacchetti Python
pipdal Python Package Index. Per prima cosa crea un ambiente virtuale Python (venv) per evitare di danneggiare i moduli Python forniti dalla distribuzione. Nell'ambiente virtuale, esegui il comandopip install certbotper installare Certbot e tutte le dipendenze necessarie.
Configurazione completamente automatizzata
Se il server Checkmk è accessibile da internet e non hai apportato alcuna modifica alla configurazione del server web Apache di sistema dall'installazione di Checkmk, puoi utilizzare la funzione "Apache automatism" di Certbot. In questo modo puoi generare chiavi, richiedere certificati, modificare automaticamente la configurazione di Apache e infine impostare un cronjob per effettuare il rinnovo periodico dei certificati validi per un massimo di 90 giorni, prima della loro scadenza.
Lo script ora richiederà in modo interattivo alcune informazioni relative ai dati di contatto (indirizzo e-mail per ulteriori informazioni, come eventuali richiami di certificati) e ai percorsi di installazione.
Una volta terminato lo script, avrai una configurazione SSL funzionante.
Non è necessaria alcuna modifica al file di configurazione di mod_ssl, poiché questa operazione è già stata eseguita da Certbot.
Configurazione semi-automatica
Se stai richiedendo certificati, come descritto nella sezione precedente, ma vuoi personalizzare tu stesso la configurazione di Apache, usa il comando:
Puoi quindi completare la configurazione come descritto di seguito nel file di configurazione per 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 checkata per poter caricare file sul 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, ad esempio, anche per specificare quali server sono autorizzati a inviare e-mail per un dominio.
Le DNS Challenge possono essere eseguite manualmente, il che di solito è pratico solo per singoli sistemi di test 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 fine, leggi la panoramica dei tipi di Challenge su Let’s Encrypt.
3.3. Utilizzo di CA interne
Puoi assumere il ruolo di Autorità di Certificazione (CA) ed emettere certificati per qualsiasi dominio (i tuoi domini, domini esterni e domini di fantasia).
Il percorso tramite la tua CA è particolarmente utile per ambienti di test o 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 esistono registrar per questi domini, di conseguenza non è possibile verificarne la proprietà.
Questo capitolo spiega come emettere certificati con una CA interna di questo tipo. Si presume che tu disponga già della chiave privata della CA root o della CA intermedia e che ora intenda utilizzarla per emettere certificati per proteggere un server Checkmk.
La creazione delle chiavi CA, del certificato CA e del file di configurazione associato non è inclusa 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 richiesti sono identici.
Firma della CSR
Per firmare i certificati autonomamente, hai bisogno almeno di una chiave privata (in questo caso intermediate.key.pem) e del certificato intermedio corrispondente intermediate.pem.
Se disponi anche di un file di configurazione, il percorso deve essere specificato 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 quindi eseguita con il seguente comando:
Oltre al certificato del server checkmk.mydomain.com.crt creato qui, devi anche trasmettere il tuo certificato CA intermediate.pem.
Se non sei una CA radice, devi anche inoltrare il certificato radice (indicato come ca_certificate_internal.pem nel resto del testo).
Importazione del certificato
Le opzioni per importare un certificato CA come attendibile variano da browser a browser.
Di solito è sufficiente aggiungere il certificato ca_certificate_internal.pem sotto Settings > Privacy e Security > Certificates > Import.
Affinché la gestione dei certificati non costituisca un ostacolo quando gli agenti vengono aggiornati automaticamente nelle edizioni commerciali, in agent bakery abbiamo previsto la possibilità di specificare un certificato CA proprio, utilizzato esclusivamente per gli aggiornamenti degli agenti. In questo caso i certificati di sistema non vengono modificati e gli aggiornamenti degli agenti sono comunque possibili.
In alternativa alla distribuzione tramite gli aggiornamenti degli agenti, puoi integrare il certificato radice nel database CA locale dell’host.
Per farlo, copia il file ca_certificate_internal.pem in /usr/local/share/ca-certificates/, quindi rigenera la cache:
Su Windows è possibile gestire i certificati di sistema tramite lo snap-in MMC "Certificati". Ciò è necessario, ad esempio, se desideri utilizzare un browser Microsoft per accedere a un Checkmk protetto con la propria CA. Puoi leggere la procedura esatta nell'articolo della Knowledge Base Microsoft PKI. In alternativa, puoi distribuire i certificati tramite Intune.
4. Configurazione della connessione HTTPS per un'istanza
Per prima cosa, devi specificare i percorsi corretti dei file relativi alla chiave, al certificato e al certificato intermedio nel file di configurazione SSL. Tieni presente che si tratta di configurazioni per il server web apache2 e non sono specifiche di Checkmk. Pertanto, il file di configurazione utilizzato sui sistemi basati su Debian è solitamente quello predefinito /etc/apache2/sites-enabled/default-ssl.conf , tuttavia il percorso del file potrebbe essere diverso sulle distribuzioni più vecchie.
Nell'esempio qui sotto, SSLCertificateKeyFile indica la chiave privata generata durante la configurazione iniziale di questo server.
SSLCertificateChainFile contiene il certificato intermedio o, se applicabile, una concatenazione di certificati intermedi dipendenti.
Questo viene omesso solo per una CA interna in cui la chiave CA viene utilizzata direttamente per la firma.
Molti fornitori commerciali utilizzano nomi di file piuttosto generici, quindi se li adotti la configurazione sarà simile alla seguente:
Se hai usato Let’s Encrypt per generare i certificati ma vuoi aggiornare la configurazione manualmente, individua i percorsi dei file memorizzati in /etc/letsencrypt/live e inseriscili:
4.1. Aggiunta dell'inoltro HTTPS
Apache utilizza gli host virtuali per fornire contenuti per molti nomi host sotto un unico indirizzo IP.
Se nel contesto di Apache si usa il termine "istanza", si intende proprio un host virtuale, non un'istanza Checkmk.
Su un server Checkmk dedicato, di solito si usa un solo host virtuale con un nome server, sotto il quale è poi possibile raggiungere tutte le istanze Checkmk.
La configurazione dell'VirtualHoste si trova in uno dei seguenti file, a seconda della distribuzione utilizzata:
Debian, Ubuntu |
|
RHEL, CentOS |
|
SLES |
|
L'esempio seguente presuppone che tu utilizzi un unico file di configurazione per le connessioni non crittografate sulla porta 80 e quelle crittografate sulla 443.
In questo caso, aggiungi le seguenti righe alla sezione VirtualHost:
Le due righe RequestHeader set X-Forwarded… qui presenti assicurano che l'istanza Apache sulla porta 5000 venga informata che è stata effettuata una chiamata tramite SSL, confermando che le regole di sicurezza sono state rispettate.
Dopo aver modificato la configurazione, devi riavviare il server web:
Anche in questo caso, alcune distribuzioni non utilizzano apache2 come nome del servizio, ma il più generico httpd.
In tal caso, basta modificare il comando.
5. Opzioni aggiuntive
5.1. Configurazione di HSTS
Rendere il server Checkmk accessibile solo tramite HTTPS è il primo e più importante passo per proteggere le connessioni al monitoraggio. Puoi però aumentare ulteriormente la sicurezza con impostazioni aggiuntive e opzionali. Ad esempio, il server web può comunicare al browser web che in futuro sarà accessibile solo tramite HTTPS e che una connessione non protetta tramite HTTP verrà sempre rifiutata.
Questa tecnica si chiama "HTTP Strict Transport Security" (HSTS) ed è definita per un determinato periodo di tempo in secondi. Una volta scaduto questo periodo, il browser verifica nuovamente se la limitazione tramite HSTS è ancora valida.
Caratteristiche di HSTS
Configurare l'HSTS non solo ha il vantaggio di garantire che si possano utilizzare solo connessioni sicure, ma il suo utilizzo comporta anche alcune condizioni di cui bisogna essere consapevoli prima di effettuare il switch:
Una volta che la voce HSTS è stata creata dal browser dell'utente, può essere rimossa — almeno prima della scadenza del tempo specificato — solo con una conoscenza approfondita del browser in questione. Tieni presente che questo non vale per molti utenti.
La connessione verrà rifiutata se, tra le altre cose, il certificato è scaduto o è stato sostituito da un self-signed. Tali pagine non possono essere aggirate nemmeno con un'eccezione per l'affidabilità temporanea di un certificato.
Al contrario, l'HSTS viene preso in considerazione solo se il certificato è considerato attendibile al momento della prima connessione. 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.
Su Debian/Ubuntu, di default si tratta del file default-ssl.conf:
Importante: imposta prima un periodo di tempo breve — ad es. 600 secondi — per testare l'impostazione, altrimenti la connessione potrebbe essere rifiutata in modo permanente in caso di errore! Maggiori informazioni su questo argomento nelle Funzioni speciali qui sotto.
Per verificare se la nuova impostazione funziona, puoi utilizzare il programma curl per interrogare il server.
In questo esempio vengono mostrate solo le prime 4 righe dell'output: