Dia 27: Segurança e Hardening Linux — CIS, fail2ban, Auditd e Lynis

Endurecer um servidor Linux não é uma tarefa única — é um processo contínuo que combina configuração do kernel, monitorização de acessos, auditoria de eventos e avaliação periódica de vulnerabilidades. O CIS Benchmark define o padrão de referência da indústria, ferramentas como fail2ban bloqueiam ataques de brute-force em tempo real, o auditd regista chamadas de sistema sensíveis para análise forense, e o Lynis faz verificação automática de centenas de controlos de segurança. Este artigo percorre os cinco passos práticos para levar um servidor Linux de uma instalação base para um estado auditável e endurecido.

Nota: Os comandos abaixo foram validados contra documentação oficial (man7.org, Arch Wiki, kernel.org, CIS e repositórios GitHub). Antes de aplicar em produção, testar em ambiente de staging — alterações de sysctl e auditd podem afectar serviços em execução.

O que é Hardening de Servidores Linux

Hardening é o processo de reduzir a superfície de ataque de um sistema — fechar portas desnecessárias, restringir permissões, activar auditoria e aplicar configurações recomendadas pela comunidade de segurança. Um servidor Linux recém-instalado vem com configurações pensadas para compatibilidade, não para segurança. Por exemplo, o kernel permite IP forwarding em muitos casos, o SSH aceita autenticação por palavra-passe, e eventos de sistema como execuções de sudo não são registados de forma persistente.

A abordagem em camadas recomendada pelo Arch Wiki e pelo Center for Internet Security divide o hardening em quatro pilares: configuração do kernel (parâmetros sysctl), protecção activa (fail2ban, firewall), auditoria (auditd, journald) e avaliação periódica (Lynis, CIS-CAT). Cada pilar é independente mas complementar — nenhum substitui outro.

CIS Benchmarks — Padrão de Referência

O CIS (Center for Internet Security) publica guias de configuração específicos por distribuição. Cada benchmark contém centenas de recomendações numeradas (Level 1 — base, Level 2 — avançado) cobrindo instalação inicial, serviços de rede, acesso, logging, kernel e filesystem. Os benchmarks para Ubuntu, Debian e RHEL estão disponíveis gratuitamente após registo.

Os benchmarks não são scripts automáticos — são documentos de referência. As secções seguintes implementam as recomendações mais impactantes desses documentos, organizadas por ferramenta. Para validação completa, o Lynis (Passo 4) verifica automaticamente ~250 controlos, muitos dos quais mapeiam directamente para o CIS Benchmark.

Passo 1 — Hardening do Kernel com sysctl

O comando sysctl permite ler e modificar parâmetros do kernel em runtime. As configurações de segurança mais relevantes vivem em /proc/sys/ e podem ser persistidas em ficheiros sob /etc/sysctl.d/. A documentação oficial do kernel e a Arch Wiki descrevem cada parâmetro em detalhe.

O bloco abaixo cria um ficheiro de hardening que desactiva IP forwarding (a menos que o servidor seja router), activa protecção contra spoofing, syncookies e ignora pings broadcast — todas recomendações Level 1 do CIS:

# Criar ficheiro de hardening kernel
sudo tee /etc/sysctl.d/99-hardening.conf << 'EOF'
# Desactivar IP forwarding (activar se for router/firewall)
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0

# Protecção contra IP spoofing
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# SYN flood protection
net.ipv4.tcp_syncookies = 1

# Ignorar pings broadcast (smurf attack)
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Desactivar redireccionamento ICMP
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

# Desactivar source routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

# Logar pacotes com endereços impossíveis
net.ipv4.conf.all.log_martians = 1

# Protecção ptrace (restringe debugging de processos)
kernel.yama.ptrace_scope = 1
EOF

# Aplicar imediatamente
sudo sysctl --system

O ptrace_scope = 1 restringe o uso de ptrace a processos com CAP_SYS_PTRACE — isto impede que um atacante com acesso de utilizador comum injecte código noutros processos. Para servidores que não precisam de debugging de processos em produção, o valor 2 (admin-only) ou 3 (completamente desactivado) oferece protecção ainda maior.

Para verificar que os parâmetros foram aplicados:

# Listar todos os parâmetros de hardening aplicados
sysctl net.ipv4.ip_forward net.ipv4.tcp_syncookies \
       net.ipv4.conf.all.rp_filter kernel.yama.ptrace_scope

# Output esperado:
# net.ipv4.ip_forward = 0
# net.ipv4.tcp_syncookies = 1
# net.ipv4.conf.all.rp_filter = 1
# kernel.yama.ptrace_scope = 1

Passo 2 — Fail2ban contra Brute-Force

