3 Servidor web

Visão geral

Esta seção contém as melhores práticas para configurar o servidor web de forma segura.

Habilitando o Zabbix no diretório raiz da URL

Em sistemas baseados em RHEL, adicione um host virtual à configuração do Apache (/etc/httpd/conf/httpd.conf) e defina um redirecionamento permanente do diretório 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.

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;
       }