Hardening e Firewall de Servidor Linux Portugal: segurança de raiz com CIS Benchmark e política default-deny

Hardening é o processo de reduzir a superfície de ataque de um servidor: firewall com política default-deny, desativação de serviços que não são usados, remoção de pacotes desnecessários, ajuste de permissões de ficheiros sensíveis, configuração de parâmetros do kernel para resistência a ataques de rede, e ativação de auditoria de eventos críticos. Um servidor Linux por padrão — mesmo após uma instalação mínima — tem muitos serviços e portas abertas que não são necessários em produção e que representam vetores de ataque desnecessários. O hardening elimina esses vetores de forma sistemática.

Um firewall controla o tráfego de rede que entra e sai do servidor — é a primeira e mais crítica camada, mas apenas uma. Hardening é mais abrangente: cobre também o que acontece dentro do próprio servidor — permissões de ficheiros, configuração de SSH, desativação de serviços, parâmetros do kernel, política de passwords e auditoria de eventos. Por isso tratamos os dois como um serviço só: um servidor com firewall mas sem hardening continua vulnerável a ataques que passam pelas portas abertas; o hardening sem firewall deixa a porta de entrada por regular.

iptables e nftables são as ferramentas de firewall integradas no kernel Linux — extremamente poderosas mas com sintaxe complexa. UFW (Uncomplicated Firewall) é uma interface simplificada sobre elas, ideal para servidores Ubuntu/Debian com regras diretas. ConfigServer Security & Firewall (CSF) é mais completo, orientado a hosting: interface web, deteção de login failures, integração com cPanel/WHM. Para um VPS simples com Nginx e WordPress, UFW chega; para hosting com múltiplas contas, CSF é o mais indicado. Escolhemos a ferramenta certa para o contexto.

Default-deny significa que todo o tráfego de entrada é bloqueado por padrão, exceto o explicitamente permitido — abrimos apenas 80/443 para web, SSH numa porta personalizada, e o mais estritamente necessário. É a política estática: um guarda permanente nas portas. Fail2ban complementa-a com proteção dinâmica: monitoriza logs em tempo real e bloqueia automaticamente IPs com comportamento suspeito — brute force SSH, ataques ao WordPress, scans de portas. Sem Fail2ban, um IP malicioso pode tentar acesso indefinidamente mesmo com boas regras de firewall; juntos, cobrem ameaças estáticas e dinâmicas.

CIS Benchmark (Center for Internet Security) é um conjunto de boas práticas de segurança internacionalmente reconhecido, com benchmarks específicos por distribuição (Ubuntu, AlmaLinux, Debian). Usamo-lo como referência base e adaptamos ao contexto de hosting web — algumas recomendações CIS são demasiado restritivas e quebrariam aplicações legítimas. O resultado é um servidor seguro sem comprometer a funcionalidade, com relatório de compliance no final.

Sim, se feito sem cuidado. Algumas configurações de sysctl, restrições de chamadas de sistema, permissões mais restritivas ou uma porta fechada por engano podem quebrar aplicações que dependem de comportamentos menos seguros. Por isso aplicamos tudo de forma progressiva, com técnicas de aplicação temporária e reversão automática para não nos bloquearmos do servidor, testamos as aplicações após cada conjunto de alterações e documentamos cada mudança para facilitar o rollback. Num servidor de produção ativo, trabalhamos fora do horário de maior tráfego.

O SSH na porta 22 é varrido constantemente por bots automáticos. Mudar para uma porta não padrão não substitui uma boa política de segurança, mas elimina praticamente toda a atividade de scanning — de centenas de tentativas por hora para próximo de zero, combinado com autenticação por chave e Fail2ban. Geo-blocking bloqueia tráfego de países com volumes anormais de ataques e sem utilizadores legítimos; não é infalível (VPNs contornam-no), mas reduz significativamente o ruído nos logs e a carga sobre o Fail2ban.

auditd é o subsistema de auditoria do kernel Linux: regista logins SSH bem-sucedidos e falhados, execução de comandos com sudo, alterações a ficheiros sensíveis como /etc/passwd e /etc/sudoers, e outros eventos definidos nas regras. Em caso de comprometimento, os logs do auditd são frequentemente a fonte mais valiosa para forensics — permitem perceber exatamente o que o atacante fez, quando e a partir de onde. Sem auditd ativo, essa informação simplesmente não existe.

O hardening e a configuração inicial de firewall são feitos uma vez, idealmente na configuração do servidor. Depois, revemos quando há atualizações significativas do OS, quando são adicionados novos serviços ou portas, ou anualmente como auditoria de segurança. Sempre que um novo serviço é adicionado ao servidor, as regras de firewall precisam de ser atualizadas — fazemo-lo como parte da gestão contínua ou em pedido avulso.

Trabalhamos em ambos. Para servidores novos, hardening e firewall fazem parte da configuração inicial, antes de qualquer aplicação entrar em produção. Para servidores já ativos, fazemos primeiro uma auditoria do estado atual — serviços, portas, permissões, configuração SSH —, avaliamos o risco de cada alteração no contexto das aplicações existentes e aplicamos de forma progressiva com janelas de manutenção acordadas. O objetivo é sempre zero downtime não planeado.