3 Web server

Overview

This section contains best practices for setting up the web server in a secure way.

Enabling Zabbix on root directory of URL

On RHEL-based systems, add a virtual host to Apache configuration (/etc/httpd/conf/httpd.conf) and set a permanent redirect for document root to Zabbix SSL URL. Note that example.com should be replaced with the actual name of the server.

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

Restart the Apache service to apply the changes:

systemctl restart httpd.service

Enabling HTTP Strict Transport Security (HSTS) on the web server

To protect Zabbix frontend against protocol downgrade attacks, we recommend enabling the HSTS policy on the web server.

To enable the HSTS policy 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/Ubuntu

2. Add the following directive to your virtual host's configuration file:

<VirtualHost *:*>
           Header set Strict-Transport-Security "max-age=31536000"
       </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

Enabling Content Security Policy (CSP) on the web server

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.

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/Ubuntu

2. 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

Disabling web server information exposure

To improve security, disabling all web server signatures is recommended.

By default, the web server is exposing the software signature:

The signature can be disabled by adding the following parameters to the Apache configuration file:

ServerSignature Off
       ServerTokens Prod

PHP signature (X-Powered-By HTTP header) can be disabled by changing the php.ini configuration file (by default, the signature is disabled):

expose_php = Off

Web server restart is required for configuration file changes to be applied.

For additional security, you can use the mod_security tool with Apache (package libapache2-mod-security2). This tool allows removing the server signature instead of removing only the version from the server signature. The server signature can be changed to any value by setting "SecServerSignature" to any desired value after installing mod_security.

Please refer to the documentation of your web server to find help on how to remove/change software signatures.

Disabling web server default error pages

To avoid information exposure, disabling the default error pages is recommended.

By default, a web server uses built-in error pages:

These default error pages should be replaced/removed. For example, the "ErrorDocument" directive can be used to define a custom error page/text for the Apache web server.

Please refer to the documentation of your web server to find help on how to replace/remove default error pages.

Removing web server test page

To avoid information exposure, removing the web server test page is recommended.

By default, the Apache web server webroot contains the index.html test page:

Please refer to the documentation of your web server to find help on how to remove default test pages.

Set X-Frame-Options HTTP response header

By default, Zabbix is configured with the Use X-Frame-Options HTTP header parameter set to SAMEORIGIN. This means that content can only be loaded in a frame that has the same origin as the page itself.

Zabbix frontend elements that pull content from external URLs (namely, the URL dashboard widget) display retrieved content in a sandbox with all sandboxing restrictions enabled.

These settings enhance the security of the Zabbix frontend and provide protection against XSS and clickjacking attacks. Super admin users can modify the Use iframe sandboxing and Use X-Frame-Options HTTP header parameters as needed. Please carefully weigh the risks and benefits before changing default settings. Turning iframe sandboxing or X-Frame-Options HTTP header off completely is not recommended.

Hiding the file with list of common passwords

To increase the complexity of password brute force attacks, limiting access to the ui/data/top_passwords.txt file is recommended. This file contains a list of the most common and context-specific passwords and prevents users from setting such passwords (if the Avoid easy-to-guess passwords parameter is enabled in the password policy).

To limit access to the top_passwords.txt file, modify your web server configuration.

On Apache, file access can be limited using the .htaccess file:

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

On NGINX, file access can be limited using the location directive:

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