18 vulnerabilidades que encontramos e corrigimos em um servidor de hospedagem

Quando voce hospeda sites de clientes, a seguranca deixa de ser opcao e vira obrigacao. Em uma auditoria recente em nosso proprio servidor de producao, encontramos 18 vulnerabilidades que iam desde portas expostas ate ausencia de atualizacoes automaticas.

Neste artigo, compartilhamos o que encontramos, como classificamos cada item e o que fizemos para corrigir.

O que auditamos

A auditoria cobriu 20 areas: SSH, firewall, MySQL, PHP, Docker, Nginx, certificados SSL, permissoes de arquivo, cron jobs, backups, monitoramento proativo e mais. Cada item foi classificado por severidade:

Critico: atualizacoes automaticas desabilitadas

O servidor nao recebia patches de seguranca automaticamente. Isso significa que vulnerabilidades conhecidas ficavam abertas por tempo indeterminado. A correcao foi simples: habilitar o unattended-upgrades do Ubuntu para aplicar patches de seguranca diariamente.

Alto: banco de dados exposto na internet

O MySQL estava escutando em todas as interfaces de rede (0.0.0.0:3306), e 4 usuarios aceitavam conexoes de qualquer origem. Se o firewall fosse desabilitado por qualquer motivo, o banco ficaria acessivel de qualquer lugar do mundo.

Correcao: restringimos o MySQL para escutar apenas em localhost e nas interfaces Docker internas. Todos os usuarios tiveram seus hosts trocados de % para IPs especificos.

Alto: PHP sem restricoes para clientes

Os pools PHP-FPM dos sites de clientes nao tinham disable_functions nem open_basedir configurados. Um script malicioso poderia executar comandos no sistema ou ler arquivos de outros sites.

Correcao: cada pool de cliente agora tem funcoes perigosas bloqueadas e acesso restrito ao seu proprio diretorio.

Alto: Docker ignorando o firewall

Containers Docker manipulam o iptables diretamente, ignorando as regras do UFW. Portas que deveriam ser internas estavam acessiveis da internet.

Correcao: todas as portas de containers foram vinculadas a 127.0.0.1 no docker-compose.

Alto: sem headers de seguranca no Nginx

As respostas HTTP nao incluiam headers basicos como HSTS, X-Frame-Options e Content-Security-Policy. Isso expoe os sites a ataques de clickjacking e downgrade de protocolo.

Correcao: criamos uma configuracao global em /etc/nginx/conf.d/security-headers.conf aplicada automaticamente a todos os sites.

Medio: backups sem criptografia

Os backups eram armazenados como arquivos tar.gz comuns. Se o storage fosse comprometido, todos os dados dos clientes estariam expostos.

Correcao: implementamos criptografia AES-256-CBC com PBKDF2 (100.000 iteracoes). A chave e armazenada com permissao 600 acessivel apenas pelo root.

O resultado

Apos corrigir todos os 18 itens, o servidor passou de uma postura de seguranca basica para um nivel compativel com hospedagem profissional:

• SSH com chave apenas, sem root, maximo 3 tentativas
• MySQL restrito a interfaces internas, todos os usuarios com autenticacao forte
• PHP isolado por site com funcoes restritas
• Backups criptografados com restauracao em 1 clique
• Atualizacoes de seguranca aplicadas automaticamente
• 7 jails Fail2Ban ativos + firewall com regras explicitas