3 Web server

Panoramica

Questa sezione contiene le best practice per configurare il web server in modo sicuro.

Reindirizzamento forzato dell'URL root a Zabbix SSL

Sui sistemi basati su RHEL, aggiungi un virtual host alla configurazione di Apache (/etc/httpd/conf/httpd.conf) e imposta un reindirizzamento permanente della document root all'URL SSL di Zabbix. Nota che example.com deve essere sostituito con il nome effettivo del server.

# Aggiungi le righe:

<VirtualHost *:*>
    ServerName example.com
    Redirect permanent / https://example.com
</VirtualHost>

Riavvia il servizio Apache per applicare le modifiche:

systemctl restart httpd.service

Abilitazione di HTTP Strict Transport Security (HSTS) sul server web

Per proteggere il frontend di Zabbix dagli attacchi di downgrade del protocollo, consigliamo di abilitare il criterio HSTS sul server web.

Per abilitare il criterio HSTS per il frontend di Zabbix nella configurazione di Apache, seguire questi passaggi:

1. Individuare il file di configurazione del virtual host:

  • /etc/httpd/conf/httpd.conf sui sistemi basati su RHEL
  • /etc/apache2/sites-available/000-default.conf su Debian/Ubuntu

2. Aggiungere la seguente direttiva al file di configurazione del virtual host:

<VirtualHost *:*>
    Header set Strict-Transport-Security "max-age=31536000"
</VirtualHost>

3. Riavviare il servizio Apache per applicare le modifiche:

# Sui sistemi basati su RHEL:
systemctl restart httpd.service

# Su Debian/Ubuntu
systemctl restart apache2.service

Quando si configura Zabbix, è essenziale imporre gli attributi secure e SameSite per i cookie di sessione per migliorare la sicurezza e prevenire gli attacchi di cross-site request forgery (CSRF). Tuttavia, l'imposizione di SameSite=Strict può causare problemi in alcuni scenari, ad esempio:

  • I widget URL della dashboard mostrano "user not logged in" quando si incorporano iframe dello stesso dominio.
  • Gli utenti che accedono alla dashboard tramite HTTP invece di HTTPS possono riscontrare problemi di accesso.
  • Impossibilità di condividere URL verso sezioni specifiche del menu di Zabbix o verso host.

Per attenuare questi problemi, gli utenti dovrebbero avere un modo per regolare la policy SameSite.

1. Cookie Secure

L'impostazione del flag secure garantisce che i cookie vengano trasmessi solo tramite HTTPS, evitando l'esposizione su connessioni non cifrate.

Per abilitare i cookie secure in Zabbix, aggiungere o modificare la seguente impostazione nella configurazione del web server:

Per Apache:

Header always edit Set-Cookie ^(.*)$ $1;Secure

Per Nginx:

proxy_cookie_path / "/; Secure";

Assicurarsi che il frontend di Zabbix sia accessibile tramite HTTPS; in caso contrario, i cookie con il flag Secure non verranno inviati.

2. Configurazione dell'attributo SameSite

Le impostazioni del web server possono anche imporre l'attributo SameSite:

Per Apache:

<IfModule mod_headers.c>
    Header onsuccess edit Set-Cookie (.*) "$1; SameSite=Strict"
</IfModule>

Per Nginx (versione 1.19.3+):

proxy_cookie_flags ~ samesite=Strict; # Replace ~ with 'zbx_session' for specificity

Abilitazione di Content Security Policy (CSP) sul web server

Per proteggere il frontend di Zabbix da Cross Site Scripting (XSS), injection di dati e attacchi simili, consigliamo di abilitare Content Security Policy sul web server. Per farlo, configura il web server in modo che restituisca l'HTTP header.

La seguente configurazione dell'header CSP è valida solo per l'installazione predefinita del frontend di Zabbix e per i casi in cui tutto il contenuto proviene dal dominio del sito (esclusi i sottodomini). Potrebbe essere necessaria una configurazione diversa dell'header CSP se, ad esempio, stai configurando il widget URL per visualizzare contenuti provenienti dai sottodomini del sito o da domini esterni, passando da OpenStreetMap a un altro motore di mappe, oppure aggiungendo CSS o widget esterni. Se utilizzi il metodo di autenticazione multi-factor authentication Duo Universal Prompt, assicurati di aggiungere "duo.com" alla direttiva CSP nel file di configurazione del virtual host.

