Hardening de Servidor Linux: Checklist para Servidor Web

Hardening de servidor linux é o trabalho de reduzir tudo o que um servidor exposto à internet oferece a um atacante: portas, serviços, usuários, versões antigas e permissões sobrando. Se a sua empresa roda site, loja ou sistema em VPS própria e ninguém da equipe é sysadmin, este checklist mostra o que fazer, em que ordem, o que não fazer e quanto custa manter.

TL;DR

• Em 2026, explorar vulnerabilidade virou a principal porta de entrada em violações de dados: 31% dos acessos iniciais no Verizon DBIR 2026, contra 20% no ano anterior. Servidor desatualizado é o alvo mais barato.
• A ordem que funciona: inventário e backup → SSH → firewall → atualizações → PHP e servidor web → banco → logs e monitoramento.
• Várias versões populares já saíram de suporte: PHP 8.1 (31/12/2025), MySQL 8.0 (abril/2026), Debian 11 (31/08/2026). O PHP 8.2 recebe só correção de segurança até 31/12/2026.
• As armadilhas mais caras são silenciosas: o Docker ignora o UFW, o fail2ban atrás da Cloudflare bane a própria Cloudflare e, no Ubuntu 24.04, mudar a porta no sshd_config não muda nada.
• O hardening de servidor linux não é tarefa de um dia: é rotina mensal. Se ninguém na empresa vai fazer essa rotina, contrate quem faça.

Escrevo como desenvolvedor full stack e fundador da Agathas Web, empresa que opera servidores Linux desde 2008. Sustento ambientes Moodle de instituições de ensino, sites e sistemas de clientes em hospedagem gerenciada e a infraestrutura do Voyia, nossa plataforma de atendimento sobre a API oficial do WhatsApp. O checklist de hardening de servidor linux abaixo é o mesmo que aplicamos quando herdamos um servidor.

O que é hardening de servidor linux e por que ficou urgente em 2026

Um servidor recém-criado numa nuvem qualquer vem configurado para funcionar, não para resistir. Aceita login por senha, deixa serviços escutando em todas as interfaces e confia que alguém vai aplicar as atualizações. Hardening de servidor linux é o processo de desligar o que sobra e endurecer o que fica.

O motivo da urgência está nos números. Segundo o Verizon Data Breach Investigations Report 2026, a exploração de vulnerabilidades passou a responder por 31% dos acessos iniciais em violações, à frente de phishing e de credenciais roubadas. O mesmo relatório mostra que as organizações levam uma mediana de 43 dias para corrigir uma falha que já está sendo explorada, e só 26% delas ficam totalmente corrigidas.

Traduzindo para a realidade de uma empresa com um servidor web: sem hardening de servidor linux e rotina de patch, o atacante não precisa escolher você. Ele varre a internet atrás de uma versão vulnerável e entra onde encontrar a porta aberta.

O caso que melhor ilustra isso é o regreSSHion (CVE-2024-6387). Em julho de 2024, a Qualys divulgou uma falha no OpenSSH que permitia execução remota de código como root, sem autenticação, em sistemas Linux com glibc. Afetava as versões 8.5p1 a 9.7p1 e a empresa estimou mais de 14 milhões de instâncias expostas potencialmente vulneráveis. Quem tinha rotina de atualização corrigiu em dias. Quem não tinha, ficou exposto por meses.

Por isso o hardening de servidor linux não é um projeto com começo, meio e fim. É uma configuração inicial bem feita somada a uma rotina que nunca para. Na nossa hospedagem gerenciada, a meta contratual é aplicar patch crítico em até 72 horas após a publicação da CVE — e é essa rotina, não a configuração do primeiro dia, que separa servidor seguro de servidor que foi seguro um dia.

Antes de começar: inventário, backup e acesso de emergência

O erro mais comum de quem faz hardening de servidor linux pela primeira vez é começar pelo SSH e trancar a si mesmo do lado de fora. Antes de mexer em qualquer coisa, garanta três coisas.

1. Um caminho de volta

• Console de emergência do provedor (KVM, console web, "rescue mode"). Teste antes. Se você errar a regra do firewall, é por ali que entra.
• Snapshot do disco tirado imediatamente antes das mudanças. Em VPS custa centavos e desfaz um erro em minutos.
• Uma segunda sessão SSH aberta enquanto altera configuração de acesso. Só feche depois de testar o login numa terceira.

2. Um inventário honesto

Rode ss -tulpn e anote cada serviço escutando. Em servidor herdado, o padrão que mais encontramos é banco de dados escutando em 0.0.0.0, painel de administração esquecido e um serviço de teste que ninguém lembra de ter instalado. Cada item dessa lista precisa de um dono e de um motivo para existir.

3. Quando NÃO aplicar hardening agora

