2 Melhores práticas para configuração segura do Zabbix

Visão geral

Esta seção contém boas práticas que devem ser observadas de modo a configurar o Zabbix de uma forma segura.

As práticas contidas aqui não são necessárias para o funcionamento do Zabbix. Elas são recomendadas para uma melhor segurança do sistema.

Controle de acesso

Princípio do menor privilégio

O princípio do menor privilégio deve ser usado todo o tempo no Zabbix. Este princípio implica que contas de usuário (no Zabbix Frontend) ou usuários de processo (para Zabbix Server/Proxy ou Agent) tenham apenas aqueles privilégios essenciais para executar as funções pretendidas. Em outras palavras, contas de usuário devem fornecer o mínimo de privilégios possível, durante todo o tempo.

Quando implementando o princípio de mínimo privilégio para contas de usuário, os tipos de usuário do frontend do Zabbix devem ser levados em conta. É importante entender que enquanto um usuário do tipo "Admin" tem menos privilégios do um usuário do tipo "Super Admin", ele tem permissões administrativas que o permitem gerenciar configurações e executar scripts customizados.

Usuário seguro para Zabbix Agent

Na configuração padrão, os processos do Zabbix Server e Zabbix Agent compartilham um usuário 'zabbix'. Se você desejar certificar-se de que o Agent não tenha acesso a detalhes sensíveis na configuração do Server (p.e. informações de login do banco de dados), o Agent deve ser executado com um usuário diferente:

1. Crie um usuário seguro
2. Especifique este usuário no arquivo de configuração (parâmetro 'User') do Agent
3. Reinicie o Agent com privilégios de administrador. Estes privilégios serão substituídos pelos privilégios do usuário especificado.

Codificação UTF-8

O UTF-8 é o único formato de codificação suportado pelo Zabbix. É conhecido por operar sem quaisquer falhas de segurança. Usuários devem estar cientes de que há problemas de segurança conhecidos quando usando algum dos outros formatos.

Caminhos para instaladores para Windows

Ao utilizar instaladores para Windows, é recomendável utilizar os caminhos padrão fornecidos pelo instalador. Usar caminhos personalizados sem as permissões adequadas pode comprometer a segurança da instalação.

Avisos de segurança Zabbix e banco de dados CVE

Consulte Zabbix Security Advisories and CVE database.

Configurando SSL para Zabbix Frontend

No RHEL/Centos, instale o pacote mod_ssl:

yum install mod_ssl

Crie diretório para as chaves SSL:

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

Crie o certificado SSL:

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

Preencha cada informação com os dados apropriados. A linha mais importante é a que solicita o Nome Comum (Common Name). Aqui você precisa informar o nome de domínio que deseja que seja associado ao seu servidor. Você pode informar o endereço de IP público caso não tenha um nome de domínio. Neste artigo nós faremos uso do nome example.com.

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 []:

Edite as configurações de SSL do Apache:

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

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

systemctl restart httpd.service

Fortalecimento do servidor Web

Habilitando o Zabbix no diretório raíz da URL

Adicione um virtual host na configuração do Apache e configure um redirecionamento permanente do diretório raíz (DocumentRoot) para a URL com SSL do Zabbix. Não esqueça de substituir example.com pelo nome real do servidor.

/etc/httpd/conf/httpd.conf
       
       #Linhas adicionais
       
       <VirtualHost *:*>
           ServerName example.com
           Redirect permanent / https://example.com
       </VirtualHost>

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

systemctl restart httpd.service && systemctl status httpd.service

Habilitando HTTP Strict Transport Security (HSTS) no servidor web

Para proteger o Zabbix Frontend contra ataques de rebaixamento de protocolo, nós recomendamos habilitar a política de HSTS no servidor web.

Por exemplo, para habilitar a política HSTS para seu Zabbix Frontend na configuração do Apache:

/etc/httpd/conf/httpd.conf

adicione a seguinte diretiva à configuração do seu virtual host:

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

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

systemctl restart httpd.service

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

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

Para habilitar o CSP para seu frontend Zabbix na configuração Apache, siga esses passos:

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

• /etc/httpd/conf/httpd.conf em RHEL-based systems
• /etc/apache2/sites-available/000-default.conf em Debian/Ubuntu

