18vulnerabilidadesqueencontramosecorrigimosemumservidordehospedagem

Quando você hospeda sites de clientes, segurança deixa de ser opção e vira obrigação. Em uma auditoria recente no nosso próprio servidor de produção, encontramos 18 vulnerabilidades que iam desde portas expostas até ausência de atualizações automáticas.

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

·O que auditamos

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

·Crítico: atualizações automáticas desabilitadas

O servidor não recebia patches de segurança automaticamente. Isso significa que vulnerabilidades conhecidas ficavam abertas por tempo indeterminado. A correção foi simples: habilitar o unattended-upgrades do Ubuntu para aplicar patches de segurança 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 usuários aceitavam conexões de qualquer origem. Se o firewall fosse desabilitado por qualquer motivo, o banco ficaria acessível de qualquer lugar do mundo.

Correção: restringimos o MySQL para escutar apenas em localhost e nas interfaces Docker internas. Todos os usuários tiveram seus hosts trocados de % para IPs específicos.

·Alto: PHP sem restrições para clientes

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

Correção: cada pool de cliente agora tem funções perigosas bloqueadas e acesso restrito ao seu próprio diretório.

·Alto: Docker ignorando o firewall

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

Correção: todas as portas de containers foram vinculadas a 127.0.0.1 no docker-compose.

·Alto: sem headers de segurança no Nginx

As respostas HTTP não incluíam headers básicos como HSTS, X-Frame-Options e Content-Security-Policy. Isso expõe os sites a ataques de clickjacking e downgrade de protocolo.

Correção: criamos uma configuração global em /etc/nginx/conf.d/security-headers.conf aplicada automaticamente a todos os sites.

·Médio: backups sem criptografia

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

Correção: implementamos criptografia AES-256-CBC com PBKDF2 (100.000 iterações). A chave é armazenada com permissão 600, acessível apenas pelo root.

·O resultado

Após corrigir todos os 18 itens, o servidor passou de uma postura de segurança básica para um nível compatível com hospedagem profissional:

• SSH com chave apenas, sem root, máximo 3 tentativas
• MySQL restrito a interfaces internas, todos os usuários com autenticação forte
• PHP isolado por site com funções restritas
• Backups criptografados com restauração em 1 clique
• Atualizações de segurança aplicadas automaticamente
• 7 jails Fail2Ban ativos + firewall com regras explícitas