• Sem backup testado. Endurecer um servidor sem restauração garantida troca um risco por outro.
• Na véspera de lançamento, matrícula ou Black Friday. Mudança de segurança tem janela, igual deploy.
• Com script pronto da internet rodado às cegas. Benchmarks como o CIS são referência excelente, mas aplicar todos os itens de uma vez quebra aplicação. Aplique por blocos e teste entre eles.
• Em sistema operacional fora de suporte. Se o servidor roda Ubuntu 20.04 ou Debian 11, o hardening certo é migrar para uma versão suportada, não remendar a antiga.

SSH e usuários: quem entra e como entra

O SSH abre o hardening de servidor linux porque é a porta da frente. É também a primeira coisa que robôs testam, minutos depois de um IP novo aparecer na internet.

O mínimo obrigatório

• Login só por chave. PasswordAuthentication no e KbdInteractiveAuthentication no no sshd_config. Use chaves ed25519, uma por pessoa, nunca compartilhadas.
• Root não entra direto. PermitRootLogin no. Cada pessoa usa o próprio usuário e sobe privilégio com sudo, o que deixa rastro de quem fez o quê.
• Só quem precisa. AllowUsers ou AllowGroups limita quem pode logar, mesmo que outra conta exista no sistema.
• fail2ban para bloquear IPs que insistem em errar. Não substitui a chave, mas tira ruído dos logs e trava ataques de força bruta em outros serviços.
• Desligue contas de quem saiu. Ex-fornecedor com chave ainda autorizada no authorized_keys é mais comum do que parece.

Armadilha: mudar a porta do SSH no Ubuntu 24.04

Trocar a porta 22 por outra reduz ruído nos logs, mas não é proteção real — um scanner encontra a nova porta em segundos. E há um detalhe que pega muita gente: desde o Ubuntu 22.10, o SSH usa ativação por socket do systemd. No Ubuntu 24.04, alterar Port no sshd_config passa na validação e é simplesmente ignorado, porque quem escuta a porta é o ssh.socket. É preciso ajustar o socket e rodar systemctl daemon-reload. Se o firewall já foi fechado para a porta antiga, é aqui que a pessoa perde o acesso.

Usuários e permissões no sistema

A regra é privilégio mínimo. O processo do servidor web (www-data, nginx ou apache) não pode ser dono dos arquivos da aplicação: se for, qualquer falha no código permite reescrever o próprio código. Deixe o código com um usuário de deploy e dê ao servidor web escrita apenas nas pastas que precisam de escrita, como uploads e cache. No Moodle, por exemplo, o moodledata deve ficar fora da pasta pública, com escrita só para o processo PHP.

Firewall: feche tudo e abra só o necessário

O firewall no hardening de servidor linux segue uma política simples: negar tudo por padrão e liberar só o que o negócio exige. Em geral, isso significa 80 e 443 para o mundo e SSH apenas para IPs conhecidos ou via VPN.

No Ubuntu, o UFW resolve bem: ufw default deny incoming, ufw allow 443/tcp, ufw allow from <seu-ip> to any port 22. Banco de dados, Redis e painéis internos não aparecem nessa lista. Eles escutam em 127.0.0.1 ou numa rede privada.

Armadilha 1: o Docker passa por cima do UFW

Se você roda containers, saiba que ao publicar uma porta com -p 8080:80 o Docker escreve as próprias regras de iptables, que o tráfego percorre antes das regras do UFW. Resultado: um ufw deny 8080 não bloqueia nada. A documentação oficial do Docker explica o comportamento. A correção mais simples é publicar só em localhost (-p 127.0.0.1:8080:80) e deixar o proxy reverso falar com o container.

Armadilha 2: fail2ban atrás da Cloudflare

Com um proxy como a Cloudflare na frente, o servidor enxerga o IP da Cloudflare, não o do visitante. Um fail2ban lendo o log do Nginx sem configurar o IP real vai banir endereços da própria Cloudflare — e derrubar clientes legítimos junto com o atacante. Configure o módulo de IP real com as faixas oficiais da Cloudflare antes de ligar qualquer regra de bloqueio baseada em log.

O que não dá para fechar no firewall

Algumas integrações exigem endpoint público. O webhook da API oficial do WhatsApp é um exemplo que operamos todo dia no Voyia: a Meta precisa chegar ao seu servidor. Aqui a proteção sai do firewall e vai para a aplicação: validar a assinatura X-Hub-Signature-256 de cada requisição, aplicar rate limit e rejeitar o que não for assinado. Com o WAF da Cloudflare na frente, ainda dá para barrar bots e picos antes de chegarem ao servidor.

Atualizações: sistema operacional, PHP e banco de dados

É o item com maior retorno e o mais abandonado do hardening de servidor linux em empresas sem sysadmin. A tabela abaixo mostra por que a versão importa tanto quanto a configuração.

