[comment]: # ({b5ee9cfc-7ef4b2b9})
# 2 Best practices for secure Zabbix setup

[comment]: # ({/b5ee9cfc-7ef4b2b9})

[comment]: # ({0bf6833f-b9719f19})
### Overview

This section contains best practices that should be observed in order to
set up Zabbix in a secure way.

The practices contained here are not required for the functioning of
Zabbix. They are recommended for better security of the system.

[comment]: # ({/0bf6833f-b9719f19})

[comment]: # ({4fc29cb0-cebf8306})
### Access control

[comment]: # ({/4fc29cb0-cebf8306})

[comment]: # ({2e580f77-dc572a02})
#### Principle of least privilege

The principle of least privilege should be used at all times for Zabbix.
This principle means that user accounts (in Zabbix frontend) or process
user (for Zabbix server/proxy or agent) have only those privileges that
are essential to perform intended functions. In other words, user
accounts at all times should run with as few privileges as possible.

::: noteimportant
Giving extra permissions to 'zabbix' user will
allow it to access configuration files and execute operations that can
compromise the overall security of the infrastructure.
:::

When implementing the least privilege principle for user accounts,
Zabbix [frontend user
types](/manual/config/users_and_usergroups/permissions) should be taken
into account. It is important to understand that while a "Admin" user
type has less privileges than "Super Admin" user type, it has
administrative permissions that allow managing configuration and execute
custom scripts.

::: noteclassic
Some information is available even for non-privileged users.
For example, while *Alerts* → *Scripts* is not available for
non-Super Admins, scripts themselves are available for retrieval by
using Zabbix API. Limiting script permissions and not adding sensitive
information (like access credentials, etc) should be used to avoid
exposure of sensitive information available in global
scripts.
:::

[comment]: # ({/2e580f77-dc572a02})

[comment]: # ({1631be73-1631be73})
#### Secure user for Zabbix agent

In the default configuration, Zabbix server and Zabbix agent processes
share one 'zabbix' user. If you wish to make sure that the agent cannot
access sensitive details in server configuration (e.g. database login
information), the agent should be run as a different user:

1.  Create a secure user
2.  Specify this user in the agent [configuration
    file](/manual/appendix/config/zabbix_agentd) ('User' parameter)
3.  Restart the agent with administrator privileges. Privileges will be
    dropped to the specified user.

[comment]: # ({/1631be73-1631be73})

[comment]: # ({ca754ae9-c02c850f})
#### Revoke write access to SSL configuration (Windows)

If you have compiled Zabbix agent on Windows, with OpenSSL located in an
unprotected directory (e.g., `c:\openssl-64bit`, `C:\OpenSSL-Win64-111-static`,
or `C:\dev\openssl`), make sure to revoke write access from non-administrator
users to this directory. Otherwise, the agent loads SSL settings from a path
that can be modified by unprivileged users, resulting in a potential security
vulnerability.

[comment]: # ({/ca754ae9-c02c850f})

[comment]: # ({5dd6aee8-6cfe5a3b})
### Cryptography

[comment]: # ({/5dd6aee8-6cfe5a3b})

[comment]: # ({5aa469c4-f8f5054e})
#### Setting up SSL for Zabbix frontend

On RHEL-based systems, install the `mod_ssl` package:

```bash
dnf install mod_ssl
```

Create a directory for SSL keys:

```bash
mkdir -p /etc/httpd/ssl/private
chmod 700 /etc/httpd/ssl/private
```

Create the SSL certificate:

```bash
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/httpd/ssl/private/apache-selfsigned.key -out /etc/httpd/ssl/apache-selfsigned.crt
```

Fill out the prompts appropriately.
The most important line is the one that requests the `Common Name`.
You need to enter the domain name that you want to be associated with your server.
You can enter the public IP address instead if you do not have a domain name.

```ini
Country Name (2 letter code) [XX]:
State or Province Name (full name) []:
Locality Name (eg, city) [Default City]:
Organization Name (eg, company) [Default Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:example.com
Email Address []:
```

Edit the Apache SSL configuration file (`/etc/httpd/conf.d/ssl.conf`):

```ini
DocumentRoot "/usr/share/zabbix"
ServerName example.com:443
SSLCertificateFile /etc/httpd/ssl/apache-selfsigned.crt
SSLCertificateKeyFile /etc/httpd/ssl/private/apache-selfsigned.key
```

Restart the Apache service to apply the changes:

```bash
systemctl restart httpd.service
```

[comment]: # ({/5aa469c4-f8f5054e})

[comment]: # ({bfaa999a-40cfdec2})
### Web server hardening

[comment]: # ({/bfaa999a-40cfdec2})