O fail2ban monitoriza ficheiros de registo e bloqueia automaticamente endereços IP que falham repetidamente a autenticação. É a ferramenta mais eficaz contra ataques de brute-force a SSH, e também protege serviços como Nginx, Apache, Postfix e Dovecot. A Arch Wiki documenta a configuração em detalhe.

Instalar nos diferentes gestores de pacotes:

# Debian/Ubuntu
sudo apt update && sudo apt install fail2ban

# RHEL/Rocky/Alma/Fedora
sudo dnf install fail2ban fail2ban-firewalld

O fail2ban lê a configuração de /etc/fail2ban/jail.conf (não editar — é substituído em actualizações) e de /etc/fail2ban/jail.local (override local). A configuração abaixo activa a jail de SSH com um ban de 1 hora após 5 tentativas falhadas:

# Criar override local
sudo tee /etc/fail2ban/jail.local << 'EOF'
[DEFAULT]
# Banir por 1 hora
bantime  = 3600
# Janela de procura (10 min)
findtime = 600
# Tentativas antes de banir
maxretry = 5
# Acção: usar iptables (ou firewalld no RHEL)
banaction = iptables-multiport

[sshd]
enabled = true
port    = ssh
logpath = %(sshd_log)s
backend = systemd
EOF

# Reiniciar e activar
sudo systemctl enable --now fail2ban
sudo systemctl restart fail2ban

Verificar o estado das jails e IPs banidos:

# Listar jails activas
sudo fail2ban-client status

# Detalhe da jail SSH
sudo fail2ban-client status sshd

# Remover um IP banido manualmente
sudo fail2ban-client set sshd unbanip 192.168.1.100

No RHEL/Rocky com firewalld activo, substituir banaction = iptables-multiport por banaction = firewallcmd-ipset para integrar com o firewall nativo.

Passo 3 — Auditd para Auditoria de Sistema

O auditd é o daemon de auditoria do kernel Linux. Regista chamadas de sistema sensíveis — execuções de comandos, acessos a ficheiros de configuração, mudanças de permissões, sessões de sudo — num registo persistente em /var/log/audit/audit.log. A Arch Wiki e as man pages documentam a configuração completa.

Instalar e activar:

# Debian/Ubuntu
sudo apt install auditd audispd-plugins

# RHEL/Rocky/Alma (já vem instalado por defeito)
sudo dnf install audit

# Activar e iniciar
sudo systemctl enable --now auditd

O auditctl (man page) define regras de auditoria. O bloco abaixo regista execuções de comandos privilegiados, acessos a ficheiros de senha e mudanças em configuração de rede:

# Registar todas as execuções de comandos com SUID
sudo auditctl -a always,exit -F arch=b64 -S execve -C uid!=0 -F auid!=4294967295 -k privileged

# Monitorizar acessos ao /etc/passwd e /etc/shadow
sudo auditctl -w /etc/passwd -p wa -k identity
sudo auditctl -w /etc/shadow -p wa -k identity
sudo auditctl -w /etc/group -p wa -k identity

# Monitorizar mudanças em configuração de rede
sudo auditctl -w /etc/hosts -p wa -k network
sudo auditctl -w /etc/sysconfig/network -p wa -k network

# Persistir regras através de reboot
# As regras acima são voláteis. Para persistir:
sudo sh -c 'auditctl -l > /etc/audit/audit.rules'

# No RHEL, as regras persistentes ficam em:
# /etc/audit/rules.d/audit.rules

Consultar eventos com ausearch e aureport (ambas documentadas em man ausearch e man aureport):

# Procurar eventos por chave (key definido nas regras)
sudo ausearch -k identity

# Relatório de execuções de comandos privilegiados hoje
sudo aureport --start today -k --summary

# Relatório de tentativas de login falhadas
sudo aureport --start today --login

# Listar regras activas
sudo auditctl -l
Atenção: As regras auditctl definidas em runtime perdem-se após reboot. No Debian/Ubuntu, executar sudo sh -c 'auditctl -l > /etc/audit/audit.rules' para persistir. No RHEL/Rocky, colocar as regras em /etc/audit/rules.d/audit.rules e executar sudo augenrules --load.

Passo 4 — Lynis para Verificação de Vulnerabilidades

O Lynis é uma ferramenta de código aberto de auditoria de segurança que verifica ~250 controlos num servidor Linux: configuração SSH, permissões de ficheiros, serviços desnecessários, kernel hardening, SSL de serviços web, configuração de bases de dados e muito mais. O código-fonte está no GitHub.

Instalar a partir dos repositórios ou do GitHub:

# Debian/Ubuntu
sudo apt install lynis

# RHEL/Rocky/Alma (via EPEL)
sudo dnf install epel-release && sudo dnf install lynis

# Ou instalar a versão mais recente do GitHub
cd /opt
sudo git clone https://github.com/CISOfy/lynis.git
sudo /opt/lynis/lynis show version

Executar o scan completo:

