Por que o hardening importa no Bitrix24 self-hosted
Na versão cloud, a Bitrix cuida da camada de infraestrutura. No modelo self-hosted (on-premise), toda a responsabilidade de segurança recai sobre o time técnico do cliente ou do integrador. Em auditorias conduzidas pela ACP Group, identificamos padrões recorrentes: ambiente web desatualizado, erros de PHP expostos ao navegador, banco de dados com configurações de fábrica inseguras e ausência de autenticação em dois fatores — frequentemente em simultâneo no mesmo servidor.
O resultado prático: em uma auditoria típica de portal de médio porte (base de dados de ~28 GB, 16 vCPUs, 47 GB de RAM), o scanner de segurança nativo do Bitrix24 identificou 5 ameaças, sendo 3 críticas, antes mesmo de completar a varredura — que foi interrompida por erros de configuração no próprio servidor.
O fluxo abaixo ilustra as três camadas de controle que estruturam este checklist:
O hardening segue uma lógica de camadas: primeiro o sistema operacional e o ambiente web, depois a aplicação Bitrix24 e seu banco de dados e, por fim, os controles de acesso e monitoramento contínuo. Corrigi as camadas na ordem errada — por exemplo, ativar 2FA antes de atualizar o PHP — reduz o efeito de cada medida.
flowchart TD
A[Camada 1: SO e Ambiente Web] --> B[Camada 2: Aplicação Bitrix24 e BD]
B --> C[Camada 3: Acesso, Autenticação e Monitoramento]
A --> A1[OS atualizado]
A --> A2[nginx / Apache / PHP atualizados]
A --> A3[HSTS + redirect HTTPS]
B --> B1[Módulos Bitrix24 atualizados]
B --> B2[PHP: display_errors OFF]
B --> B3[BD: local_infile OFF, query_cache OFF]
C --> C1[2FA para todos os usuários]
C --> C2[Acesso à adminke restrito por IP]
C --> C3[Scanner de segurança periódico]
Camada 1 — Sistema operacional e ambiente web (pontos 1–5)
No Bitrix24 self-hosted, SO e servidor web desatualizados são a principal porta de entrada para ataques: em auditorias reais encontramos nginx 1.20.2, Apache 2.4.6, PHP 8.1 e Percona 5.7 simultâneos — cada gap representando meses de patches de segurança não aplicados, todos classificados como prioridade Crítica.
Esta é a base de tudo. Versões antigas de OS e de servidores web carregam CVEs conhecidas que ferramentas automatizadas exploram em minutos.
| # | Controle | Prioridade | Complexidade |
|---|---|---|---|
| 1 | Atualizar SO para versão suportada (ex.: da série 7 para série 9) | Crítico | Alta |
| 2 | Atualizar nginx para versão estável atual | Crítico | Alta |
| 3 | Atualizar Apache para versão atual | Crítico | Alta |
| 4 | Atualizar PHP para versão suportada (8.2+) | Crítico | Alta |
| 5 | Atualizar SGBD (Percona/MySQL) para versão 8.x | Crítico | Alta |
Referência de versões: Em um servidor auditado recentemente, encontramos nginx 1.20.2 (atual: 1.26.x), Apache 2.4.6 (atual: 2.4.62), PHP 8.1.x (atual: 8.2.x) e Percona 5.7 (atual: 8.0). Cada um desses gaps representa meses ou anos de patches de segurança não aplicados.
Boa prática: ao provisionar um novo servidor, utilize a imagem de máquina virtual oficial do Bitrix24 — ela parte de um baseline já alinhado com as versões recomendadas pelo fabricante.
Camada 2 — Configuração do PHP (pontos 6–8)
A configuração do PHP em modo desenvolvimento em produção expõe ao navegador caminhos de arquivos, queries SQL e estrutura do banco de dados; desabilitar display_errors e display_startup_errors é a correção de maior impacto e menor complexidade desta camada, classificada como prioridade Alta.
Ponto 6 — Desabilitar display_errors
Com display_errors = On e display_startup_errors = On ativos, qualquer erro de runtime expõe ao navegador: caminhos absolutos de arquivos, queries SQL, estrutura do banco de dados e informações sobre a configuração do servidor. Desative ambas as diretivas no php.ini de produção:
display_errors = Off
display_startup_errors = Off
Ponto 7 — Revisar error_reporting e log_errors
Erros devem ir para o log do servidor, não para o cliente. Configure log_errors = On e aponte error_log para um arquivo com permissões restritas.
Ponto 8 — Auditar extensões PHP carregadas
Remova ou desabilite extensões não utilizadas pelo Bitrix24. Cada extensão ativa é superfície de ataque adicional.
Camada 3 — Configuração do banco de dados (pontos 9–12)
As configurações padrão do MySQL/Percona priorizam compatibilidade, não segurança: local_infile habilitado permite leitura arbitrária de arquivos, e em auditoria real encontramos a senha do usuário root do banco em branco — cenário de risco máximo que qualquer processo local explora sem autenticação.
| # | Parâmetro | Ação | Motivo |
|---|---|---|---|
| 9 | local_infile |
Desabilitar (OFF) |
Permite leitura arbitrária de arquivos do servidor |
| 10 | query_cache |
Desabilitar | Obsoleto no MySQL 8.x; gera contenção |
| 11 | innodb_log_file_size |
Aumentar (mín. 256 MB) | Valor de 64 MB causa I/O excessivo e instabilidade |
| 12 | Usuário root do banco | Senha forte + acesso apenas local | Credenciais padrão ou fracas são exploradas ativamente |
Atenção crítica: Durante uma migração de servidor documentada internamente, encontramos o campo password do usuário root do banco em branco no arquivo de configuração da aplicação. Este é o cenário de risco máximo — qualquer processo local consegue acesso total ao banco sem autenticação.
Também verifique os tamanhos de buffer (join_buffer_size, sort_buffer_size) — valores muito grandes (ex.: 32 MB cada) indicam tentativas de tunning manual que podem mascarar outros problemas de configuração.
Camada 4 — Segurança da aplicação Bitrix24 (pontos 13–18)
Com o ambiente saneado, os controles nativos do Bitrix24 — proteção proativa no nível recomendado pelo fabricante, 2FA obrigatório para todos os usuários, módulos atualizados, HSTS e X-Frame-Options — reduzem drasticamente a superfície de ataque na camada de aplicação, com complexidade predominantemente Baixa.
Ponto 13 — Elevar o nível de proteção proativa
O Bitrix24 possui um módulo de "Proteção Proativa" com diferentes níveis de rigidez. Em auditorias, frequentemente encontramos o nível mínimo ativo — abaixo do padrão recomendado pelo fabricante. Eleve para o nível padrão ou superior e revise as políticas de segurança do grupo de administradores.
Ponto 14 — Ativar 2FA para todos os usuários
A autenticação em dois fatores via aplicativo OTP deve ser obrigatória, não opcional. Isso vale especialmente para contas de administrador. O Bitrix24 possui suporte nativo a 2FA — basta habilitá-lo nas configurações de segurança do portal.
Ponto 15 — Atualizar módulos e núcleo do Bitrix24
Módulos desatualizados são vetores de ataque conhecidos. Verifique e aplique atualizações pendentes pelo painel administrativo do Bitrix24 regularmente.
Ponto 16 — Adicionar cabeçalho HSTS e forçar HTTPS
Configure o cabeçalho Strict-Transport-Security no nginx ou Apache e garanta que todo tráfego HTTP seja redirecionado para HTTPS. Sem HSTS, um atacante em posição de man-in-the-middle pode fazer downgrade da conexão.
Exemplo para nginx:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
Ponto 17 — Proteção contra clickjacking (X-Frame-Options)
Ative a proteção contra uso do portal em iframes — prevenindo ataques de clickjacking. Configure o cabeçalho X-Frame-Options: SAMEORIGIN no servidor web ou via as configurações de segurança do Bitrix24.
Ponto 18 — Considerar o Web Antivírus nativo
O Bitrix24 self-hosted inclui um módulo de web antivírus. Avalie o trade-off: ele aumenta a segurança, mas reduz o desempenho do portal. Em servidores com folga de CPU (como o caso de 16 vCPUs documentado), o impacto tende a ser aceitável.
Camada 5 — Controle de acesso e rede (pontos 19–22)
Restringir a superfície de exposição é tão eficaz quanto corrigir vulnerabilidades: limitar /bitrix/admin/ a IPs corporativos via firewall, manter blacklist atualizada com fail2ban, desabilitar listagem de diretórios e restringir permissões de arquivos de configuração para 600 são os 4 controles desta camada.
Ponto 19 — Restringir acesso à área administrativa por IP
O painel /bitrix/admin/ deve ser acessível apenas de IPs corporativos conhecidos. Configure isso no firewall do servidor ou via regras no nginx/Apache. Em um modelo de trabalho remoto, use VPN como gateway — não exponha o admin publicamente.
Ponto 20 — Manter blacklist de IPs no firewall
Implemente e atualize regularmente uma lista de bloqueio de IPs de onde partem tentativas de ataque, injeção e varredura. Ferramentas como fail2ban automatizam parte desse processo.
Ponto 21 — Desabilitar listagem de diretórios
Garanta que Options -Indexes esteja ativo no .htaccess — impede que um atacante navegue pela estrutura de arquivos do servidor em caso de URL mal configurada.
Ponto 22 — Revisar permissões de arquivos e diretórios
Arquivos de configuração (dbconn.php, .settings.php) devem ter permissões restritivas (600 ou 640). O usuário web (www-data / nginx) não deve ter acesso de escrita a diretórios fora do necessário.
Camada 6 — Auditoria de modificações no núcleo (pontos 23–24)
Customizações diretas no núcleo do Bitrix24 introduzem vulnerabilidades e bloqueiam atualizações: em auditoria real, o Monitor de Qualidade identificou 23 arquivos modificados em 109.188 (0,02%), distribuídos por 6 módulos — cada arquivo alterado exige revisão, documentação e registro em controle de versão.
Ponto 23 — Auditar arquivos modificados com o Monitor de Qualidade
O Bitrix24 possui uma ferramenta de "Monitor de Qualidade" que compara os arquivos instalados com os originais do fabricante. Em um portal auditado, 23 arquivos de 109.188 foram modificados (0,02%) — distribuídos por 6 módulos (CRM, IM, extranet, location, socialnetwork, tasks, vote).
O nível de modificação foi classificado como BAIXO, mas cada arquivo alterado precisa ser: - Revisado para confirmar que a modificação é intencional e documentada - Verificado para garantir que não introduz backdoors ou vulnerabilidades - Registrado no controle de versão da empresa
Ponto 24 — Auditar componentes customizados de terceiros
Componentes de terceiros instalados no portal (identificáveis pelo prefixo diferente de bitrix: no nome do componente) devem ser revisados quanto à necessidade, funcionalidade e segurança. Se um componente não está em uso ou não tem documentação clara, considere desabilitá-lo.
Camada 7 — Verificação contínua e pós-correção (ponto 25)
A verificação contínua fecha o ciclo de hardening: o scanner nativo do Bitrix24 deve ser reexecutado após cada conjunto de correções — em portais com erros graves ele aborta antes de concluir, subestimando o total de vulnerabilidades — com rotina mínima trimestral em produção e obrigatória após cada atualização.
Ponto 25 — Repetir o scan de segurança após cada ciclo de correções
O scanner de segurança nativo do Bitrix24 deve ser executado após cada conjunto de correções aplicadas. Em portais com erros de configuração graves, o scanner pode abortar antes de concluir — o que significa que o número real de vulnerabilidades pode ser maior do que o relatado. Corrija os bloqueadores (php.ini, cache) e reexecute.
Estabeleça uma rotina de auditoria: no mínimo trimestral para portais em produção, e sempre após atualizações de módulos ou mudanças de infraestrutura.
Resumo executivo: checklist por prioridade
Este checklist de 25 pontos, derivado de auditoria real em portal com ~28 GB de dados, consolida os controles de hardening do Bitrix24 self-hosted por prioridade: 6 itens Críticos (SO, servidores web, PHP, SGBD e senha do banco), 12 de prioridade Alta e 7 de prioridade Média ou Baixa.
A tabela abaixo consolida os 25 pontos com prioridade e complexidade estimada, derivados diretamente de dados de auditoria real:
| # | Controle | Prioridade | Complexidade |
|---|---|---|---|
| 1 | Atualizar SO | Crítico | Alta |
| 2 | Atualizar nginx | Crítico | Alta |
| 3 | Atualizar Apache | Crítico | Alta |
| 4 | Atualizar PHP | Crítico | Alta |
| 5 | Atualizar SGBD | Crítico | Alta |
| 6 | Desabilitar display_errors | Alto | Baixa |
| 7 | Configurar log_errors | Alto | Baixa |
| 8 | Auditar extensões PHP | Médio | Baixa |
| 9 | Desabilitar local_infile | Alto | Média |
| 10 | Desabilitar query_cache | Alto | Média |
| 11 | Aumentar innodb_log_file_size | Alto | Média |
| 12 | Senha forte no BD + acesso local | Crítico | Baixa |
| 13 | Elevar nível de proteção proativa | Alto | Média |
| 14 | Ativar 2FA para todos os usuários | Alto | Baixa |
| 15 | Atualizar módulos Bitrix24 | Médio | Baixa |
| 16 | HSTS + redirect HTTPS | Alto | Baixa |
| 17 | X-Frame-Options (anti-clickjacking) | Baixo | Baixa |
| 18 | Avaliar Web Antivírus nativo | Baixo | Baixa |
| 19 | Restringir admin por IP | Alto | Média |
| 20 | Blacklist de IPs no firewall | Médio | Média |
| 21 | Desabilitar listagem de diretórios | Alto | Baixa |
| 22 | Revisar permissões de arquivos | Alto | Média |
| 23 | Auditar arquivos modificados | Médio | Média |
| 24 | Auditar componentes de terceiros | Médio | Baixa |
| 25 | Repetir scan pós-correções | Médio | Baixa |
Para uma análise completa dos custos e escopo de uma implementação segura desde o início, veja nosso guia de custos e prazos de implementação do Bitrix24. Se você está planejando mover dados de outro CRM para o Bitrix24 self-hosted, o plano de migração do Bitrix24 Cloud para self-hosted cobre as considerações de segurança específicas desse processo.
Para quem está dimensionando o hardware do servidor antes de aplicar estas configurações, consulte o guia de dimensionamento de hardware para 50 a 1.000 usuários. E se integração com Active Directory e SSO está no escopo do projeto, veja o artigo sobre Active Directory, LDAP e SSO com Bitrix24 self-hosted — autenticação centralizada facilita a aplicação de políticas como 2FA obrigatório.