Hardening de Linux em 2026: o guia que começa pelo modelo de ameaça

A maioria dos guias de hardening de Linux são checklists. Dizem-lhe que flags sysctl definir, que serviços desativar, que módulos do kernel colocar na blacklist. Raramente respondem à pergunta prévia: contra que ameaça se está realmente a defender?

A resposta muda o trabalho. Um jornalista que protege fontes de malware dirigido precisa de medidas muito diferentes de um administrador de sistemas que reduz a superfície de ataque num servidor sem ameaças físicas. Este guia parte do modelo de ameaça para a medida, não da medida para a justificação.

Está enraizado na linhagem de segurança deste domínio — o mesmo pensamento operacional que animou a lista de correio Secure Desktops (2015–2017), onde os programadores do Qubes OS, Tails e Subgraph debatiam hardening prático sem o marketing.

Passo zero: defina o seu modelo de ameaça

Antes de tocar num único ficheiro de configuração, responda a estas quatro perguntas:

1. Quem é o adversário? Oportunista casual, criminoso organizado, investigador empresarial, Estado-nação?
2. O que procuram? Ficheiros no disco, comunicações, credenciais, a sua identidade, os seus contactos?
3. Como vão entrar? Exploração de rede, acesso físico, cadeia de fornecimento, engenharia social?
4. Que recursos têm? Tempo, dinheiro, zero-days, autoridade legal?

As medidas deste guia estão agrupadas pela ameaça que abordam. Aplique apenas as camadas que correspondem às suas respostas. Fazer um hardening excessivo de uma estação de trabalho cria atrito sem um ganho de segurança proporcional, e o atrito leva as pessoas a contornar os controlos.

Hardening do kernel: parâmetros sysctl

Os parâmetros seguintes são apropriados para a maioria das instalações desktop e de servidor hardenizadas. Não exigem hardware especializado e não têm um impacto significativo no desempenho.

# /etc/sysctl.d/99-hardening.conf

# Restrict kernel pointers from userspace (defeats certain info-leak attacks)
kernel.kptr_restrict=2

# Restrict dmesg access to root (prevents attackers reading kernel memory addresses)
kernel.dmesg_restrict=1

# Disable SysRq key (prevents certain physical-access attacks)
kernel.sysrq=0

# Restrict ptrace to processes with CAP_SYS_PTRACE (limits debug attach)
kernel.yama.ptrace_scope=2

# Disable unprivileged user namespaces (large attack surface, rarely needed on desktops)
kernel.unprivileged_userns_clone=0

# Disable unprivileged eBPF (significant attack surface for CVE exploitation)
kernel.unprivileged_bpf_disabled=1

# Enable TCP SYN cookies (basic DoS resistance)
net.ipv4.tcp_syncookies=1

# Disable ICMP redirects (routing manipulation attacks)
net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.default.accept_redirects=0
net.ipv6.conf.all.accept_redirects=0

# Disable source routing (rarely legitimate, used in spoofing attacks)
net.ipv4.conf.all.accept_source_route=0

# Enable reverse path filtering (defeats IP spoofing)
net.ipv4.conf.all.rp_filter=1

# Disable core dumps (prevents memory exposure of crashed processes)
fs.suid_dumpable=0

# Restrict symlink and hardlink following (prevents certain privilege escalation attacks)
fs.protected_symlinks=1
fs.protected_hardlinks=1

Aplique de imediato sem reiniciar:

sudo sysctl -p /etc/sysctl.d/99-hardening.conf

Aquilo de que estes não protegem: são parâmetros ajustáveis ao nível do kernel, não defesas ao nível da aplicação. Uma exploração do navegador que não precise de ptrace, user namespaces ou eBPF não é afetada pelos parâmetros relevantes. São uma camada de apoio, não um substituto do isolamento de aplicações (consulte o Qubes OS se o isolamento for o seu requisito principal).

Mandatory Access Control: AppArmor vs SELinux

Tanto o AppArmor como o SELinux implementam o Mandatory Access Control (MAC): uma camada de política que restringe o que os processos podem fazer, independentemente das permissões dos ficheiros. O MAC impõe o princípio do menor privilégio ao nível do kernel.