Per abilitare CSP per il frontend di Zabbix nella configurazione di Apache, segui questi passaggi:

1. Individua il file di configurazione del virtual host:

  • /etc/httpd/conf/httpd.conf sui sistemi basati su RHEL
  • /etc/apache2/sites-available/000-default.conf su Debian/Ubuntu

2. Aggiungi la seguente direttiva al file di configurazione del virtual host:

<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. Riavvia il servizio Apache per applicare le modifiche:

# Sui sistemi basati su RHEL:
systemctl restart httpd.service

# Su Debian/Ubuntu
systemctl restart apache2.service

Disabilitazione dell'esposizione delle informazioni del web server

Per migliorare la sicurezza, si consiglia di disabilitare tutte le firme del web server.

Per impostazione predefinita, il web server espone la firma del software:

La firma può essere disabilitata aggiungendo i seguenti parametri al file di configurazione di Apache:

ServerSignature Off
ServerTokens Prod

La firma PHP (intestazione HTTP X-Powered-By) può essere disabilitata modificando il file di configurazione php.ini (per impostazione predefinita, la firma è disabilitata):

expose_php = Off

Per applicare le modifiche al file di configurazione è necessario riavviare il web server.

Per una sicurezza aggiuntiva, è possibile usare lo strumento mod_security con Apache (pacchetto libapache2-mod-security2). Questo strumento consente di rimuovere la firma del server invece di rimuovere solo la versione dalla firma del server. La firma del server può essere modificata in qualsiasi valore impostando "SecServerSignature" su qualsiasi valore desiderato dopo l'installazione di mod_security.

Consultare la documentazione del proprio web server per trovare assistenza su come rimuovere/modificare le firme del software.

Disabilitazione delle pagine di errore predefinite del web server

Per evitare l'esposizione di informazioni, si consiglia di disabilitare le pagine di errore predefinite.

Per impostazione predefinita, un web server utilizza pagine di errore integrate:

Queste pagine di errore predefinite devono essere sostituite/rimosse. Ad esempio, la direttiva "ErrorDocument" può essere utilizzata per definire una pagina/testo di errore personalizzato per il web server Apache.

Consultare la documentazione del proprio web server per trovare indicazioni su come sostituire/rimuovere le pagine di errore predefinite.

Rimozione della pagina di test del web server

Per evitare l'esposizione di informazioni, si consiglia di rimuovere la pagina di test del web server.

Per impostazione predefinita, la directory webroot del web server Apache contiene la pagina di test index.html:

Consultare la documentazione del proprio web server per trovare istruzioni su come rimuovere le pagine di test predefinite.

Impostare l'intestazione di risposta HTTP X-Frame-Options

Per impostazione predefinita, Zabbix è configurato con il parametro Use X-Frame-Options HTTP header impostato su SAMEORIGIN. Ciò significa che il contenuto può essere caricato solo in un frame che ha la stessa origine della pagina stessa.

Gli elementi del frontend di Zabbix che recuperano contenuti da URL esterni (in particolare, il widget dashboard URL) visualizzano il contenuto recuperato in una sandbox con tutte le restrizioni di sandboxing abilitate.

Queste impostazioni migliorano la sicurezza del frontend di Zabbix e forniscono protezione contro gli attacchi XSS e clickjacking. Gli utenti Super admin possono modificare i parametri Use iframe sandboxing e Use X-Frame-Options HTTP header secondo necessità. Valutate attentamente i rischi e i vantaggi prima di modificare le impostazioni predefinite. Non è consigliabile disattivare completamente il sandboxing degli iframe o l'intestazione HTTP X-Frame-Options.

Nascondere il file con l'elenco delle password comuni

Per aumentare la complessità degli attacchi di brute force sulle password, si consiglia di limitare l'accesso al file ui/data/top_passwords.txt. Questo file contiene un elenco delle password più comuni e specifiche per il contesto e impedisce agli utenti di impostare tali password (se il parametro Avoid easy-to-guess passwords è abilitato nella password policy).

Per limitare l'accesso al file top_passwords.txt, modifica la configurazione del tuo web server.

Su Apache, l'accesso al file può essere limitato usando il file .htaccess:

<Files "top_passwords.txt">
    Order Allow,Deny
    Deny from all
</Files>

Su NGINX, l'accesso al file può essere limitato usando la direttiva location:

location = /data/top_passwords.txt {
    deny all;
    return 404;
}