Em sistemas baseados em RHEL, adicione um host virtual à configuração do Apache (/etc/httpd/conf/httpd.conf) e defina um redirecionamento permanente para a raiz do documento para a URL SSL do Zabbix. Observe que example.com deve ser substituído pelo nome real do servidor.

# Adicione as linhas:

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

Reinicie o serviço Apache para aplicar as alterações:

systemctl restart httpd.service

Ativando HTTP Strict Transport Security (HSTS) no servidor web

Para proteger o frontend do Zabbix contra ataques de downgrade de protocolo, recomendamos ativar a política HSTS no servidor web.

Para ativar a política HSTS para o seu frontend do Zabbix na configuração do Apache, siga estas etapas:

1. Localize o arquivo de configuração do seu virtual host:

/etc/httpd/conf/httpd.conf em sistemas baseados em RHEL
/etc/apache2/sites-available/000-default.conf no Debian/Ubuntu

2. Adicione a seguinte diretiva ao arquivo de configuração do seu virtual host:

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

3. Reinicie o serviço Apache para aplicar as alterações:

# Em sistemas baseados em RHEL:
systemctl restart httpd.service

# No Debian/Ubuntu
systemctl restart apache2.service

Aplicando cookies de sessão Secure e SameSite no Zabbix

Ao configurar o Zabbix, é essencial aplicar os atributos Secure e SameSite para cookies de sessão, a fim de aumentar a segurança e evitar ataques de falsificação de solicitação entre sites (CSRF). No entanto, aplicar SameSite=Strict pode causar problemas em determinados cenários, como:

Widgets de URL no dashboard exibindo "usuário não autenticado" ao incorporar iframes do mesmo domínio.
Usuários acessando o dashboard via HTTP em vez de HTTPS podem enfrentar problemas de login.
Impossibilidade de compartilhar URLs para seções específicas do menu do Zabbix ou hosts.

Para mitigar esses problemas, os usuários devem ter uma forma de ajustar a política SameSite.

1. Cookies seguros

Definir o parâmetro secure garante que os cookies sejam transmitidos apenas via HTTPS, evitando exposição em conexões não criptografadas.

Para habilitar cookies seguros no Zabbix, adicione ou modifique a seguinte configuração no servidor web:

Para Apache:

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

Para Nginx:

proxy_cookie_path / "/; Secure";

Certifique-se de que o frontend do Zabbix seja acessado via HTTPS; caso contrário, cookies com o parâmetro Secure não serão enviados.

2. Configurando o atributo SameSite

As configurações do servidor web também podem aplicar o atributo SameSite:

Para Apache:

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

Para Nginx (versão 1.19.3+):

proxy_cookie_flags ~ samesite=Strict; # Substitua ~ por 'zbx_session' para especificidade

Habilitando a Política de Segurança de Conteúdo (CSP) no servidor web

Para proteger o frontend do Zabbix contra Cross Site Scripting (XSS), injeção de dados e ataques semelhantes, recomendamos habilitar a Política de Segurança de Conteúdo no servidor web. Para isso, configure o servidor web para retornar o cabeçalho HTTP.

A configuração de cabeçalho CSP a seguir é apenas para a instalação padrão do frontend do Zabbix e para casos em que todo o conteúdo se origina do domínio do site (excluindo subdomínios). Uma configuração diferente de cabeçalho CSP pode ser necessária se você estiver, por exemplo, configurando o widget URL para exibir conteúdo dos subdomínios do site ou domínios externos, trocando o OpenStreetMap por outro mecanismo de mapa ou adicionando CSS ou widgets externos. Se você estiver usando o método de autenticação multifator Duo Universal Prompt, certifique-se de adicionar "duo.com" à diretiva CSP no arquivo de configuração do seu host virtual.

Para habilitar o CSP para seu frontend do Zabbix na configuração do Apache, siga estas etapas:

1. Localize o arquivo de configuração do seu host virtual:

/etc/httpd/conf/httpd.conf em sistemas baseados em RHEL
/etc/apache2/sites-available/000-default.conf no Debian/Ubuntu