Componente	Situação em setembro de 2026	O que fazer
Ubuntu 20.04 LTS	Suporte padrão encerrado em 31/05/2025 (só ESM pago)	Migrar para 24.04 LTS
Ubuntu 22.04 LTS	Suporte padrão até abril de 2027	Planejar migração para 2027
Debian 11	LTS encerrado em 31/08/2026	Migrar já
Debian 12	Em LTS até 30/06/2028	Suportado, planejar Debian 13
PHP 8.1	Fim de vida em 31/12/2025	Atualizar a aplicação
PHP 8.2	Só segurança, até 31/12/2026	Migrar antes do fim do ano
MySQL 8.0	Fim de vida em abril de 2026	Migrar para 8.4 LTS

Fontes: ciclo de lançamentos do Ubuntu, anúncio do fim do Debian 11 LTS e versões suportadas do PHP.

Atualização automática: ligue, mas entenda o limite

No Ubuntu, o unattended-upgrades vem ativo e aplica apenas atualizações de segurança uma vez por dia. É uma boa base. O limite: ele não reinicia o servidor por padrão. Correção de kernel e de bibliotecas como glibc e OpenSSL só vale depois do reboot ou do restart dos serviços. Verifique o arquivo /var/run/reboot-required e agende reinícios numa janela combinada.

Quando NÃO atualizar sozinho

Em hardening de servidor linux vale uma regra: upgrade de versão maior — PHP 8.1 para 8.3, MySQL 8.0 para 8.4, Ubuntu 22.04 para 24.04 — nunca deve ser automático. Plugin, extensão ou código antigo quebra. O caminho seguro é subir um servidor novo em paralelo, validar em staging e virar a chave, como descrevemos no guia para migrar Moodle de servidor sem perder dados. Vale para qualquer sistema, não só para o Moodle.

PHP e servidor web: o que a aplicação expõe

Boa parte das invasões em sites PHP não entra pelo sistema operacional: entra pelo código, por um plugin desatualizado ou por um upload mal validado. O hardening de servidor linux não conserta código ruim, mas limita o estrago.

Configurações de PHP que valem sempre

• expose_php = Off e display_errors = Off em produção. Mensagem de erro na tela entrega caminho de arquivo, versão e às vezes credencial.
• allow_url_include = Off. Não há motivo moderno para incluir código por URL.
• Um pool PHP-FPM por aplicação, cada um com seu usuário. Se um site cair, o vizinho não cai junto.
• Bloquear execução de PHP na pasta de uploads. É por ali que entra o arquivo .php disfarçado de imagem.
• open_basedir restringindo o PHP às pastas da própria aplicação.

Cuidado com o disable_functions copiado da internet

Listas prontas que desligam exec, shell_exec e proc_open aparecem em todo tutorial. Funcionam em site institucional simples, mas quebram recursos reais: o Moodle, por exemplo, chama binários externos para tarefas como conversão de documentos e cálculo de uso de disco. Ajuste a lista à aplicação, não o contrário. Os requisitos, custos e erros da hospedagem Moodle mostram como a stack desse tipo de sistema pede configuração específica.

No servidor web

Remova a assinatura de versão (server_tokens off no Nginx), force HTTPS com HSTS, desligue a listagem de diretórios e bloqueie o acesso a arquivos sensíveis como .env, .git e backups .sql esquecidos na raiz. Certificado SSL renovado automaticamente pelo Let's Encrypt elimina o susto do site "não seguro" numa segunda-feira.

Banco de dados: fora da internet, sempre

Não existe motivo para um MySQL, MariaDB ou PostgreSQL de site ou sistema empresarial aceitar conexão da internet. Mesmo assim, banco exposto é um dos achados mais frequentes quando fazemos hardening de servidor linux em ambiente herdado.

O checklist do banco

• Escutar só em 127.0.0.1 ou na rede privada (bind-address no MySQL/MariaDB, listen_addresses no PostgreSQL).
• Um usuário por aplicação, com permissão só no próprio banco. A aplicação não usa root do banco.
• Senhas fortes e fora do código versionado. Credencial em repositório Git é credencial vazada.
• Acesso administrativo por túnel SSH, nunca abrindo a porta 3306 "só por um dia".
• Remover usuários anônimos e bancos de teste que algumas instalações criam.
• Backup do banco separado do backup de arquivos, com dump consistente e cópia fora do servidor.

Redis e similares

Redis sem senha escutando em interface pública é um convite. Ele foi desenhado para rede confiável. Deixe em localhost, ative autenticação e desligue comandos perigosos que a aplicação não usa.

Logs, monitoramento e backup: o hardening que prova que funcionou

