Lições práticas de hardening em Linux/systemd, escritas a partir de auditorias reais e de erros de configuração corrigidos na marra — não teoria de curso, registro de "isso pareceu seguro e não era, aqui está o porquê e como confirmar por conta própria". A ideia não é "aplique o patch e siga", é entender por que o problema existe, como mitigar sem depender só de esperar uma atualização, e como auditar uma máquina já em uso pra confirmar que ela não foi alvo antes da correção.
Todo achado aqui é generalizado: nomes de máquina, IPs, domínios e qualquer identificador específico de ambiente foram removidos ou substituídos por exemplos genéricos. O valor não está em "de onde veio", está no padrão técnico — a mesma classe de erro reaparece em qualquer VPS, qualquer desktop Linux com systemd recente, qualquer stack Docker.
Escrito em português e inglês (*.en.md ao lado de cada arquivo principal); nem toda entrada tem as duas versões ainda, mas a intenção é chegar lá.
| Tema | Componente | Severidade | Status |
|---|---|---|---|
| CVE | CVE-2026-4105 — systemd-machined |
CVSS 6.7 (Medium) | Mitigável via mask --now |
docs/systemd-attack-surface-reduction.md— metodologia genérica e reutilizável pra mapear e reduzir a superfície de daemons IPC privilegiados ativados por padrão no systemd, incluindo como cruzar com CVEs conhecidas viaarch-audit.docs/init-system-alternatives.md— avaliação de quando trocar de init system (systemd → runit/dinit/OpenRC) reduz essa classe de risco, e quando é só trocar de fornecedor sem ganho real.docs/ssh-hardening-cloud-servers.md/ English — o bug de precedência doIncludenosshd_configque faz um servidor parecer protegido e não estar, vetor de túnel SSH reverso, a pegadinha Docker Swarm vs UFW, e por que automação com tool-use rodando como root é o pior achado possível numa auditoria desse tipo.
audits/firewall-application-control/(English) — firewall de aplicação rodando em modo "permitir tudo" por config default, capacidade fixa de mapa BPF causando crash-loop ao carregar blocklist grande, UFW aceitando mDNS/SSDP por padrão do próprio template, a corrida entre script externo e o live-reload do próprio daemon ao escrever regra direto no arquivo, e um daemon de enforcement próprio morrendo em silêncio (sem crash-loop) no ciclo de suspend/resume por confundirEINTRespúrio do freezer do kernel com o sinal de shutdown de verdade.audits/desktop-surface-review/(English) — dez lugares onde superfície de ataque se esconde num desktop Linux moderno: autostart virando unit systemd sozinho, socket SSH local ativo mesmo com o serviço desabilitado, rastreio de processo órfão via journal, isolamento de GPU, verificação direta de hooks eBPF/LSM no kernel.audits/enforcement-drift-detection/(English) — a pergunta que vem depois de corrigir tudo: como saber, meses depois, que continua corrigido? Risco de drift acompanha onde a mitigação está gravada (arquivo de pacote reverte, arquivo seu sobrevive), por que indeterminado nunca pode virar OK, o teste diferencial que de fato prova enforcement, seis armadilhas que só aparecem rodando contra o estado real da máquina, e um terceiro jeito de regredir: correção de incidente que resolve só o sintoma e deixa o resto do baseline documentado sem ninguém notar.
research/kubearmor-bpf-lsm/— leitura guiada do enforcement BPF-LSM real do KubeArmor, referenciando commit exato do código-fonte lido.
scripts/systemd-surface-audit.sh(English, +.service/.timer) — auditoria read-only da superfície de daemons IPC do systemd, agendável viasystemctl --user. Comentado pra explicar o "porquê" de cada checagem, não só o comando.scripts/update-net-guard-blocklist.sh(English) — gera blocklist a partir da lista Spamhaus DROP respeitando um teto de capacidade (ver a lição do crash-loop emaudits/firewall-application-control/).CVE-2026-4105-systemd-machined/audit-checklist.sh(English) — checklist de auditoria pós-fato, com nota inline do que um resultado normal vs. suspeito parece em cada seção.
- O que é o problema — descrição técnica, vetor, fontes primárias.
- Por que importa nesse contexto — nem todo achado é urgente; a análise cobre se o componente está de fato em uso.
- Mitigação — comandos reproduzíveis, preferindo remover a superfície de ataque a confiar só em esperar patch.
- Auditoria pós-fato — como verificar, com o que já vem no sistema, se a falha foi explorada antes da correção.
Este repositório é para fins educacionais e de hardening defensivo. Os exemplos foram generalizados a partir de auditorias reais; identificadores específicos de máquina, rede ou organização (hostname, IP, domínio, nome de serviço interno) não aparecem em nenhum arquivo — onde a lição exigia um exemplo concreto, foi usado um cenário ilustrativo, não um ambiente real identificável.