2. Adicione a seguinte diretiva ao arquivo de configuração do seu host virtual:

<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. Reinicie o serviço Apache para aplicar as alterações:

# Em sistemas baseados em RHEL:
systemctl restart httpd.service

# No Debian/Ubuntu
systemctl restart apache2.service

Desabilitando a exposição de informações do servidor web

Para melhorar a segurança, recomenda-se desabilitar todas as assinaturas do servidor web.

Por padrão, o servidor web expõe a assinatura do software:

A assinatura pode ser desabilitada adicionando os seguintes parâmetros ao arquivo de configuração do Apache:

ServerSignature Off
ServerTokens Prod

A assinatura do PHP (cabeçalho HTTP X-Powered-By) pode ser desabilitada alterando o arquivo de configuração php.ini (por padrão, a assinatura está desabilitada):

expose_php = Off

É necessário reiniciar o servidor web para que as alterações no arquivo de configuração sejam aplicadas.

Para segurança adicional, você pode usar a ferramenta mod_security com o Apache (pacote libapache2-mod-security2). Esta ferramenta permite remover a assinatura do servidor em vez de remover apenas a versão da assinatura do servidor. A assinatura do servidor pode ser alterada para qualquer valor definindo "SecServerSignature" para qualquer valor desejado após instalar o mod_security.

Consulte a documentação do seu servidor web para obter ajuda sobre como remover/alterar assinaturas de software.

Desabilitando as páginas de erro padrão do servidor web

Para evitar a exposição de informações, recomenda-se desabilitar as páginas de erro padrão.

Por padrão, um servidor web usa páginas de erro internas:

Essas páginas de erro padrão devem ser substituídas/removidas. Por exemplo, a diretiva "ErrorDocument" pode ser usada para definir uma página/texto de erro personalizado para o servidor web Apache.

Consulte a documentação do seu servidor web para obter ajuda sobre como substituir/remover as páginas de erro padrão.

Removendo a página de teste do servidor web

Para evitar a exposição de informações, recomenda-se remover a página de teste do servidor web.

Por padrão, o diretório webroot do servidor web Apache contém a página de teste index.html:

Consulte a documentação do seu servidor web para obter ajuda sobre como remover as páginas de teste padrão.

Definir o cabeçalho de resposta HTTP X-Frame-Options

Por padrão, o Zabbix é configurado com o parâmetro Usar cabeçalho HTTP X-Frame-Options definido como SAMEORIGIN. Isso significa que o conteúdo só pode ser carregado em um frame que tenha a mesma origem da própria página.

Os elementos do frontend do Zabbix que puxam conteúdo de URLs externas (nomeadamente, o widget de dashboard de URL) exibem o conteúdo recuperado em uma sandbox com todas as restrições de sandboxing ativadas.

Essas configurações aumentam a segurança do frontend do Zabbix e fornecem proteção contra ataques XSS e clickjacking. Usuários Super admin podem modificar os parâmetros Usar sandboxing de iframe e Usar cabeçalho HTTP X-Frame-Options conforme necessário. Por favor, avalie cuidadosamente os riscos e benefícios antes de alterar as configurações padrão. Não é recomendado desativar completamente o sandboxing de iframe ou o cabeçalho HTTP X-Frame-Options.

Ocultando o arquivo com a lista de senhas comuns

Para aumentar a complexidade dos ataques de força bruta de senha, é recomendável limitar o acesso ao arquivo ui/data/top_passwords.txt. Este arquivo contém uma lista das senhas mais comuns e específicas de contexto e impede que os usuários definam tais senhas (se o parâmetro Evitar senhas fáceis de adivinhar estiver habilitado na política de senha).

Para limitar o acesso ao arquivo top_passwords.txt, modifique a configuração do seu servidor web.

No Apache, o acesso ao arquivo pode ser limitado usando o arquivo .htaccess:

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

No NGINX, o acesso ao arquivo pode ser limitado usando a diretiva location:

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

What’s next?

2 Melhores práticas de configuração

Docs

3 Servidor web

Visão geral

Forçando o redirecionamento da URL raiz para o Zabbix SSL