# Scan completo (cerca de 2-5 minutos)
sudo lynis audit system

# Scan com output em ficheiro + formato cron
sudo lynis audit system --quiet --pentest

# Ver relatório da última execução
sudo lynis show details TEST-ID

# O relatório fica em:
# /var/log/lynis.log
# /var/log/lynis-report.dat

O Lynis atribui um Hardening Index (0-100) no fim do scan. Um servidor recém-instalado tipicamente obtém 50-65; após aplicar as recomendações deste artigo, o valor sobe para 75-85. As recomendações estão categorizadas por prioridade (sugestões, avisos, erros) e cada item indica o ficheiro de configuração a alterar.

Parâmetro Lynis O que Verifica Acção Recomendada
SSH-7408 PermitRootLogin Definir PermitRootLogin no
KRNL-6000 sysctl hardening Aplicar ficheiro 99-hardening.conf
AUTH-9208 Mínimo de dias entre mudanças de palavra-passe Configurar PAM
FILE-6362 Permissões de /etc/passwd Garantir 644
PROC-3802 ptrace_scope Definir kernel.yama.ptrace_scope >= 1

Passo 5 — Hardening SSH Adicional

O artigo do Dia 10 cobriu o básico de SSH. Aqui adicionamos as configurações de hardening que o CIS Benchmark recomenda para além das chaves SSH e mudança de porta. A Arch Wiki documenta estas opções em detalhe.

# Editar /etc/ssh/sshd_config
sudo tee /etc/ssh/sshd_config.d/99-hardening.conf << 'EOF'
# Desactivar login directo como root
PermitRootLogin no

# Apenas autenticação por chave (desactivar passwords)
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

# Limitar utilizadores autorizados
AllowUsers admin deploy

# Timeout de sessão inactiva (300s)
ClientAliveInterval 300
ClientAliveCountMax 0

# Desactivar X11 forwarding se não for necessário
X11Forwarding no

# Desactivar tunneling se não for necessário
AllowTcpForwarding no
PermitTunnel no

# Algoritmos modernos apenas (remover legados)
KexAlgorithms curve25519-sha256,[email protected]
MACs [email protected],[email protected]
Ciphers [email protected],[email protected],[email protected]
EOF

# Validar configuração antes de reiniciar
sudo sshd -t

# Reiniciar serviço
sudo systemctl restart sshd
Atenção: Antes de definir PasswordAuthentication no, garantir que pelo menos um utilizador tem chave SSH configurada e acesso confirmado. Bloquear o acesso por palavra-passe sem alternativa válida resulta em perda de acesso ao servidor.

O sshd -t valida a sintaxe do ficheiro de configuração sem reiniciar o serviço — executar sempre antes de systemctl restart para evitar deixar o SSH em estado inoperável.

Erros Comuns

Problema Causa Solução
sysctl: cannot stat Parâmetro não existe no kernel actual Verificar com sysctl -a | grep nome e remover do ficheiro
fail2ban não bane IPs Backend de log incorrecto Confirmar backend = systemd em sistemas com journald
auditd: regras perdem-se após reboot Regras definidas em runtime não são persistentes Persistir com auditctl -l > /etc/audit/audit.rules (Debian) ou augenrules --load (RHEL)
Lynis reporta versão desactualizada Pacote do repositório é antigo Instalar do GitHub (git clone) para versão mais recente
SSH: Permission denied após hardening PasswordAuthentication desactivado sem chave configurada Reverter temporariamente via consola física ou recuperação
Serviços deixam de funcionar após sysctl IP forwarding desactivado em router/VPN Reactivar net.ipv4.ip_forward = 1 se o servidor for router

Checklist de Hardening

Lista de verificação para aplicar antes de considerar um servidor endurecido:

  1. Kernel: Criar /etc/sysctl.d/99-hardening.conf e executar sysctl --system
  2. Fail2ban: Instalar, criar jail.local com jail SSH activa, garantir systemctl enable fail2ban
  3. Auditd: Instalar, definir regras para identidade e rede, persistir regras para sobreviver a reboot
  4. SSH: Desactivar PermitRootLogin e PasswordAuthentication, validar com sshd -t antes de reiniciar
  5. Lynis: Executar lynis audit system, registar Hardening Index, corrigir avisos prioritários
  6. Firewall: Confirmar que firewall (nftables/UFW/firewalld) está activo com regras mínimas — ver Dia 9
  7. Actualizações: Configurar actualização automática de segurança ou processo de revisão manual regular
  8. Documentação: Guardar saída do Lynis e configuração aplicada para auditoria futura
Nota: O hardening é iterativo. Executar o Lynis mensalmente e após cada mudança significativa no servidor. O CIS Benchmark actualiza as recomendações periodicamente — consultar a versão mais recente antes de auditorias de compliance.

Artigos Relacionados