Um servidor endurecido e sem monitoramento é um servidor em que você só descobre o problema pelo cliente. Esta etapa fecha o ciclo do hardening de servidor linux e mostra se as outras funcionaram.

• Logs centralizados e retidos. Autenticação (/var/log/auth.log ou journalctl), servidor web e aplicação. Se o servidor for comprometido, log só local pode ser apagado.
• Alerta que chega em alguém. Uptime externo, disco acima de 85%, CPU travada, erro 500 em série, login SSH de IP novo. Alerta que vai para um e-mail que ninguém lê não é alerta.
• Backup 3-2-1, criptografado e testado. Três cópias, duas mídias, uma fora do servidor. E a parte que quase ninguém faz: restaurar de verdade, todo mês, num ambiente de teste. Backup que nunca foi restaurado é uma hipótese.

Checklist resumido e esforço estimado

Etapa	Esforço inicial	Rotina
Inventário, snapshot e acesso de emergência	1 a 2 h	A cada mudança grande
SSH e usuários	1 h	Revisão trimestral de chaves
Firewall e WAF	1 a 3 h	A cada serviço novo
Atualizações e reboots	1 h de configuração	Semanal, com janela
PHP e servidor web	2 a 4 h	A cada nova aplicação
Banco de dados	1 a 2 h	Revisão trimestral
Logs, alertas e backup testado	3 a 6 h	Mensal (teste de restore)

As horas acima são a nossa estimativa de hardening de servidor linux para um servidor web típico com uma ou duas aplicações, feito por quem já conhece o caminho. Para quem está aprendendo, multiplique por três. E o custo real não é o dia da configuração: é a rotina que precisa acontecer toda semana, por anos, sem que ninguém esqueça.

É aqui que a conta muda para quem não tem sysadmin. Contratar um profissional sênior em tempo integral para cuidar de um ou dois servidores raramente se paga. Deixar a rotina com o desenvolvedor da aplicação costuma funcionar até o primeiro mês corrido. Comparamos custo de operar sozinho e terceirizar, com números, em Moodle na AWS vs hospedagem gerenciada — o raciocínio vale para qualquer sistema.

Como a Agathas Web resolve isso

Tudo o que está neste checklist de hardening de servidor linux faz parte do padrão da nossa hospedagem gerenciada. Não é um pacote extra: é o ponto de partida de todo ambiente que assumimos.

O que está incluso

• Hardening do sistema operacional na entrega, com fail2ban, MFA obrigatório e auditoria de logs.
• Cloudflare WAF com regras customizadas, mitigação de DDoS e bloqueio de bots.
• Atualizações de sistema, runtime (PHP, Node, Python), banco e plugins críticos, testadas em staging e aplicadas em janela combinada. Patch crítico em até 72 horas após a CVE pública, em contrato.
• Backup diário e incremental, offsite e criptografado com AES-256, com restore testado mensalmente.
• Monitoramento 24/7 com Grafana, Prometheus, Sentry e UptimeRobot, e alertas no WhatsApp da equipe técnica.
• SSL Let's Encrypt renovado automaticamente em todos os domínios.
• SLA contratual: 99,9% de uptime, resposta em até 15 minutos para incidente crítico e resolução em até 2 horas.

Como funciona na prática

Começamos com um diagnóstico gratuito da infraestrutura atual: em até 3 dias úteis apontamos riscos, versões fora de suporte e custo otimizado. Se fizer sentido seguir, migramos site, banco, e-mails e DNS em até 7 dias úteis, com validação em staging antes da virada e o ambiente antigo mantido por 30 dias como plano de rollback. Quem atende o seu chamado é o mesmo engenheiro que configurou o servidor.

Quanto custa e como contratar

Sites institucionais e blogs ficam entre R$ 250 e R$ 500 por mês; e-commerce e SaaS, entre R$ 600 e R$ 2.500 por mês. O setup inicial vai de R$ 800 a R$ 3.500, conforme a complexidade. O contrato é mensal, sem fidelidade, com 30 dias de aviso para cancelar. Se a sua empresa também precisa de alguém para decidir arquitetura e prioridades de TI, a consultoria com atuação de CTO as a Service complementa a operação.

Conclusão: o checklist só funciona se alguém rodar todo mês

O hardening de servidor linux começa com um dia de configuração e continua com anos de disciplina. Chave no lugar de senha, firewall negando por padrão, banco fora da internet, versões suportadas, logs e backup testado. Nada disso é secreto. O que falta na maioria das empresas é alguém com tempo e responsabilidade para manter a rotina.

Se você tem o servidor e não tem esse alguém, o próximo passo é simples: peça o diagnóstico gratuito da hospedagem gerenciada da Agathas Web. Você recebe o retrato do risco atual do seu servidor e decide, com números na mão, se vale fazer sozinho ou deixar com quem já faz isso todo dia.