Questa sezione contiene le migliori pratiche che dovrebbero essere osservate per configurare Zabbix in modo sicuro.
Le pratiche qui contenute non sono necessarie per il funzionamento di Zabbix. Sono raccomandati per una migliore sicurezza del sistema.
Il principio del privilegio minimo dovrebbe essere sempre utilizzato per Zabbix. Questo principio significa che l'account utente (nel frontend di Zabbix) o il processo utente (per server/proxy o agente Zabbix) dispone solo di quei privilegi che sono essenziali per svolgere le funzioni previste. In altre parole, gli account utente dovrebbero sempre essere eseguiti con il minor numero di privilegi possibile.
::: nota importante Dare autorizzazioni extra all'utente "zabbix" lo farà consentirgli di accedere ai file di configurazione ed eseguire operazioni che possono compromettere la sicurezza complessiva dell'infrastruttura. :::
Quando si implementa il principio del privilegio minimo per gli account utente, Zabbix utente frontend types. in considerazione. È importante capire che mentre un utente "Admin". type ha meno privilegi rispetto al tipo di utente "Super Admin", ha autorizzazioni amministrative che consentono di gestire la configurazione e l'esecuzione script personalizzati.
Alcune informazioni sono disponibili anche per gli utenti non privilegiati. Ad esempio, mentre Amministrazione → Script non è disponibile per non Super Admin, gli script stessi possono essere recuperati da utilizzando l'API di Zabbix. Limitare le autorizzazioni di script e non aggiungere informazioni sensibili (come credenziali di accesso, ecc.) dovrebbero essere utilizzate per evitare esposizione di informazioni sensibili disponibili negli script globali.
Nella configurazione predefinita, i processi del server Zabbix e dell'agente Zabbix condividono un utente 'zabbix'. Se desideri assicurarti che l'agente non possa accedere a dettagli sensibili nella configurazione del server (ad es. login al database informazioni), l'agente deve essere eseguito come un altro utente:
UTF-8 è l'unica codifica supportata da Zabbix. È nota per funzionare senza difetti di sicurezza. Gli utenti dovrebbero essere consapevoli che ci sono noti problemi di sicurezza se si utilizzano alcune delle altre codifiche.
Quando si utilizzano i programmi di installazione di Windows, si consiglia di utilizzare i percorsi predefiniti forniti dal programma di installazione poiché l'utilizzo di percorsi personalizzati senza le autorizzazioni adeguate potrebbe compromettere la sicurezza dell'installazione.
Su RHEL, installa il pacchetto mod_ssl:
Crea directory per le chiavi SSL:
Crea certificato SSL:
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/httpd/ssl/private/apache-selfsigned.key -out /etc/httpd/ssl/apache-selfsigned.crt
Compila le richieste in modo appropriato. La linea più importante è quella che richiede il nome comune. Devi inserire il nome di dominio che vuoi che sia associato al tuo server. Puoi inserire l'IP pubblico indirizzo invece se non si dispone di un nome di dominio. Noi useremo example.com in questo articolo.
Nome Paese (codice di 2 lettere) [XX]:
Nome dello stato o della provincia (nome completo) []:
Nome località (es. città) [Città predefinita]:
Nome organizzazione (ad es. azienda) [Default Company Ltd]:
Nome unità organizzativa (ad es. sezione) []:
Nome comune (ad esempio, il tuo nome o il nome host del tuo server) []:example.com
Indirizzo e-mail []:
Modifica configurazione SSL Apache:
/etc/httpd/conf.d/ssl.conf
DocumentRoot "/usr/share/zabbix"
ServerName example.com:443
SSLCertificateFile /etc/httpd/ssl/apache-selfsigned.crt
SSLCertificateKeyFile /etc/httpd/ssl/private/apache-selfsigned.key
Riavvia il servizio Apache per applicare le modifiche:
Aggiungi un host virtuale alla configurazione di Apache e imposta il reindirizzamento permanente per la root del documento all'URL SSL di Zabbix. Non dimenticare di sostituire example.com con il nome effettivo del server.
/etc/httpd/conf/httpd.conf
#Aggiungi linee
<VirtualHost *:*>
ServerName example.com
Reindirizzamento permanente / https://example.com
</VirtualHost>
Riavvia il servizio Apache per applicare le modifiche:
Per proteggere il frontend di Zabbix dagli attacchi di downgrade del protocollo, noi consiglio di abilitare HSTS politica sul server web.
Ad esempio, per abilitare la politica HSTS per il tuo frontend Zabbix nella configurazione Apache:
aggiungi la seguente direttiva alla configurazione del tuo host virtuale:
<host virtuale *:443>
Set di intestazione Strict-Transport-Security "max-age=31536000"
</VirtualHost>
Riavvia il servizio Apache per applicare le modifiche:
To protect Zabbix frontend against Cross Site Scripting (XSS), data injection, and similar attacks, we recommend enabling Content Security Policy on the web server. To do so, configure the web server to return the HTTP header.
The following CSP header configuration is only for the default Zabbix frontend installation and for cases when all content originates from the site's domain (excluding subdomains). A different CSP header configuration may be required if you are, for example, configuring the URL widget to display content from the site's subdomains or external domains, switching from OpenStreetMap to another map engine, or adding external CSS or widgets.
To enable CSP for your Zabbix frontend in Apache configuration, follow these steps:
1. Locate your virtual host's configuration file:
/etc/httpd/conf/httpd.conf
on RHEL-based systems/etc/apache2/sites-available/000-default.conf
on Debian/Ubuntu2. Add the following directive to your virtual host's configuration file:
<VirtualHost *:*>
Header set Content-Security-Policy: "default-src 'self' *.openstreetmap.org; script-src 'self' 'unsafe-inline' 'unsafe-eval'; connect-src 'self'; img-src 'self' data: *.openstreetmap.org; style-src 'self' 'unsafe-inline'; base-uri 'self'; form-action 'self';"
</VirtualHost>
3. Restart the Apache service to apply the changes:
# On RHEL-based systems:
systemctl restart httpd.service
# On Debian/Ubuntu
systemctl restart apache2.service
Si consiglia di disabilitare tutte le firme del server Web come parte del processo di rafforzamento del server web. Il server Web sta esponendo il software firma per impostazione predefinita:
La firma può essere disabilitata aggiungendo due righe al file Apache (usato come un esempio) file di configurazione:
La firma PHP (intestazione HTTP X-Powered-By) può essere disabilitata modificando il file File di configurazione php.ini (la firma è disabilitata per impostazione predefinita):
Il riavvio del server Web è necessario per le modifiche al file di configurazione applicato.
È possibile ottenere un livello di sicurezza aggiuntivo utilizzando il file mod_security (pacchetto libapache2-mod-security2) con Apache. mod_security consente di rimuovere la firma del server invece di rimuovere solo la versione dal server firma. La firma può essere modificata in qualsiasi valore cambiando "SecServerSignature" su qualsiasi valore desiderato dopo l'installazione mod_security.
Si prega di fare riferimento alla documentazione del proprio server web per trovare aiuto su come farlo rimuovere/modificare le firme del software.
Si consiglia di disabilitare le pagine di errore predefinite per evitare informazioni esposizione. Il server Web utilizza le pagine di errore integrate per impostazione predefinita:
Le pagine di errore predefinite devono essere sostituite/rimosse come parte del processo di indurimento del server web. La direttiva "ErrorDocument" può essere utilizzata per definire la pagina/testo di errore personalizzato per il server Web Apache (utilizzato come esempio).
Si prega di fare riferimento alla documentazione del proprio server web per trovare aiuto su come farlo sostituire/rimuovere le pagine di errore predefinite.
Si consiglia di rimuovere la pagina di test del server web per evitare esposizione delle informazioni. Per impostazione predefinita, la webroot del server web contiene un test pagina chiamata index.html (Apache2 su Ubuntu è usato come esempio):
La pagina di test deve essere rimossa o resa non disponibile come parte di il processo di rafforzamento del server web.
Per impostazione predefinita, Zabbix è configurato con la risposta HTTP X-Frame-Options header impostato su SAMEORIGIN
, il che significa che il contenuto può essere caricato solo in un frame che ha la stessa origine della pagina stessa.
Elementi frontend di Zabbix che estraggono contenuti da URL esterni (vale a dire, l'URL dashboard widget) visualizzare il contenuto recuperato in una sandbox con tutte le restrizioni di sandboxing abilitato.
Queste impostazioni migliorano la sicurezza del frontend Zabbix e forniscono protezione contro attacchi XSS e clickjacking. I super amministratori possono modifica iframe sandboxing e intestazione di risposta HTTP X-Frame-Options parametri secondo necessità. Si prega di valutare attentamente i rischi e i benefici prima di modificare le impostazioni predefinite. Girando sandboxing o X-Frame-Options spento completamente non è raccomandato.
L'agente Windows Zabbix compilato con OpenSSL proverà a raggiungere il file di configurazione SSL in c:\openssl-64bit. La directory "openssl-64bit". su disco C: può essere creato da utenti non privilegiati.
Quindi, per rafforzare la sicurezza, è necessario creare questa directory manualmente e revocare l'accesso in scrittura agli utenti non amministratori.
Tieni presente che i nomi delle directory saranno diversi su 32 bit e Versioni a 64 bit di Windows.
Per aumentare la complessità degli attacchi di forza bruta della password, è suggerito di limitare l'accesso al file ui/data/top_passwords.txt
di modifica della configurazione del server web. Questo file contiene un elenco di password più comuni e specifiche del contesto e viene utilizzato per impedire agli utenti dall'impostazione di tali password se il parametro Evita password facili da indovinare è abilitato in password policy.
Ad esempio, su NGINX l'accesso ai file può essere limitato utilizzando la "posizione". direttiva:
Su Apache - utilizzando il file .htacess
: