Hardening de servidores Linux reduz a superfície de ataque antes mesmo da primeira conexão. Administradores brasileiros que aplicam CIS Benchmarks, travam o SSH com chaves e mantêm firewall, SELinux e atualizações automáticas em sincronia blindam VPSs e on-premise contra ransomware, criptomineração e acesso não autorizado. Veja o passo a passo.

Por que endurecer o Linux

Um servidor Linux recém-instalado vem com dezenas de serviços, portas abertas e permissões generosas que facilitam a vida do operador — e do atacante. O processo de hardening consiste em reduzir essa exposição ao mínimo necessário para a função do servidor, seguindo um conjunto documentado de controles técnicos. A referência mais adotada é a série de CIS Benchmarks, mantida pelo Center for Internet Security, que descreve mais de 200 configurações recomendadas para distribuições como Ubuntu, Debian, RHEL e Rocky Linux.

A NIST publica controles complementares na série SP 800-53, adotada por órgãos federais e por provedores de nuvem. Aplicar esses guias do zero, antes de qualquer aplicação entrar em produção, evita que vulnerabilidades já conhecidas sejam exploradas. Casos recentes mostram o custo de negligenciar isso: o malware SharkLoader invade redes explorando 13 falhas antigas, nenhuma delas zero-day.

Desativar serviços desnecessários

O primeiro bloco do CIS Benchmark manda listar e remover tudo que o servidor não usa. Em uma instalação típica de Debian ou Ubuntu, serviços como avahi-daemon, cups, rpcbind, nfs-kernel-server e postfix sobem por padrão mesmo em uma máquina voltada só para web. Cada um deles abre uma porta, consome memória e adiciona vetores de exploração.

Para identificar o que está ativo, execute ss -tulpn e systemctl list-unit-files --state=enabled. Depois desative com systemctl disable --now <servico>. A meta é deixar apenas os processos essenciais: SSH, firewall, servidor web ou banco de dados conforme a função. Quanto menos serviços rodando, menor a superfície de ataque — princípio conhecido como redução de privilegiamento de serviços.

Ferramentas de automação como Lynis (auditoria) e OpenSCAP (compliance) geram relatórios que comparam o servidor contra os controles do CIS e apontam o que ainda falta ajustar.

SSH blindado contra invasões

O SSH é a principal porta de entrada de administradores e também o alvo mais visado. Bots varrem a internet inteira procurando servidores que aceitem login root por senha. A configuração mínima recomendada pelo CIS, no arquivo /etc/ssh/sshd_config, envolve quatro mudanças:

  • Port — trocar a porta padrão 22 por outra, como 2222, reduz o ruído de bots (não substitui firewall, mas diminui log).
  • PermitRootLogin no — proíbe login direto como root; o administrador acessa com usuário comum e usa sudo.
  • PasswordAuthentication no — exige autenticação por chave criptográfica (ed25519 ou RSA 4096), eliminando senhas fracas.
  • MaxAuthTries 3 — limita tentativas por conexão.

Antes de recarregar o daemon (systemctl reload sshd), teste a nova chave em uma segunda sessão aberta para não se trancar fora. Gere as chaves com ssh-keygen -t ed25519 no cliente e copie com ssh-copy-id. Um servidor com essa combinação rejeita milhares de tentativas de força bruta por dia, como mostram incidentes em que um RCE em serviço desprotegido instalou cryptominer.

Firewall com regras restritivas

Nenhum servidor deve chegar à internet sem firewall ativo. O Linux oferece três camadas: iptables (legado, granular), ufw (front-end simplificado, padrão no Ubuntu) e nftables (sucessor moderno, presente no Debian e RHEL). O princípio é o mesmo: negar tudo por padrão e abrir apenas o necessário.

Com ufw, a configuração mínima de um servidor web fica em três comandos:

ufw default deny incoming
ufw allow 2222/tcp
ufw allow 80,443/tcp
ufw enable

No RHEL e Rocky, o firewalld oferece zonas predefinidas e integração com SELinux. Em ambientes críticos, o nftables permite tabelas com conjuntos de IP, limitação de taxa (rate limit) e log de pacotes descartados, útil para investigar tentativas de varredura.

SELinux e AppArmor em ação

Firewall controla o tráfego; controle de acesso obrigatório (MAC) controla o que cada processo pode fazer dentro do sistema. O SELinux, padrão no RHEL, Rocky, AlmaLinux e Fedora, etiqueta processos e arquivos e bloqueia ações fora da política — mesmo que o invasor consiga root. O AppArmor, padrão no Ubuntu e SUSE, usa perfis baseados em caminhos para o mesmo fim.

A regra de ouro: nunca rodar em modo permissive ou disabled em produção. Se uma aplicação quebra com SELinux enforcing, a solução é ajustar a política com audit2allow, não desligar a proteção. O comando sestatus confirma o modo atual; aureport -a mostra as negações recentes que orientam o ajuste. Em Ubuntu, aa-status lista os perfis ativos do AppArmor.

Atualizações e patches automáticos

Servidor sem atualização é convite a exploração. O pacote unattended-upgrades (Debian/Ubuntu) instala automaticamente correções de segurança, com whitelist que evita reinícios inesperados. No RHEL, o dnf-automatic faz o mesmo. Configure com:

dpkg-reconfigure -plow unattended-upgrades

Defina Automatic-Reboot "true" apenas se houver janela de manutenção. Para kernels críticos, vale o needs-restarting do RHEL, que indica quando um reboot é inevitável. A atualização constante fecha falhas como as que o SharkLoader encadeia para penetrar redes inteiras a partir de um único host.

Auditoria, logs e fail2ban

Detectar invasões exige registro detalhado. O auditd, recomendado pelo CIS, grava chamadas de sistema sensíveis: mudanças de senha, execução de comandos por root, alterações em /etc. Configure regras com auditctl e revise com ausearch -m USER_LOGIN. O journald (systemd) complementa com logs estruturados por serviço, consultáveis via journalctl -u sshd --since today.

Para conter força bruta em tempo real, o fail2ban monitora logs de SSH, web e FTP e bane IPs que falham repetidamente. Uma configuração típica em /etc/fail2ban/jail.local com maxretry = 3 e bantime = 3600 descarta bots em minutos. Em provedores brasileiros (Hetzner BR, Locaweb, OVH), combinar fail2ban com bloqueio geográfico no firewall reduz o volume de tentativas em mais de 90%.

Para servidores que processam dados de clientes, o monitoramento centralizado com Wazuh ou ELK agrega logs de várias máquinas e correlaciona eventos — passo indispensável quando o negócio responde à LGPD.

Impacto e recomendações

Hardening não é tarefa única, mas ciclo contínuo. Cada nova versão de aplicação, cada novo usuário e cada kernel atualizado exigem reauditoria. A recomendação prática para operações brasileiras, do pequeno e-commerce ao datacenter próprio:

  • Partir de CIS Benchmark Level 1 (básico, baixo impacto) antes de subir aplicação.
  • Automatizar com Ansible ou Puppet, aplicando o mesmo perfil em dezenas de servidores.
  • Reservar janela mensal para rodar Lynis ou OpenSCAP e corrigir desvios.
  • Centralizar logs e configurar alertas para logins root e mudanças de firewall.
  • Testar restauração de backup — hardening não substitui recuperação de desastre.

Servidores endurecidos segundo o CIS resistem à maioria dos ataques automatizados que assolam a internet brasileira. O esforço inicial de configuração — entre duas e seis horas por máquina — paga dividendos em estabilidade, conformidade regulatória e tranqüilidade operacional. Comece antes do primeiro byte público.