AppArmor (predefinição em Ubuntu, Debian, SUSE)

O AppArmor usa perfis baseados em caminhos. Cada aplicação recebe um perfil que especifica que ficheiros pode ler, escrever ou executar, que capacidades pode usar e que operações de rede são permitidas. Os perfis operam em dois modos: enforce (as violações são bloqueadas e registadas) e complain (as violações são registadas mas permitidas — útil durante o desenvolvimento).

# Check AppArmor status
sudo apparmor_status

# List all loaded profiles
sudo aa-status

# Put a profile into enforce mode
sudo aa-enforce /etc/apparmor.d/usr.bin.firefox

# Generate a new profile for an application
sudo aa-genprof /usr/bin/myapp

Os repositórios do Ubuntu e do Debian incluem perfis pré-escritos para aplicações comuns. Instale-os:

sudo apt install apparmor-profiles apparmor-profiles-extra

Recomendação prática: num sistema Ubuntu ou Debian, garanta que o AppArmor está ativado no arranque (verifique com sudo apparmor_status | grep "profiles are in enforce mode") e que o Firefox, o Chromium e quaisquer processos de servidor (nginx, sshd, cups) correm com perfis em modo enforce.

SELinux (predefinição em Fedora, RHEL, CentOS)

O SELinux usa políticas baseadas em rótulos. Cada processo, ficheiro, socket e utilizador recebe um contexto de segurança (um rótulo), e as regras da política definem que contextos podem interagir. É mais granular do que o AppArmor mas significativamente mais complexo de manter.

No Fedora, o SELinux está ativado em modo Enforcing por predefinição. Verifique:

getenforce
# Should output: Enforcing

Não desative o SELinux. Uma resposta comum e errada aos negações do SELinux é setenforce 0. Em vez disso, diagnostique a negação:

sudo ausearch -m avc -ts recent | audit2allow -a

A ferramenta audit2allow sugere módulos de política que permitiriam a ação negada. Reveja-os antes de os aplicar — o objetivo é perceber por que ocorreu a negação, não permiti-la em bloco.

Parâmetros de arranque do kernel

Os parâmetros de arranque (definidos na configuração do GRUB) aplicam-se mais cedo no processo de arranque do que o sysctl e abordam superfícies de ataque diferentes.

Adicione a GRUB_CMDLINE_LINUX em /etc/default/grub e depois execute sudo update-grub:

# Disable SMT if you have a high-threat CPU side-channel model (Spectre, MDS)
# Performance cost: significant (up to 30–50% on multi-threaded workloads)
# Only appropriate for threat models involving local co-tenancy or targeted CPU attacks
# mitigations=auto,nosmt

# Enable all CPU vulnerability mitigations (default on most distros, worth verifying)
mitigations=auto

# Randomize page allocation (increases difficulty of certain heap exploitation)
page_alloc.shuffle=1

# Enable kernel lockdown (Integrity or Confidentiality mode)
# Locks down several features used by rootkits; may break some functionality
lockdown=integrity

# Disable old IPv4 network protocols rarely used (reduce attack surface)
ipv6.disable=0   # Keep IPv6 enabled; disable if genuinely unused

# Disable Firewire DMA (physical access attack vector on older hardware)
module.sig_enforce=1

Nota sobre lockdown=confidentiality: este modo impede mesmo o root de ler a memória do kernel através de /dev/mem e interfaces semelhantes. Quebra alguns usos legítimos (certos controladores, kexec, hibernação). Use o modo integrity a menos que tenha um motivo específico para confidentiality.

Hardening do sistema de ficheiros e dos serviços

Opções de montagem

Em /etc/fstab, adicione opções de montagem de segurança onde for apropriado:

# /tmp: no execution, no device files, no SUID bits
tmpfs /tmp tmpfs defaults,noexec,nodev,nosuid 0 0

# /var/tmp: same
tmpfs /var/tmp tmpfs defaults,noexec,nodev,nosuid 0 0

# /home: no device files, no SUID (noexec breaks some workflows — test first)
/dev/mapper/home /home ext4 defaults,nodev,nosuid 0 2

