O hardening de servidores consiste na aplicação sistemática de controles técnicos e administrativos para reduzir a superfície de ataque de uma máquina. Diferente da simples instalação de um antivírus, esse processo exige uma revisão criteriosa de cada serviço, porta, permissão e protocolo ativo no sistema. A seguir, detalhamos os passos essenciais para executar essa prática com rigor, alinhados às recomendações de referências reconhecidas em segurança da informação no Brasil.

Por que o hardening é indispensável

Servidores com configurações padrão de fábrica expõem uma quantidade de serviços e funcionalidades que, na maioria dos cenários reais, nunca serão utilizados. Cada serviço adicional representa um potencial vetor de entrada para invasores. Pesquisas de vulnerabilidade mostram consistentemente que grande parte dos incidentes de segurança aproveita configurações incorretas ou padrões que permaneceram inalterados após a instalação. O endurecimento não substitui outros controles, como sistemas de detecção de intrusão ou backups regulares — que são amplamente recomendados pela Cartilha de Segurança para Internet do CERT.br [1] —, mas atua como camada fundamental que eleva o custo do ataque para o adversário. Sem hardening, qualquer outra camada de defesa opera sobre uma base fragilizada.

Inventário e classificação de ativos

Antes de modificar qualquer configuração, é preciso saber exatamente o que está em execução. Isso significa realizar um inventário completo de todos os servidores, identificando sistema operacional, versão, patches aplicados, serviços ativos, portas abertas e rotinas automatizadas (como cron jobs ou tarefas agendadas). Cada servidor deve ser classificado de acordo com a criticidade dos dados e serviços que hospeda. Um servidor de banco de dados produtivo exige um nível de endurecimento diferente de um servidor de desenvolvimento interno. Esse inventário deve ser documentado e atualizado sempre que houver alterações na infraestrutura, formando a base sobre a qual todas as etapas seguintes serão executadas.

Remoção de serviços e pacotes desnecessários

O princípio do menor privilégio se aplica também aos serviços: se não é necessário, não deve estar instalado. Muitas distribuições Linux, por exemplo, trazem por padrão serviços de correio, impressão, gerenciamento remoto gráfico e ferramentas de diagnóstico de rede que raramente são usados em servidores de produção. No ambiente Windows Server, recursos como o Internet Information Services (IIS) ou o Active Directory podem estar habilitados mesmo em máquinas que não exercem essas funções. A remoção ou desabilitação desses componentes reduz diretamente a superfície de ataque. Cada serviço a menos é um componente a menos para ser atualizado, monitorado e potencialmente explorado.

Gerenciamento rigoroso de patches e atualizações

Vulnerabilidades conhecidas são exploradas em questão de horas após a divulgação de um patch. O gerenciamento de atualizações deve ser um processo estruturado, não reativo. Isso envolve: manter um registro das versões de todos os softwares instalados; monitorar canais oficiais de divulgação de segurança (como os avisos do CERT.br [2]); testar patches em ambientes de homologação antes da aplicação em produção; e definir janelas de manutenção para aplicar atualizações de forma controlada. O atraso na aplicação de correções de segurança é um dos fatores mais frequentemente associados a incidentes graves. Um processo de patching bem executado é complementar ao hardening e não pode ser tratado como etapa opcional.

Configuração segura de acesso remoto

O acesso remoto é frequentemente o vetor inicial de comprometimento. As práticas essenciais incluem: desabilitar o login direto do usuário root ou administrador, exigindo que a autenticação seja feita com um usuário comum seguido de escalonamento de privilégio; desativar a autenticação por senha no SSH e utilizar exclusivamente chaves criptográficas; alterar a porta padrão do serviço SSH (embora isso não substitua controles mais robustos, dificulta varreduras automatizadas de baixo esforço); configurar timeout de inatividade e limites de tentativas de login; e implementar autenticação multifator sempre que tecnicamente viável. O CERT.br aborda a importância da verificação em duas etapas como reforço significativo à autenticação [3], e esse princípio deve ser estendido aos acessos administrativos a servidores sempre que possível.

Endurecimento do sistema de arquivos e permissões

O modelo de permissões do sistema operacional é uma barreira crítica contra movimentação lateral e escalonamento de privilégios. Diretórios como /tmp devem ser montados com opções que impeçam a execução de binários (noexec), a criação de dispositivos de bloco (nodev) e a execução de setuid (nosuid). Arquivos de configuração do sistema devem ter permissões restritivas, permitindo leitura apenas ao administrador quando possível. Partiçãoções sensíveis, como aquelas que armazenam dados de usuários ou logs, podem ser separadas em pontos de montagem distintos com opções de montagem específicas. Auditorias periódicas de permissões, utilizando ferramentas como o comando find para localizar arquivos com permissões world-writable ou com bit setuid ativado indevidamente, são parte de um ciclo de manutenção contínua.

Configuração de firewall e segmentação de rede

