Hardening de servidores Linux: checklist de seguranca para ambientes corporativos

Por que hardening de Linux deixou de ser opcional

Servidores Linux sustentam a maior parte da infraestrutura corporativa brasileira: bancos de dados, aplicações internas, servidores de arquivos, gateways de VPN, hipervisores e cargas em nuvem. A percepção de que "Linux é seguro por padrão" ainda circula em muitas equipes de TI, mas ela confunde duas coisas diferentes. O kernel e as distribuições corporativas realmente têm um histórico sólido de isolamento de privilégios e correções rápidas. O que quase nunca vem pronto é a configuração: uma instalação padrão prioriza compatibilidade e facilidade de uso, não superfície de ataque mínima.

Na prática, os incidentes que vemos em servidores Linux raramente envolvem uma falha exótica do kernel. Envolvem SSH exposto à internet com autenticação por senha, um usuário de aplicação rodando como root, um serviço legado ouvindo em 0.0.0.0 porque "era mais simples testar assim", pacotes sem atualização há dezoito meses e ausência total de log centralizado — o que significa que ninguém consegue reconstruir o que aconteceu depois do fato. Nenhum desses problemas exige um atacante sofisticado. Exige apenas alguém rodando varredura automatizada em blocos de IP, o que acontece continuamente.

Hardening é o processo de reduzir essa distância entre o padrão de fábrica e o que um ambiente de produção exige. Não é um projeto com data de término: é um conjunto de controles aplicados na provisão do servidor, validados periodicamente e reaplicados quando o ambiente muda. O checklist abaixo cobre as camadas que, na nossa experiência operando parques com centenas de máquinas, entregam a maior redução de risco pelo menor esforço.

SSH: o ponto de entrada que merece mais atenção

O SSH é, na esmagadora maioria dos ambientes, o principal canal administrativo — e por isso o alvo preferencial de força bruta e credential stuffing. Um servidor com porta 22 aberta na internet e autenticação por senha habilitada começa a receber tentativas de login em questão de minutos após subir. A boa notícia é que endurecer o SSH é barato e o retorno é imediato.

O controle mais importante é eliminar senhas do fluxo de autenticação. Chaves assimétricas (Ed25519 ou RSA de 4096 bits) não são adivinháveis por dicionário e permitem revogação individual por usuário. Depois disso, vale desabilitar o login direto de root: administradores autenticam com a própria conta e escalam via sudo, o que preserva a trilha de auditoria de quem fez o quê. Um root compartilhado destrói qualquer possibilidade de responsabilização.

• PermitRootLogin no — força escalonamento nominal via sudo.
• PasswordAuthentication no e ChallengeResponseAuthentication no — apenas chaves.
• AllowUsers ou AllowGroups — lista explícita de quem pode sequer tentar autenticar.
• Protocol 2, ciphers e MACs modernos — remova algoritmos legados (CBC, HMAC-SHA1, diffie-hellman-group1).
• MaxAuthTries 3 e LoginGraceTime 30 — reduzem janela de tentativa.
• ClientAliveInterval e ClientAliveCountMax — encerram sessões ociosas esquecidas.
• Fail2ban ou equivalente — bane IPs após repetidas falhas, cortando ruído de varredura.

Trocar a porta 22 por outra é frequentemente citado, mas é segurança por obscuridade: reduz o volume de log gerado por bots genéricos, não detém um atacante que faça varredura de portas. Use como conveniência operacional, nunca como controle principal. O controle real é restringir a origem: sempre que possível, o SSH não deve estar exposto à internet, e sim acessível apenas via VPN corporativa ou bastion host. Isso transforma o problema de "qualquer um no mundo pode tentar" para "apenas quem já está autenticado na rede pode tentar".

Se o seu servidor de produção aceita conexão SSH com senha vinda de qualquer IP do planeta, esse é o item que você deve corrigir antes de ler o resto deste artigo. Todos os demais controles perdem valor quando a porta da frente está destrancada.

Usuários, permissões e o princípio do menor privilégio

