CVE-2026-31431-mitigation-suite

Framework de defesa em tempo de execução do kernel para vulnerabilidades AF_ALG, com rastreamento de sockets via eBPF, endurecimento com Ansible e um auditor criptográfico para detecção de desvios.

Em uma build empresarial típica:

• Quase nenhum software de espaço do usuário o exige. OpenSSL, GnuTLS, libsodium e systemd-cryptsetup usam outros caminhos por padrão.
• Adversários estão interessados nele. É um pivô recorrente em cadeias de escalonamento de privilégios (CVE-2019-8912, CVE-2017-13215 e outras) justamente porque é acessível a partir de contêineres sem privilégios quando namespaces de usuário estão disponíveis.
• É invisível para a maioria dos EDRs. Ferramentas de endpoint que interceptam connect(), bind() ou DNS não veem nada — o tráfego AF_ALG nunca sai do kernel.

Esta estrutura trata cada criação de socket AF_ALG como um evento de alto sinal e reduz a superfície que torna esses eventos exploráveis.

Modelo de ameaça e mapeamento Zero Trust

Estrutura do repositório

Componentes

1. Observabilidade em tempo de execução — rastreador eBPF

ebpf/af_alg_tracer.py anexa um kprobe a security_socket_create. A sonda filtra em family == 38 no nível do programa BPF para que o verificador elimine criações de socket não relacionadas e a sobrecarga por evento permaneça em nanossegundos. Ela emite um registro JSON por tentativa:

Envie a saída padrão para Vector, Fluent Bit ou journald (via systemd-cat). Uma lista de permissões por nome de comm (/etc/af-alg-defense/allow.list) suprime consumidores conhecidos e legítimos sem perder a capacidade de detectar desvios.

O alvo do kprobe é o hook LSM, então os eventos disparam com base na intenção — mesmo tentativas que seriam negadas por seccomp ou RestrictAddressFamilies ainda produzem um registro. Isso é exatamente o que um SOC deseja para baseline comportamental.

2. Configuração como Código — role Ansible + drop-in systemd

ansible/roles/af_alg_hardening/ aplica duas camadas de endurecimento:

Drop-in sysctl (/etc/sysctl.d/90-af-alg-defense.conf):

• kernel.unprivileged_userns_clone=0 — remove o pivô userns usado pela maioria das cadeias de escalonamento AF_ALG.
• user.max_user_namespaces=0 — defesa em profundidade portável entre distribuições.

Drop-in systemd (/etc/systemd/system/<unit>.d/50-af-alg-restrict.conf): Usa RestrictAddressFamilies como uma lista de permissões (não lista de negações). A unidade tem permissão para AF_UNIX AF_INET AF_INET6 AF_NETLINK; qualquer outra família — incluindo AF_ALG — falha com EAFNOSUPPORT porque o systemd a aplica por meio de BPF anexado a cgroups que o aplicativo não pode desabilitar. O drop-in também remove CAP_SYS_ADMIN e aplica ProtectKernel* para fechar os caminhos de escalonamento mais comuns.

Aplique com:

Para hosts sem Ansible, coloque o arquivo autônomo no lugar:

3. Auditor de estado do kernel

auditor/crypto_auditor.py produz um relatório JSON de postura de segurança ao inspecionar:

• /proc/crypto — toda cifra / hash / aead registrado, com flags FIPS e status de autoteste.
• /sys/module/ — módulos carregados na subárvore de criptografia, com flags de taint e snapshots de parâmetros.
• /proc/sys/kernel/, /proc/sys/user/ — sysctls que controlam os caminhos de ataque do AF_ALG.
• /sys/kernel/security/lockdown — modo de lockdown do kernel.

O relatório é indexado por IDs de descoberta estáveis (FND-001 a FND-005 no momento) para que regras de SIEM possam suprimir descobertas individuais sem descartar o documento inteiro. A detecção de desvio compara a postura com uma linha de base:

O esquema está em schemas/audit_report.schema.json (Draft 2020-12) e é validado no CI a cada push.

4. Integração contínua

.github/workflows/ci.yml executa quatro jobs a cada push e PR:

1. ShellCheck — todo *.sh e script com shebang.
2. Validação de esquema — verificação de metaesquema em audit_report.schema.json, depois executa o auditor ao vivo no kernel do runner do GH e valida o relatório resultante. Fixtures em tests/fixtures/ também são verificadas.
3. Lint Python (ruff check .).
4. Lint Ansible na árvore da role.

Uma falha na verificação de esquema bloqueia merges, o que impede que parsers de SIEM downstream quebrem por causa de um campo renomeado silenciosamente.

Orientação operacional para SOC

Regras de detecção para sobrepor

• Qualquer evento af_alg_socket_create de um comm não permitido — acione na primeira ocorrência, não agregue.
• Nova entrada em crypto_modules entre execuções consecutivas do auditor em um host onde o carregamento de módulos deve estar congelado.
• Qualquer sysctl com hardened=false após uma execução do playbook de endurecimento — indica adulteração manual ou desvio de um sistema de configuração paralelo.
• O campo lockdown transiciona de integrity/confidentiality para none — forte indicador de adulteração do estado do kernel.

Plano de implantação (recomendado)

1. Implante o rastreador eBPF em modo somente monitoramento por duas semanas. Use a linha de base resultante para preencher allow.list para consumidores conhecidos e legítimos (cryptsetup na inicialização é o usual).
2. Execute o auditor contra uma frota de hosts representativa; capture a postura como baseline.json assinado.
3. Aplique a role Ansible a um grupo canário com af_alg_systemd_services definido para uma unidade de baixo risco. Observe erros EAFNOSUPPORT no journald.
4. Expanda a lista de serviços iterativamente. systemd-analyze security <unit> deve mostrar que a restrição está aplicada.
5. Conecte o auditor a um cron noturno com --fail-on-drift e encaminhe saídas não zero para a fila de plantão.

O que esta estrutura não faz

• Ela não descarrega af_alg se ele já estiver em uso. Descarregamento de módulos está fora do escopo porque consumidores legítimos em tempo de inicialização podem ainda estar em execução. Use modprobe.blacklist=af_alg na linha de comando do kernel se você confirmou que nada no host precisa dele.
• Ela não corrige CVEs. Atualizações de kernel do fornecedor permanecem o controle primário; esta estrutura reduz o custo de um patch perdido.
• Ela não protege contra root. Um root local pode desabilitar qualquer um desses controles; a estrutura eleva a barra até root, não além dela.

Requisitos

• Linux ≥ 4.18 (para o alvo kprobe security_socket_create).
• BCC ≥ 0.25 ou libbpf ≥ 1.0, além de headers do kernel correspondentes a uname -r.
• Python 3.10+ nos hosts gerenciados.
• Ansible 2.14+ no nó de controle.
• CAP_BPF (ou root) para carregar o rastreador; acesso de leitura a /proc/crypto para o auditor (nenhum privilégio é necessário para lê-lo).

Licença

Apache-2.0. Consulte LICENSE.