Áú»¢¶Ä²©

Esta ¨¦ uma tradu??o da p¨¢gina de documenta??o original em ingl¨ºs. Ajude-nos a torn¨¢-la melhor.

2 Melhores pr¨¢ticas para configura??o segura do Áú»¢¶Ä²©

Vis?o geral

Esta se??o cont¨¦m boas pr¨¢ticas que devem ser observadas de modo a configurar o Áú»¢¶Ä²© de uma forma segura.

As pr¨¢ticas contidas aqui n?o s?o necess¨¢rias para o funcionamento do Áú»¢¶Ä²©. 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 Áú»¢¶Ä²©. Este princ¨ªpio implica que contas de usu¨¢rio (no Áú»¢¶Ä²© Frontend) ou usu¨¢rios de processo (para Áú»¢¶Ä²© 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.

Fornecer permiss?es extras ao usu¨¢rio 'zabbix' permitir¨¢ que este acesse os arquivos de configura??o e execute opera??es que podem comprometer a seguran?a geral da infraestrutura.

Quando implementando o princ¨ªpio de m¨ªnimo privil¨¦gio para contas de usu¨¢rio, os tipos de usu¨¢rio do frontend do Áú»¢¶Ä²© 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.

Algumas informa??es est?o dispon¨ªveis at¨¦ mesmo para usu¨¢rios sem privil¨¦gio. Por exemplo, conquanto Administra??o ¡ú Scripts esteja dispon¨ªvel apenas para usu¨¢rios Super Admins, os pr¨®prios scripts est?o dispon¨ªveis para recupera??o atrav¨¦s do uso da API do Áú»¢¶Ä²©. Limita??o nas permiss?es dos scripts e a n?o adi??o de informa??es sens¨ªveis (como credenciais de acesso, etc) devem ser consideradas para evitar a exposi??o de informa??es sens¨ªveis existentes nos scripts globais.

±«²õ³Ü¨¢°ù¾±´Ç seguro para Áú»¢¶Ä²© Agent

Na configura??o padr?o, os processos do Áú»¢¶Ä²© Server e Áú»¢¶Ä²© 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.

Áú»¢¶Ä²© Windows Agent com OpenSSL

O Áú»¢¶Ä²© 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

Configurando SSL para Áú»¢¶Ä²© 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 Áú»¢¶Ä²© 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 Áú»¢¶Ä²©. 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 Áú»¢¶Ä²© Frontend contra ataques de rebaixamento de protocolo, n¨®s recomendamos habilitar a pol¨ªtica de no servidor web.

Por exemplo, para habilitar a pol¨ªtica HSTS para seu Áú»¢¶Ä²© 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

Enforcing Secure and SameSite Session Cookies in Áú»¢¶Ä²©

When configuring Áú»¢¶Ä²©, it is essential to enforce secure and SameSite attributes for session cookies to enhance security and prevent cross-site request forgery (CSRF) attacks. However, enforcing SameSite=Strict may cause issues in certain scenarios, such as:

  • Dashboard URL widgets displaying "user not logged in" when embedding same-domain iframes.
  • Users accessing the dashboard via HTTP instead of HTTPS may face login issues.
  • Inability to share URLs to specific Áú»¢¶Ä²© menu sections or hosts.

To mitigate these issues, users should have a way to adjust the SameSite policy.

1. Secure Cookies

Setting the secure flag ensures that cookies are only transmitted over HTTPS, preventing exposure over unencrypted connections.

To enable secure cookies in Áú»¢¶Ä²©, add or modify the following setting in the web server configuration:

For Apache:

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

For Nginx:

proxy_cookie_path / "/; Secure";

Ensure that your Áú»¢¶Ä²© frontend is accessed via HTTPS; otherwise, cookies with the Secure flag will not be sent.

2. Configuring the SameSite Attribute

Web server settings can also enforce the SameSite attribute:

For Apache:

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

For Nginx (version 1.19.3+):

proxy_cookie_flags ~ samesite=Strict; # Replace ~ with 'zbx_session' for specificity

Habilitando a Pol¨ªtica de Seguran?a do Conte¨²do no servidor web

Para proteger o frontend Áú»¢¶Ä²© 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 .

A seguinte configura??o do cabe?alho CSP ¨¦ apenas para instala??o do frontend Áú»¢¶Ä²© padr?o e para casos em que todos os conte¨²dos s?o produzidos a partir do dom¨ªnio do site (excluindo subdom¨ªnios). Uma configura??o diferente do cabe?alho CSP pode ser necess¨¢ria se voc¨º estiver, por exemplo, configurando o widget URL para exibir o conte¨²do dos subdom¨ªnios do site ou a partir de dom¨ªnios externos, alternando de OpenStreetMap para um outro mecanismo de mapa, ou adicionando CSS externo ou widgets.

Para habilitar o CSP para seu frontend Áú»¢¶Ä²© 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 Áú»¢¶Ä²©

Por padr?o, o Áú»¢¶Ä²© 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 Áú»¢¶Ä²© 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 Áú»¢¶Ä²© 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.

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>

Codifica??o UTF-8

O UTF-8 ¨¦ o ¨²nico formato de codifica??o suportado pelo Áú»¢¶Ä²©. ? conhecido por operar sem quaisquer falhas de seguran?a. ±«²õ³Ü¨¢°ù¾±´Çs 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 Áú»¢¶Ä²© e banco de dados CVE

Consulte Áú»¢¶Ä²© Security Advisories and CVE database.