[comment]: # ({56ed21db-bb3706f4})
#### 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 permanent redirect for document root to Zabbix SSL URL.
Note that *example.com* should be replaced with the actual name of the server.

```ini
# Add lines:

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

Restart the Apache service to apply the changes:

```bash
systemctl restart httpd.service
```

[comment]: # ({/56ed21db-bb3706f4})

[comment]: # ({fa3fd73b-c7ee0bb2})
#### Enabling HTTP Strict Transport Security (HSTS) on the web server

To protect Zabbix frontend against protocol downgrade attacks, we recommend enabling [HSTS](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) policy on the web server.

To enable 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:

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

3\. Restart the Apache service to apply the changes:

```bash
# On RHEL-based systems:
systemctl restart httpd.service

# On Debian/Ubuntu
systemctl restart apache2.service
```

[comment]: # ({/fa3fd73b-c7ee0bb2})

[comment]: # ({31e3d90b-0aad5c50})
#### 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](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy).

::: noteimportant
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*](/manual/web_interface/frontend_sections/dashboards/widgets/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/Ubuntu

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

```ini
<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:

```bash
# On RHEL-based systems:
systemctl restart httpd.service

# On Debian/Ubuntu
systemctl restart apache2.service
```

[comment]: # ({/31e3d90b-0aad5c50})

[comment]: # ({486f4b5d-cd09dcd1})
#### Disabling web server information exposure

It is recommended to disable all web server signatures as part of the
web server hardening process. The web server is exposing software
signature by default:

![](../../../../assets/en/manual/installation/requirements/software_signature.png)

The signature can be disabled by adding two lines to the Apache (used as
an example) configuration file:

```ini
ServerSignature Off
ServerTokens Prod
```

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

```ini
expose_php = Off
```

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

Additional security level can be achieved by using the mod\_security
(package libapache2-mod-security2) with Apache. mod\_security allows to
remove server signature instead of only removing version from server
signature. Signature can be altered to any value by changing
"SecServerSignature" to any desired value after installing
mod\_security.

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

[comment]: # ({/486f4b5d-cd09dcd1})

[comment]: # ({720052da-720052da})
#### Disabling default web server error pages

It is recommended to disable default error pages to avoid information
exposure. Web server is using built-in error pages by default:

![](../../../../assets/en/manual/installation/requirements/error_page_text.png)

Default error pages should be replaced/removed as part of the web server
hardening process. The "ErrorDocument" directive can be used to define a
custom error page/text for Apache web server (used as an example).

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

[comment]: # ({/720052da-720052da})

[comment]: # ({ba1547c0-ba1547c0})
#### Removing web server test page

It is recommended to remove the web server test page to avoid
information exposure. By default, web server webroot contains a test
page called index.html (Apache2 on Ubuntu is used as an example):

![](../../../../assets/en/manual/installation/requirements/test_page.png)

The test page should be removed or should be made unavailable as part of
the web server hardening process.

[comment]: # ({/ba1547c0-ba1547c0})

[comment]: # ({828c10d5-7e4e4a45})
#### Set X-Frame-Options HTTP response header

By default, Zabbix is configured with X-Frame-Options HTTP header* 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](/manual/web_interface/frontend_sections/dashboards/widgets/url)) 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](/manual/web_interface/frontend_sections/administration/general#security) 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.

[comment]: # ({/828c10d5-7e4e4a45})

[comment]: # ({fb7d0785-3f76ae70})
#### Hiding the file with list of common passwords

To increase the complexity of password brute force attacks, it is
suggested to limit access to the file `ui/data/top_passwords.txt` by
modifying web server configuration. This file contains a list of the
most common and context-specific passwords, and is used to prevent users
from setting such passwords if *Avoid easy-to-guess passwords* parameter
is enabled in the [password
policy](/manual/web_interface/frontend_sections/users/authentication#internal_authentication).

For example, on NGINX file access can be limited by using the `location`
directive:

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

On Apache - by using `.htaccess` file:

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

[comment]: # ({/fb7d0785-3f76ae70})

[comment]: # ({b57e9136-40e70f9e})
### UTF-8 encoding

UTF-8 is the only encoding supported by Zabbix. It is known to work
without any security flaws. Users should be aware that there are known
security issues if using some of the other encodings.

[comment]: # ({/b57e9136-40e70f9e})

[comment]: # ({55965c98-62eeb2ec})
### Windows installer paths
When using Windows installers, it is recommended to use default paths provided by the installer as using custom paths without proper permissions could compromise the security of the installation.

[comment]: # ({/55965c98-62eeb2ec})

[comment]: # ({7c192639-ba0d4036})

### Zabbix Security Advisories and CVE database

See [Zabbix Security Advisories and CVE database](https://www.zabbix.com/security_advisories).

[comment]: # ({/7c192639-ba0d4036})