Um firewall de host (como iptables, nftables ou o Windows Defender Firewall com Regras Avançadas) deve ser configurado seguindo a regra de negar por padrão e permitir apenas o estritamente necessário. Isso significa que cada porta aberta deve ter justificativa documentada e associada a um serviço específico. A segmentação de rede complementa essa abordagem: servidores que hospedam bancos de dados, por exemplo, não precisam ter conectividade direta com a internet, devendo ser posicionados em segmentos internos acessíveis apenas por servidores de aplicação autorizados. A combinação de firewall de host com segmentação de rede cria barreiras que dificultam significativamente a progressão de um ataque após a fase inicial de comprometimento.

Proteção de logs e monitoramento de integridade

Os logs são a principal fonte de evidência para investigação de incidentes e, portanto, devem ser protegidos contra modificação ou exclusão por um invasor que tenha obtido acesso ao sistema. Isso pode ser feito enviando os logs em tempo real para um servidor centralizado de syslog ou uma solução de SIEM, garantindo que mesmo que o servidor local seja comprometido, os registros anteriormente enviados permaneçam intactos. Além disso, a instalação de um sistema de monitoramento de integridade de arquivos (como AIDE, OSSEC ou Wazuh) permite detectar alterações não autorizadas em binários do sistema, arquivos de configuração e outros elementos críticos. Esses controles são essenciais para que o hardening não seja um ponto no tempo, mas um estado mantido e verificável continuamente.

Lista estruturada de verificação de hardening

Abaixo, um resumo quantitativo dos principais pontos de verificação para um processo de hardening executado de forma organizada:

  1. Inventariar todos os servidores com sistema operacional, versão, serviços e portas mapeadas.
  2. Remover pacotes e serviços não utilizados, incluindo ferramentas de desenvolvimento em produção.
  3. Aplicar todas as atualizações de segurança pendentes e estabelecer um ciclo regular de patching.
  4. Desabilitar login direto de root/administrador e exigir autenticação por chave SSH.
  5. Configurar firewall de host com política de negação por padrão.
  6. Restringir permissões de arquivos e diretórios, aplicando opções de montagem seguras em partições sensíveis.
  7. Centralizar logs em servidor dedicado e implantar monitoramento de integridade de arquivos.
  8. Documentar cada alteração realizada e justificar exceções com aprovação formal.
  9. Auditar periodicamente o estado de endurecimento de cada servidor.
  10. Segmentar a rede para isolar servidores com dados sensíveis da exposição direta à internet.

Manutenção contínua e reavaliação periódica

O hardening não é uma atividade realizada uma única vez. Novas vulnerabilidades são descobertas, serviços são adicionados ou modificados, e as necessidades de negócio se transformam. Por isso, é necessário estabelecer um ciclo de reavaliação que inclua auditorias regulares da configuração dos servidores, comparação com baselines documentadas e atualização das políticas de endurecimento conforme o cenário de ameaças evolui. Ferramentas de automação de configuração, como Ansible, Puppet ou Chef, podem ser utilizadas para garantir que o estado desejado de hardening seja mantido de forma consistente e reproduzível, reduzindo a dependência de processos manuais que são propensos a erros e inconsistências.

Perguntas frequentes sobre hardening de servidores

O que diferencia hardening de simples instalação de antivírus?
O hardening é um processo estruturado de redução da superfície de ataque que envolve remoção de serviços, ajuste de permissões, configuração de firewalls e outras medidas preventivas. O antivírus é um controle reativo que detecta e bloqueia ameaças conhecidas. São camadas complementares, não substitutas.

É possível fazer hardening sem impactar a disponibilidade dos serviços?
Sim, desde que cada alteração seja planejada, testada em ambiente de homologação e aplicada com janelas de manutenção adequadas. O objetivo do hardening é remover o desnecessário, não o essencial. A documentação e o inventário prévio são fundamentais para evitar remoções indevidas.

Hardening substitui a necessidade de backups?
Não. O hardening reduz a probabilidade de comprometimento, mas não a elimina. Backups regulares, testados e armazenados de forma segura são indispensáveis e são enfatizados como prática essencial pela Cartilha de Segurança para Internet do CERT.br [1]. Hardening e backup atendem a propósitos distintos e devem coexistir.

Com que frequência o hardening deve ser reavaliado?
A reavaliação deve ocorrer sempre que houver mudanças significativas na infraestrutura (instalação de novos serviços, atualizações de versão do sistema operacional) ou quando novas vulnerabilidades críticas forem divulgadas. Como referência mínima, uma auditoria trimestral de conformidade com a baseline de hardening é recomendada.

Containers e máquinas virtuais também precisam de hardening?
Sim. Embora o modelo de containers reduza a superfície de ataque em comparação a máquinas virtuais completas, cada container ainda expõe um sistema operacional mínimo que pode conter vulnerabilidades. Imagens de base devem ser enxutas, sem ferramentas desnecessárias, e o host que executa os containers deve passar pelo mesmo processo de endurecimento descrito neste artigo.

Fontes

[1] CERT.br — Fascículos — Cartilha de Segurança para Internet

[2] Governo Digital — CERT.br

[3] Camara-e.net — Cartilha de Segurança para Internet – CERT.br lança fascículo sobre verificação de senhas em duas etapas

[6] IBSEC — Hardening: O que é e como proteger seus servidores e sistemas

Leia também