Depois do acesso remoto, o segundo vetor mais explorado é o excesso de privilégio interno. O padrão que se repete: uma aplicação web roda como root "porque precisava abrir a porta 80", um script de integração usa uma conta com sudo NOPASSWD: ALL "porque estava dando erro", e três anos depois ninguém lembra por quê. Quando um atacante compromete essa aplicação — via injeção, deserialização ou uma dependência vulnerável —, ele não ganha acesso a um processo isolado; ganha a máquina inteira.

Cada serviço deve rodar sob um usuário de sistema dedicado, sem shell de login (/usr/sbin/nologin), sem diretório home com dados sensíveis e com acesso de escrita restrito aos diretórios que realmente precisa. Para portas privilegiadas abaixo de 1024, use CAP_NET_BIND_SERVICE via systemd ou coloque um proxy reverso na frente — não eleve o serviço inteiro a root. As unidades systemd modernas oferecem ProtectSystem=strict, PrivateTmp=yes, NoNewPrivileges=yes e ProtectHome=yes, que criam isolamento significativo com três linhas de configuração.

No lado dos administradores, o sudo deve ser específico: conceda comandos, não o coringa. Registre a saída com Defaults log_output quando o ambiente exigir auditoria fina. E revise periodicamente contas órfãs — o técnico que saiu da empresa há oito meses, o usuário de um sistema desativado, a chave pública que ninguém sabe de quem é. Um inventário trimestral de contas com lastlog e leitura do /etc/passwd e dos authorized_keys costuma revelar surpresas.

1. Mapeie todo serviço em produção e o usuário sob o qual ele executa.
2. Elimine execuções como root que não tenham justificativa técnica documentada.
3. Revise /etc/sudoers e /etc/sudoers.d/ em busca de ALL=(ALL) NOPASSWD: ALL.
4. Audite arquivos SUID/SGID com find / -perm -4000 -type f e remova o que não for necessário.
5. Verifique permissões de diretórios sensíveis: /etc/shadow (640), chaves privadas (600), /root (700).
6. Desative contas inativas e remova chaves SSH sem dono identificado.

Firewall local, serviços expostos e segmentação

Muita equipe considera o firewall de perímetro suficiente e deixa o host sem qualquer filtro local. O problema dessa abordagem aparece no movimento lateral: uma vez que um atacante — ou um ransomware — tem presença em qualquer máquina da rede interna, todo servidor sem firewall local vira alvo direto, porque o perímetro só protege contra tráfego que vem de fora. Firewall no host é a camada que limita o estrago depois que algo já entrou.

A regra de ouro é política padrão de negação na entrada, liberando explicitamente apenas o necessário — e, quando possível, restringindo também a origem. Um banco de dados PostgreSQL não deve aceitar conexões de toda a rede corporativa; deve aceitar da faixa de IPs dos servidores de aplicação. Ferramentas como ufw, firewalld ou nftables direto tornam isso administrável sem exigir domínio profundo de tabelas de filtro.

Complementarmente, reduza a superfície na origem: rode ss -tulpn e questione cada porta em escuta. Serviços instalados por dependência de pacote e nunca usados — servidores de impressão, RPC, servidores de e-mail locais, ferramentas de descoberta — são passivo puro. Desinstale em vez de apenas desabilitar, quando o pacote não for requisito de outro componente. Serviços que precisam existir mas só servem localhost devem estar amarrados a 127.0.0.1, não a 0.0.0.0. E onde a distribuição oferece SELinux (RHEL, Rocky, Alma) ou AppArmor (Ubuntu, Debian, SUSE), mantenha em modo enforcing: desligar o SELinux para resolver um erro de permissão é trocar uma correção de dez minutos por um risco permanente.

Auditoria, logs e visibilidade do que acontece

Hardening sem monitoramento produz um servidor mais difícil de invadir e igualmente impossível de investigar. Quando ocorre um incidente, as três perguntas são sempre as mesmas: quando começou, por onde entrou e o que foi acessado. Sem log íntegro e retido, nenhuma delas tem resposta — e a organização fica sem base para notificar clientes, acionar seguro ou cumprir obrigações da LGPD.

