Migração do Bitrix24 On-Premise: do CentOS 7 para o CentOS Stream 9

Por que o CentOS 7 deixou de ser seguro para o Bitrix24?

O CentOS 7 encerrou seu ciclo de vida em 30 de junho de 2024: desde essa data, não há mais patches de segurança para o sistema operacional nem para as bibliotecas do sistema - incluindo o OpenSSL, preso na versão 1.0.2, também fora de suporte.

Isso significa que vulnerabilidades descobertas após essa data simplesmente não serão corrigidas. Não existe atalho: atualizar pacotes individuais dentro do CentOS 7 não resolve o problema, porque os repositórios estão congelados e as dependências do sistema impedem a instalação de versões mais recentes das bibliotecas críticas.

O OpenSSL 1.0.2 merece atenção especial. Toda comunicação TLS do seu portal - login de usuários, integrações via API, webhooks, acesso ao painel administrativo - passa por essa biblioteca. Falhas ao nível de cifra ou protocolo TLS descobertas hoje ficam permanentemente sem correção nessa versão.

Do ponto de vista de conformidade, rodar um sistema fora de suporte em ambientes que processam dados pessoais cria exposição regulatória direta, seja sob LGPD no Brasil, GDPR na Europa ou legislações equivalentes. Para mais detalhes sobre soberania de dados e conformidade no Bitrix24 self-hosted, veja CRM Self-Hosted: Por Que Escolher Bitrix24 On-Premise para Soberania de Dados.

Em um exemplo real auditado pela nossa equipe, um portal corporativo rodando CentOS Linux 7 com o ambiente web na versão 7.5.1 apresentou o seguinte comparativo em relação às versões recomendadas:

Nenhuma dessas versões pode ser atualizada para os releases atuais dentro do CentOS 7 - os repositórios foram congelados e as dependências do sistema bloqueiam a atualização.

CVEs Ativos no nginx: Vulnerabilidades que Não Têm Correção no CentOS 7

No CentOS 7 é impossível instalar as versões corrigidas do nginx: repositórios congelados, dependência do OpenSSL antigo e ausência de backports de segurança bloqueiam qualquer atualização - o que deixa o servidor exposto a pelo menos três CVEs críticos documentados.

As correções para essas vulnerabilidades só estão disponíveis em versões novas do nginx, que não podem ser instaladas no CentOS 7. Abaixo os três CVEs relevantes para ambientes Bitrix24 On-Premise:

CVE-2026-42945 - "NGINX Rift" (Crítico, RCE ativo)

Buffer overflow de heap no módulo ngx_http_rewrite_module. Afeta todas as versões do nginx de 0.6.27 até 1.30.0 - o que inclui qualquer instalação padrão em CentOS 7. Um atacante não autenticado pode derrubar o processo nginx e, em condições favoráveis, executar código remoto (RCE). Esta vulnerabilidade já está sendo explorada ativamente. A correção está disponível apenas no nginx 1.30.1 e 1.31.0.

CVE-2025-23419 - Bypass de certificado de cliente via TLS session resumption

Permite contornar a verificação de certificados de cliente através da retomada de sessão TLS. Afeta versões 1.11.4 a 1.27.3, corrigida nas versões 1.26.3 e 1.27.4. Particularmente relevante em portais que usam autenticação mútua TLS para integrações entre sistemas.

CVE-2024-7347 - Estouro de buffer no módulo MP4

Overflow no módulo ngx_http_mp4_module. Afeta versões 1.5.13 a 1.27.0, corrigida nas versões 1.26.2 e 1.27.1. Explorável via arquivo MP4 malformado enviado ao servidor.

Nenhuma dessas correções pode ser aplicada no CentOS 7. A única solução efetiva é migrar o sistema operacional.

Para um checklist completo de endurecimento do servidor após a migração, consulte o Hardening de Segurança para Bitrix24 Self-Hosted: Checklist de 25 Pontos.

Como funciona a migração do Bitrix24 para o CentOS Stream 9?

A migração do Bitrix24 On-Premise do CentOS 7 para o CentOS Stream 9 leva cerca de 2 dias úteis de trabalho técnico mais uma semana de suporte de garantia, e utiliza a ferramenta nativa de Backup e Restauração do próprio Bitrix24 para transferir dados sem perda.