Desative os serviços não utilizados

Cada serviço em execução é uma superfície de ataque. Num desktop:

# List enabled services
systemctl list-unit-files --state=enabled

# Common candidates for disabling on a desktop with no network service requirements:
sudo systemctl disable cups   # Printing — if you never print
sudo systemctl disable avahi-daemon  # mDNS — if you don't need .local resolution
sudo systemctl disable bluetooth  # If not using Bluetooth

Num servidor, o princípio é mais agressivo: apenas os serviços necessários à função declarada da máquina devem correr. Cada socket à escuta deve ter um motivo documentado para existir.

Verified Boot e Secure Boot

O Secure Boot com as suas próprias chaves registadas (não apenas as chaves Microsoft predefinidas) protege contra bootkits que carregam antes do sistema operativo. No Fedora e no Ubuntu, as distribuições assinam o seu bootloader e kernel com chaves em que o firmware UEFI confia por predefinição.

Para uma configuração de maior garantia, substitua as chaves predefinidas pelas suas:

1. Gere a sua própria Platform Key (PK) e Key Exchange Key (KEK).
2. Registe a sua chave no firmware UEFI (o processo varia conforme o fabricante).
3. Assine o seu bootloader e kernels com a sua chave usando sbsign.
4. Desative “Other OS” ou “Compatibility Support Module” no firmware UEFI.

Isto é operacionalmente complexo e, em geral, apropriado apenas para implementações de alta ameaça. O projeto de firmware Heads e projetos semelhantes vão mais longe, estendendo o measured boot a uma cadeia de confiança ancorada no TPM.

Checklist por modelo de ameaça

Oportunista / malware em massa: predefinições de sysctl acima, AppArmor/SELinux em enforcing, disco encriptado (LUKS), atualizações regulares. Isto trata 95% das ameaças comuns.

Atacante dirigido com acesso à rede: adicione a minimização de serviços, uma firewall restritiva (nftables/ufw), o sandboxing de aplicações (Firejail ou Flatpak), a monitorização do tráfego de saída da rede.

Adversário com acesso físico e recursos: encriptação de disco completo com frase-passe forte + cópia de segurança do cabeçalho, Secure Boot com chaves personalizadas, Tails OS para operações sensíveis, considere o Qubes OS para a compartimentação. Reveja a carta da Secure Desktops para os princípios operacionais por trás destas escolhas.

Nível estatal / Estado-nação: pondere se uma estação de trabalho Linux hardenizada é sequer a ferramenta certa. O Qubes OS com uma arquitetura de qubes cuidadosa está mais próximo do instrumento adequado. Máquinas air-gapped para as operações mais sensíveis. Nenhum ponto único de falha para o material criptográfico.

FAQ

P: Desativar os user namespaces não privilegiados quebra alguma coisa? R: Quebra as aplicações que dependem deles sem root — nomeadamente o sandboxing do Chromium em sistemas que o usam, e certos runtimes de contentores (Docker/Podman rootless). No Ubuntu/Debian desktop, provavelmente terá de o reativar para o Chromium. O compromisso está documentado; decida com base no seu modelo de ameaça.

P: Devo usar um kernel hardenizado (linux-hardened no Arch, ou grsecurity)? R: O linux-hardened no Arch Linux aplica um conjunto razoável de patches de hardening upstream e vale a pena usá-lo se estiver no Arch. Os patches do grsecurity já não estão disponíveis publicamente. O kernel upstream absorveu muitas funcionalidades antes exclusivas do grsecurity (KASLR, stack protector, FORTIFY_SOURCE, etc.) desde o final da década de 2010.

P: O Fedora ou o Ubuntu é mais hardenizado de raiz? R: Ambos são fornecidos com MAC em enforcing (SELinux no Fedora, AppArmor no Ubuntu), predefinições modernas de mitigação do kernel e atualizações de segurança automáticas. O Fedora geralmente fornece versões mais recentes do kernel mais depressa. O Ubuntu LTS troca o que há de mais avançado pelo suporte a longo prazo. Para uma estação de trabalho hardenizada, qualquer um é um ponto de partida razoável; as medidas deste guia aplicam-se a ambos.