Hardening Linux: práticas essenciais para servidores em produção
Servidores instalados com configuração padrão trazem risco evitável. Veja um baseline de hardening aplicável e auditável.
Um servidor Linux recém-instalado vem com serviços ativos que você não usa, permissões amplas e configurações pensadas para conveniência, não para segurança. Hardening é o processo de reduzir essa superfície: desligar o que não é necessário, endurecer o acesso e garantir que o sistema gere evidência do que acontece. Feito uma vez e padronizado, ele eleva o piso de segurança de toda a frota.
Este guia apresenta um baseline prático e defensivo para servidores em produção, organizado pelos pontos que mais reduzem risco: acesso por SSH, privilégios, firewall, atualizações, serviços e auditoria. Use os CIS Benchmarks como referência e adapte ao seu ambiente, em vez de aplicar uma lista de forma cega.
Acesso, SSH e privilégios
O SSH é a principal porta de entrada e merece atenção. Desabilite o login direto de root, exija autenticação por chave em vez de senha e restrinja quem pode acessar. Manter a autenticação por chave evita força bruta de senha, que é o ataque mais comum contra SSH exposto.
PermitRootLogin no
PasswordAuthentication no
X11Forwarding noPrivilégios, chaves e contas de serviço
Para privilégios, aplique menor privilégio: cada pessoa tem o próprio usuário, e a elevação acontece via sudo com registro. Evite contas compartilhadas, que destroem a rastreabilidade de quem fez o quê.
Trate as chaves SSH como credenciais com ciclo de vida: registre quais chaves têm acesso, remova as de pessoas que saíram e prefira chaves protegidas por senha. Contas de serviço que não precisam de shell interativo devem usar um shell que recuse login, para que uma credencial dessa conta não vire um ponto de acesso. Restrinja também quais usuários podem se autenticar por SSH, em vez de deixar o acesso aberto a qualquer conta do sistema.
Firewall, serviços e atualizações
Habilite um firewall de host e libere apenas as portas necessárias, na lógica de negar por padrão. Liste os serviços ativos e desabilite tudo que não tem função clara: cada serviço a menos é uma vulnerabilidade potencial a menos. Atualizações de segurança devem ter um processo definido, com aplicação regular e prioridade para correções críticas, idealmente testadas em homologação antes de produção.
- Negar por padrão no firewall e liberar apenas o necessário
- Desabilitar serviços e pacotes sem função clara
- Aplicar atualizações de segurança em cadência definida
- Separar homologação de produção para validar mudanças
- Sincronizar horário com NTP para correlação confiável de logs
Kernel e controle de acesso obrigatório
Boa parte da superfície de um servidor vive no kernel e no comportamento de rede. Um conjunto de parâmetros de sysctl reduz vetores comuns: ignorar redirecionamentos ICMP, ativar filtro de caminho reverso contra spoofing de origem e manter a aleatorização de endereços de memória, que dificulta a exploração de falhas de memória. Esses ajustes ficam versionados em um arquivo, então nascem junto com o servidor e são fáceis de auditar.
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
kernel.randomize_va_space = 2Mantenha o controle de acesso obrigatório ativo. SELinux em modo enforcing ou AppArmor com perfis carregados confina cada processo ao que ele deveria fazer, de modo que um serviço comprometido não alcance arquivos e recursos fora do seu escopo. É comum desativar essa camada ao primeiro conflito, o que remove justamente a contenção que limitaria o estrago. O caminho melhor é ajustar o perfil ou o contexto e manter o modo enforcing.
Logs, auditoria e proteção contra abuso
Centralize os logs em um destino remoto, para que um host comprometido não permita apagar a própria trilha. Habilite auditoria do sistema para registrar eventos sensíveis, como uso de sudo e alterações em arquivos críticos. Ferramentas como fail2ban reduzem força bruta bloqueando origens com muitas tentativas falhas, complementando a autenticação por chave.
Revise permissões de arquivos sensíveis e remova permissões de escrita desnecessárias. Muitos incidentes escalam porque um arquivo de configuração ou um binário tinha permissão ampla demais.
Integridade de arquivos e baseline verificável
Hardening só se sustenta se você percebe quando o sistema muda. Uma ferramenta de integridade de arquivos, como o AIDE, grava um baseline dos arquivos críticos e aponta o que foi alterado depois, o que ajuda a detectar um binário trocado ou uma configuração adulterada. Os próprios gerenciadores de pacote validam a integridade dos arquivos instalados, comparando-os com o que o pacote entregou, o que é útil ao investigar um host suspeito.
A auditoria do sistema pode observar caminhos sensíveis e registrar quem os alterou. Regras que vigiam contas, configuração do SSH e o arquivo de sudoers transformam uma mudança silenciosa em um evento rastreável. Combine essas regras com o envio de logs para fora do host, para que a evidência não dependa do servidor que pode ter sido comprometido.
-w /etc/passwd -p wa -k identity
-w /etc/ssh/sshd_config -p wa -k sshd
-w /etc/sudoers -p wa -k sudoersO baseline também vive na forma como o servidor é provisionado. Descrever o hardening como código, em uma ferramenta de automação, faz cada host nascer no mesmo estado e permite comparar o que está rodando com o que deveria estar. Sem isso, a configuração vai divergindo host a host e o desvio só aparece durante um incidente.
Checklist prático
- Desabilitar login direto de root no SSH
- Exigir autenticação por chave e desativar senha no SSH
- Dar a cada pessoa um usuário próprio e elevar via sudo com registro
- Habilitar firewall de host com negação por padrão
- Desabilitar serviços e pacotes sem função clara
- Definir processo de atualizações de segurança com cadência
- Centralizar logs em destino remoto
- Habilitar auditoria de eventos sensíveis (sudo, arquivos críticos)
- Usar fail2ban ou equivalente contra força bruta
- Revisar permissões de arquivos e remover escrita desnecessária
- Sincronizar horário via NTP
- Padronizar o baseline para novos servidores
- Manter SELinux ou AppArmor em modo enforcing
- Aplicar parâmetros de sysctl de rede e memória (rp_filter, ASLR, redirects)
- Habilitar verificação de integridade de arquivos com AIDE ou equivalente
- Registrar regras de auditoria para arquivos sensíveis (passwd, sshd_config, sudoers)
- Restringir quais usuários podem se autenticar por SSH
Boas práticas
- Use os CIS Benchmarks como referência adaptada ao ambiente
- Padronize o baseline para que novos hosts nasçam endurecidos
- Centralize logs para preservar evidência mesmo sob comprometimento
- Aplique mudanças de hardening de forma incremental e validada
- Documente exceções com justificativa e prazo de revisão
- Monitore desvio em relação ao baseline ao longo do tempo
- Mantenha o controle de acesso obrigatório ativo em vez de desligá-lo ao primeiro conflito
- Descreva o hardening como código para que cada host nasça no mesmo estado
Erros comuns
SSH com senha e login de root habilitados
Alvo direto de força bruta e comprometimento com privilégio máximo.
Serviços padrão ativos sem uso
Ampliam a superfície de ataque e somam vulnerabilidades desnecessárias.
Logs apenas locais
Um host comprometido permite apagar a própria trilha de evidência.
Atualizações sem processo
Vulnerabilidades conhecidas permanecem abertas por longos períodos.
Contas compartilhadas
Perde-se a rastreabilidade de quem executou cada ação.
SELinux ou AppArmor desativado para resolver um erro rápido
Remove uma camada de contenção que limitaria um processo comprometido.
Quando procurar apoio especializado
Definir um baseline de hardening que reduza risco sem quebrar a operação, e padronizá-lo na frota, é o foco do serviço de Hardening da GUARDIASEC, que adapta os CIS Benchmarks ao seu ambiente e valida as mudanças de forma incremental.
Perguntas frequentes
Preciso seguir os CIS Benchmarks à risca?
Os CIS Benchmarks são uma excelente referência, mas devem ser adaptados ao seu ambiente. Alguns itens podem quebrar aplicações específicas ou não fazer sentido no seu contexto. A prática recomendada é aplicar o que reduz risco sem inviabilizar a operação e justificar as exceções, em vez de seguir a lista de forma cega.
Autenticação por chave SSH é mesmo mais segura que senha?
Sim, de forma significativa. Chaves eliminam o ataque de força bruta de senha, que é o mais comum contra SSH exposto, e são muito mais difíceis de adivinhar. O cuidado passa a ser proteger a chave privada com senha e controlar quais chaves têm acesso, removendo as que não são mais necessárias.
Por que centralizar logs fora do servidor?
Porque um atacante que compromete o host normalmente tenta apagar rastros para dificultar a investigação. Se os logs ficam apenas locais, ele consegue. Enviando os logs para um destino remoto e restrito, você preserva a evidência mesmo quando o servidor de origem foi comprometido.
Hardening elimina a necessidade de monitoramento?
Não. Hardening reduz a superfície e a probabilidade de comprometimento, mas não impede todo ataque. Monitoramento e detecção continuam necessários para identificar atividade suspeita e responder rápido. Os dois trabalham juntos: o hardening diminui o que pode dar errado e a detecção avisa quando algo acontece.
Devo desativar o SELinux quando ele atrapalha uma aplicação?
A resposta curta é não. Desativar o SELinux costuma ser o atalho para resolver um erro de permissão, mas remove uma camada que confina cada processo ao seu escopo. Quando um serviço é bloqueado, o caminho melhor é analisar o registro de negação e ajustar o contexto ou o perfil, mantendo o modo enforcing. Deixar em modo permissivo por um período serve para diagnosticar, não para operar em produção.
O que é verificação de integridade de arquivos e preciso disso?
É um mecanismo que grava um baseline dos arquivos críticos e depois aponta o que mudou, ajudando a detectar um binário trocado ou uma configuração adulterada. Ferramentas como o AIDE fazem isso, e os gerenciadores de pacote também validam a integridade do que instalaram. Em servidores expostos ou que guardam dados sensíveis, esse controle acelera bastante a investigação de um host suspeito.
Como mantenho o baseline de hardening ao longo do tempo?
Descrevendo o hardening como código, em uma ferramenta de automação, de forma que cada servidor nasça no mesmo estado e seja possível comparar o que roda com o que deveria rodar. Mudanças manuais no dia a dia fazem a configuração divergir host a host, e esse desvio costuma aparecer só durante um incidente. A automação, somada a uma verificação periódica contra o baseline, mantém a frota coerente.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.