O processo não é uma atualização in-place do sistema operacional - é a criação de um servidor novo limpo com CentOS Stream 9 e posterior transferência dos dados do portal. O fluxo descrito abaixo corresponde ao nosso padrão de execução em projetos de migração de servidor.

As etapas principais do processo, desde o backup até a desativação do servidor antigo:

Etapas detalhadas

1. Backup completo - banco de dados, arquivos do portal (incluindo anexos de e-mails, chats e CRM), configurações atuais. Nenhum dado é migrado sem backup verificado.

2. Novo servidor com CentOS Stream 9 - instalação limpa do ambiente Bitrix (bitrix-env) na versão atual, sem herdar dependências antigas. O cliente provisiona o servidor e fornece acesso SSH root; se não tiver infraestrutura própria, indicamos configurações e provedores recomendados.

3. Transferência de dados pela ferramenta nativa - o Bitrix24 possui um mecanismo de Backup/Restauração que move banco de dados, configuração do site e todos os arquivos de forma íntegra. É essa ferramenta que usamos, não scripts manuais.

4. Reconfiguração e segurança - no novo servidor: SMTP, Push & Pull, certificado SSL (Let's Encrypt), redirecionamento HTTP → HTTPS, backups regulares automáticos e demais ajustes de segurança (HSTS, acesso à área administrativa por IP, 2FA).

5. Testes pelo cliente - o portal é entregue para validação antes de qualquer mudança de DNS. O cliente verifica integrações, automações, permissões de usuários e fluxos críticos.

6. Abertura para usuários - a entrada DNS (registro A) é atualizada pelo cliente para apontar para o novo servidor. O mesmo domínio, os mesmos logins de usuários, o mesmo funcionamento.

7. Suporte de garantia - por uma semana após o go-live, corrigimos qualquer problema diretamente relacionado à migração. O servidor antigo permanece acessível durante esse período e só é desligado após confirmação.

Para referências de dimensionamento do servidor de destino antes de iniciar a migração, veja o Bitrix24 Self-Hosted: Guia de Dimensionamento de Hardware para 50 a 1.000 Usuários.

Leia também: Como Mover o Bitrix24 Self-Hosted para um Novo Servidor: Guia Completo

Portais com Personalizações: Por Que a Auditoria é Obrigatória

Se o seu portal Bitrix24 tem modificações no núcleo, módulos próprios ou integrações não padrão, a migração e a atualização acumulada do sistema podem tornar o produto inoperante - sem uma auditoria prévia, esse risco é real e não teórico.

Em auditorias que realizamos, é comum encontrar portais com dezenas de arquivos do núcleo modificados - em alguns casos distribuídos por seis ou mais módulos diferentes (CRM, mensagens, extranet, tarefas, entre outros). Quando a atualização acumulada de versões encontra código modificado no núcleo, os conflitos podem quebrar funcionalidades críticas silenciosamente ou impedir o portal de inicializar.

Antes de qualquer migração em portais personalizados, fazemos:

• Auditoria de modificações de núcleo - identificação de todos os arquivos alterados em relação à distribuição oficial
• Análise de componentes customizados - verificação de compatibilidade com a nova versão do ambiente
• Plano de atualização incremental - se o portal está várias versões atrasado, as atualizações são feitas em etapas no servidor antigo antes da migração, para reduzir o delta de conflitos no destino
• Ambiente de testes - a migração é validada em servidor de teste antes de tocar o ambiente de produção

Portais sem personalizações seguem o fluxo padrão de 2 dias úteis. Portais com customizações têm prazo e escopo definidos apenas após a auditoria. Tentar migrar ou atualizar sem esse passo prévio é o principal motivo de incidentes em migrações de Bitrix24 On-Premise.

Se você também gerencia estratégia de backup e recuperação do portal, veja Bitrix24 On-Premise: Estratégia Completa de Backup e Disaster Recovery.

Trabalhar com um parceiro no self-hosting. Quer o controle do Bitrix24 self-hosted sem gerenciar o servidor? A ACP Group implanta e opera para você - veja Bitrix24 self-hosted gerenciado, planos de suporte e manutenção ou peça um orçamento chave na mão.