2. Adicione o seguinte diretivo para o seu arquivo de configuração do 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 todas as alterações:

# On RHEL-based systems:
       systemctl restart httpd.service
       
       # On Debian/Ubuntu
       systemctl restart apache2.service

Desabilitando exposição de informação do servidor web

É recomendado desabilitar todas as assinaturas do web server como parte do processo de garantia da segurança. O Web Server expõe sua assinatura de software por padrão:

A assinatura pode ser desabilitada através da adição de duas linhas no arquivo de configuração do Apache, por exemplo::

ServerSignature Off
       ServerTokens Prod

A assinatura do PHP (X-Powered-By HTTP header) pode ser desabilitada pela alteração do arquivo de configuração php.ini (neste caso a assinatura é desabilitada por padrão):

expose_php = Off

Um reinício do Web Server é necessário para que as alterações no arquivo de configuração sejam aplicadas.

Um nível adicional de segurança pode ser alcançado usando mod_security (pacote libapache2-mod-security2) com Apache. O mod_security permite remover toda a assinatura do server em vez de apenas remover a versão. A assinatura pode ser alterada para qualquer valor pela alteração de "SecServerSignature" para um valor desejado após a instalação do mod_security.

Por favor, consulte a documentação do seu Web Server para encontrar auxílio em como remover/alterar as assinaturas de software.

Desabilitando as páginas de erro padrão do Web Server

É recomendado desabilitar as páginas de erro padrão para evitar exposição de informação. O Web Server usa as páginas de erro embutidas por padrão:

Páginas de erro padrão devem ser substituídas/removidas como parte do processo de aprimoramento da segurança. A diretiva "ErrorDocument" pode ser usada para definir uma página/texto de erro customizado para o Apache Web Server (usado como exemplo).

Por favor, consulte a documentação do seu Web Server para encontrar auxílio em como substituir/remover as páginas de erro padrão.

Removendo a página de teste do Web Server

É recomendado remover a página de teste do Web Server para evitar a exposição de informações. Por padrão, o diretório raíz do Web Server contém uma página de teste chamada index.html (usando Apache2 no Ubuntu como exemplo):

A página de teste deve ser removida ou tornada indisponível como parte do processo de aprimoramento da segurança do Web Server.

Configurações do Zabbix

Por padrão, o Zabbix possui a opção X-Frame-Options HTTP response header configurada como SAMEORIGIN, significando que o conteúdo só pode ser carregado em um frame que tenha a mesma origem da página em si.

Os elementos do Zabbix Frontend que buscam conteúdo de URLs externas (especificamente, o widget de URL para dashboard) apresentam o conteúdo encontrado em uma área isolada (sandbox) com todas as restrições habilitadas.

Estas configurações aprimoram a segurança do Zabbix Frontend e proveem proteção contra ataques do tipo XSS e clickjacking. Super Admins podem modificar os parâmetros iframe sandboxing e X-Frame-Options HTTP response header conforme necessário. Por favor, pese cuidadosamente os riscos e benefícios antes de alterar as configurações padrão. Desativar completamente a função de sandboxing ou X-Frame-Options não é recomendado.

Zabbix Windows Agent com OpenSSL

O Zabbix Windows Agent compilado com OpenSSL tentará encontrar o arquivo de configuração SSL em C:\openssl-64bit. O diretório "openssl-64bit" na partição C: pode ser criado por usuários sem privilégio elevado.

Assim, para aprimoramento da segurança, é necessária a criação deste diretório manualmente e então a retirada do acesso de escrita para os usuários que não sejam administradores.

Por favor, note que os nomes do diretório serão diferentes nas versões 32-bit e 64-bit do Windows.

Criptografia

Escondendo o arquivo com lista de senhas comuns

Para aumentar a complexidade dos ataques de força bruta a senhas, sugere-se limitar o acesso ao arquivo ui/data/top_passwords.txt , modificando a configuração do servidor web. Este arquivo contém uma lista de senhas mais comuns e senhas específicas ao contexto, sendo utilizado para evitar que usuários definam tais senhas caso o parâmetro Avoid easy-to-guess passwords esteja habilitado na password policy.

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

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

No Apache - usando o arquivo .htaccess:

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