O auditd é a ferramenta nativa para trilha em nível de syscall: permite regras que registram alterações em arquivos críticos (/etc/passwd, /etc/sudoers, chaves SSH), execuções privilegiadas e tentativas de acesso negadas. Combinado ao journald e aos logs de aplicação, forma a base do que precisa ser coletado. O ponto crítico é que esses logs não podem morar apenas no host: um atacante com root apaga o rastro. Envio para um coletor centralizado — Graylog, Wazuh, Elastic, ou o SIEM que a empresa já usa — garante que exista uma cópia fora do alcance do comprometimento.

Além do registro, vale instrumentar verificação de integridade com AIDE ou Tripwire, que detectam alteração inesperada de binários e arquivos de configuração, e definir alertas para os eventos que realmente importam: login SSH bem-sucedido de origem incomum, criação de usuário, alteração de sudoers, uso de su para root, falha em massa de autenticação. Alerta em excesso vira ruído ignorado; escolha poucos gatilhos de alto sinal e mantenha a resposta documentada.

Atualizações, gestão de vulnerabilidades e disciplina de ciclo

A causa mais comum de comprometimento de servidor Linux continua sendo software desatualizado com vulnerabilidade pública e exploit disponível. Não é sofisticado, mas funciona porque atualizar exige janela de manutenção, teste e coordenação — e essas coisas escorregam quando não há processo formal. Servidores que "não podem reiniciar" acumulam anos de dívida até que a atualização vire um projeto de risco em si.

Um ciclo saudável combina três elementos. Primeiro, atualizações de segurança automatizadas para pacotes de baixo risco (unattended-upgrades no Debian/Ubuntu, dnf-automatic no RHEL), configuradas para aplicar apenas o repositório de segurança. Segundo, janela mensal planejada para pacotes maiores e reinicialização de kernel — ou uso de live patching (kpatch, Livepatch, KernelCare) onde o downtime é inviável. Terceiro, varredura de vulnerabilidades recorrente que produza uma lista priorizada por criticidade e exposição real, não um relatório de trezentas páginas que ninguém lê.

Vale reforçar um ponto que costuma ser esquecido: hardening e backup são controles complementares, não substitutos. O servidor mais bem endurecido do parque ainda pode ser vítima de ransomware que entrou por outro caminho, de erro humano ou de falha de hardware. Backup testado — com cópia imutável ou offline, e restauração validada em ensaio, não apenas "o job rodou verde" — é o que transforma um incidente grave em uma interrupção administrável.

Como a Duk aplica isso em ambientes de produção

Manter esse checklist vivo em um parque com dezenas ou centenas de servidores é um trabalho contínuo, e é exatamente aí que a maioria das equipes internas trava: não por falta de conhecimento técnico, mas por falta de tempo entre chamados, projetos e demandas do dia. Hardening compete com o urgente e costuma perder — até o dia do incidente.

Na Duk Informática & Cloud, hardening faz parte do padrão de provisionamento, não de um serviço avulso. São mais de 18 anos operando infraestrutura crítica e mais de 550 empresas atendidas, com baseline aplicada na entrega de cada servidor Linux, revisão periódica de conformidade, monitoramento centralizado de logs e gestão de patches em janela acordada com o cliente. Como Microsoft Gold Partner com data center próprio em Alphaville, cuidamos tanto de cargas Linux quanto de ambientes híbridos com Windows Server e Microsoft 365 — o que na prática significa uma única equipe respondendo por segurança, backup e disponibilidade em vez de fornecedores fragmentados apontando uns para os outros.

Se você não tem certeza de qual é o estado atual dos seus servidores — quais aceitam senha no SSH, quais rodam serviços como root, quais não recebem patch há mais de um trimestre —, esse diagnóstico é o ponto de partida natural. Ele costuma ser rápido de levantar e quase sempre revela dois ou três itens de correção imediata que reduzem risco de forma desproporcional ao esforço. Fale com nosso time para avaliar seu ambiente e montar um plano de hardening compatível com a sua realidade operacional.