Hardening de Linux Servidor: CIS Benchmark Aplicado sem Quebrar Producao

Aplicar o CIS Benchmark inteiro de uma vez em um servidor Debian 12 que atende 40 mil requisicoes por minuto e a forma mais rapida de transformar uma sexta-feira em um incidente de severidade 1. A gente do time Basilisk ja viu mais de uma equipe rodar o script ansible-lockdown puro em producao e descobrir, as 3h da manha, que o controle 5.2.16 desativou o login do usuario que orquestrava o backup do Postgres. Hardening serio nao e copiar 380 controles do PDF: e escolher os 60 que valem o risco, testar em staging com a mesma carga, e ter telemetria pra saber em quanto tempo voce reverte se algo quebrar.

O ponto de partida correto e separar os controles em quatro buckets antes de tocar em qualquer servidor. Bucket 1: kernel e boot (sysctl, GRUB, modulos), baixo risco de quebrar app, alto ganho. Bucket 2: rede e firewall (nftables, ipv6, ICMP), risco medio se voce nao mapeou todas as portas. Bucket 3: autenticacao, PAM e SSH, onde mora a maior parte dos incidentes pos-hardening. Bucket 4: auditd, syslog e integridade (AIDE), praticamente zero risco operacional. Comece pelo bucket 4, depois 1, depois 2, e deixe SSH e PAM por ultimo. Se voce ja esta refazendo o SSH, leia Hardening de SSH 2026: Algoritmos, Certificados e Bastion Hosts antes de mexer no sshd_config porque os algoritmos mudaram em 2026.

Para inventariar o estado atual, use o openscap-scanner com o profile xccdf_org.ssgproject.content_profile_cis_level2_server do projeto ComplianceAsCode. Em um Ubuntu 24.04 limpo voce vai ver entre 110 e 140 controles em estado fail, o que e normal. Exporte o relatorio HTML, importe no Jira como uma epica por bucket, e estime esforco em pontos de risco e nao em horas. O segredo aqui e nunca aplicar uma remediation sem ler o rationale, porque metade das recomendacoes do CIS Level 2 quebra workloads modernos: desabilitar usb-storage faz sentido em um bastion, nao em um host que escreve dump em pendrive criptografado para air gap.

A camada de kernel rende um ganho enorme com pouco risco se voce souber o que esta tunando. kernel.kptr_restrict=2, kernel.dmesg_restrict=1, kernel.yama.ptrace_scope=2 e fs.protected_hardlinks=1 sao gratuitos. Ja kernel.unprivileged_userns_clone=0 quebra Docker rootless, Podman, Bubblewrap e qualquer sandbox de aplicacao, entao se voce roda containers ou usa as tecnicas de Sandbox de Aplicacoes no Linux com Bubblewrap, Firejail e Flatpak, deixe esse em 1 e documente o desvio formalmente. Para servicos com perfil de ataque alto considere SELinux em modo enforcing com politica targeted customizada, conforme detalhamos em SELinux sem Medo: Politicas Customizadas para Servicos Criticos com exemplo completo para um Nginx exposto.

Validacao e a parte que ninguem faz direito. Suba um ambiente espelho em LXD ou Proxmox com o mesmo kernel, o mesmo glibc e a mesma versao dos servicos, e rode um perfil de carga com k6 ou wrk replicando 30 minutos de trafego real capturado via tcpdump. Aplique os controles em batches de 10, rode o teste, compare p95 de latencia e taxa de erro. Se a regressao for maior que 3% voce isolou qual controle e o culpado por bisecao. Tambem rode atomic-red-team com tecnicas mapeadas ao MITRE ATT&CK pra confirmar que o hardening realmente reduz a superficie: a logica e a mesma de Adversary Emulation com Caldera e MITRE ATT&CK em Lab Corporativo, so que focada em pos-exploracao no host endurecido.

Auditd quase sempre vira gargalo se voce copiar o ruleset do CIS sem pensar. As regras default geram entre 8 e 15 mil eventos por minuto em um host medio, enchem /var/log em 6 horas e fazem o journald comecar a descartar. A receita que usamos no Basilisk e cortar as regras de execve por usuarios de servico conhecidos (postgres, nginx, app) e manter monitoramento agressivo so para uid 0, sudo e shells interativas. Encaminhe via auditd-plugin para um pipeline Sigma como mostramos em Threat Hunting com Sigma e Elastic: Do Indicador a Regra de Deteccao, senao voce ta gerando ruido caro sem nenhuma deteccao acionavel do outro lado.

Para servidores que tocam dados sensiveis ou que voce nao consegue acessar fisicamente, complemente o hardening com cripto de disco resiliente a coercao e backup verificado, seguindo o que discutimos em Cripto de Disco e Backups: Veracrypt, LUKS e Estrategia 3-2-1 Resiliente. LUKS2 com Argon2id, chave em TPM2 selada com PCR0+PCR7, e snapshot encriptado em storage offsite resolvem o caso de roubo fisico do datacenter. Combinado com Secure Boot, modulos assinados e GRUB com senha (controles CIS 1.4.x), voce eleva o custo de um ataque presencial para algo que so vale a pena contra alvos muito especificos.

Takeaway pratico: monte uma planilha com cada controle CIS que voce aplicou, a versao do pacote no momento, o resultado do openscap pre e pos, e o delta de latencia medido em staging. Rode essa planilha a cada release maior do SO (Debian point release, LTS upgrade) porque sysctls mudam de default e auditd ganha campos novos. Hardening nao e projeto, e processo: se em 6 meses voce nao conseguir provar via scan automatizado que os 60 controles continuam ativos no host, voce nao tem hardening, voce tem fe.