CVE-2026-31431-mitigation-suite

Framework de défense au niveau du noyau pour les vulnérabilités AF_ALG, doté d'un traçage de sockets eBPF, d'un durcissement Ansible et d'un auditeur cryptographique pour la détection de dérives.

Dans une configuration d'entreprise typique :

• Presque aucun utilisateur n'en a besoin. OpenSSL, GnuTLS, libsodium et systemd-cryptsetup utilisent tous d'autres chemins par défaut.
• Les adversaires s'y intéressent. C'est un point de pivot récurrent dans les chaînes d'élévation de privilèges (CVE-2019-8912, CVE-2017-13215, et d'autres) précisément parce qu'il est accessible depuis des conteneurs non privilégiés lorsque les espaces de noms utilisateur sont disponibles.
• Il est invisible pour la plupart des EDR. Les outils de point de terminaison qui interceptent connect(), bind() ou le DNS ne voient rien — le trafic AF_ALG ne quitte jamais le noyau.

Ce framework traite chaque création de socket AF_ALG comme un événement à forte valeur de signal et réduit la surface qui rend ces événements exploitables.

Modèle de menace et correspondance Zero Trust

Structure du dépôt

Composants

1. Observabilité runtime — traceur eBPF

ebpf/af_alg_tracer.py attache un kprobe à security_socket_create. La sonde filtre sur family == 38 au niveau du programme BPF afin que le vérificateur élague les créations de sockets non liées et que la surcharge par événement reste de l'ordre de la nanoseconde. Elle émet un enregistrement JSON par tentative :

Redirigez la sortie standard vers Vector, Fluent Bit ou journald (via systemd-cat). Une liste d'autorisation de noms de commandes (/etc/af-alg-defense/allow.list) supprime les consommateurs connus et légitimes sans perdre la capacité de détecter les écarts.

La cible du kprobe est le hook LSM, donc les événements se déclenchent sur l'intention — même les tentatives qui seraient refusées par seccomp ou RestrictAddressFamilies produisent un enregistrement. C'est exactement ce qu'un SOC souhaite pour l'établissement de références comportementales.

2. Configuration en tant que code — rôle Ansible + drop-in systemd

ansible/roles/af_alg_hardening/ applique deux couches de durcissement :

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

• kernel.unprivileged_userns_clone=0 — supprime le pivot userns utilisé par la plupart des chaînes d'escalade AF_ALG.
• user.max_user_namespaces=0 — défense en profondeur portable entre distributions.

Drop-in systemd (/etc/systemd/system/<unit>.d/50-af-alg-restrict.conf) : Utilise RestrictAddressFamilies comme liste d'autorisation (et non liste de refus). L'unité est autorisée pour AF_UNIX AF_INET AF_INET6 AF_NETLINK ; toute autre famille — AF_ALG inclus — échoue avec EAFNOSUPPORT car systemd l'applique via un BPF attaché au cgroup que l'application ne peut pas désactiver. Le drop-in retire également CAP_SYS_ADMIN et applique ProtectKernel* pour fermer les chemins d'escalade les plus courants.

Application :

Pour les hôtes sans Ansible, placez le fichier autonome directement :

3. Auditeur d'état du noyau

auditor/crypto_auditor.py produit un rapport JSON de posture de sécurité en inspectant :

• /proc/crypto — chaque chiffrement / hachage / aead enregistré, avec les indicateurs FIPS et l'état d'auto-test.
• /sys/module/ — modules chargés dans le sous-arbre crypto, avec indicateurs de taint et instantanés de paramètres.
• /proc/sys/kernel/, /proc/sys/user/ — sysctls qui contrôlent les chemins d'attaque AF_ALG.
• /sys/kernel/security/lockdown — mode de verrouillage du noyau.

Le rapport est indexé par des identifiants de constatation stables (FND-001 à FND-005 actuellement) afin que les règles SIEM puissent supprimer des constatations individuelles sans abandonner l'intégralité du document. La détection de dérive compare la posture à une référence :

Le schéma se trouve dans schemas/audit_report.schema.json (Draft 2020-12) et est validé en CI à chaque push.

4. Intégration continue

.github/workflows/ci.yml exécute quatre tâches à chaque push et PR :

1. ShellCheck — chaque *.sh et script avec shebang.
2. Validation de schéma — vérifie le métaschéma de audit_report.schema.json, puis exécute l'auditeur en direct sur le noyau du runner GH et valide le rapport résultant. Les fixtures dans tests/fixtures/ sont également vérifiées.
3. Lint Python (ruff check .).
4. Lint Ansible sur l'arborescence du rôle.

Un échec de validation de schéma bloque les fusions, ce qui empêche les analyseurs SIEM en aval de se casser sur un champ renommé silencieusement.

Recommandations opérationnelles pour le SOC

Règles de détection à superposer

• Tout événement af_alg_socket_create provenant d'une commande non autorisée — pagez dès la première occurrence, ne regroupez pas.
• Nouvelle entrée dans crypto_modules entre deux exécutions consécutives de l'auditeur sur un hôte où le chargement de modules devrait être figé.
• Tout sysctl avec hardened=false après une exécution du playbook de durcissement — indique une altération manuelle ou une dérive d'un système de configuration parallèle.
• Le champ lockdown qui passe de integrity/confidentiality à none — indicateur fort d'altération de l'état du noyau.

Plan de déploiement (recommandé)

1. Déployez le traceur eBPF en mode surveillance uniquement pendant deux semaines. Utilisez la référence résultante pour remplir allow.list avec les consommateurs connus et légitimes (cryptsetup au démarrage est le cas habituel).
2. Exécutez l'auditeur sur un parc d'hôtes représentatif ; capturez la posture comme baseline.json signé.
3. Appliquez le rôle Ansible à un groupe canari avec af_alg_systemd_services défini sur une unité à faible risque. Surveillez les erreurs EAFNOSUPPORT dans journald.
4. Élargissez la liste de services de manière itérative. systemd-analyze security <unit> doit montrer que la restriction est appliquée.
5. Intégrez l'auditeur dans un cron nocturne avec --fail-on-drift et routez les sorties non nulles vers la file d'astreinte.

Ce que ce framework ne fait pas

• Il ne décharge pas af_alg s'il est déjà utilisé. Le déchargement de modules est hors périmètre car des consommateurs légitimes au démarrage peuvent encore être actifs. Utilisez modprobe.blacklist=af_alg sur la ligne de commande du noyau si vous avez confirmé que rien sur l'hôte n'en a besoin.
• Il ne corrige pas les CVE. Les mises à jour du noyau du fournisseur restent le contrôle principal ; ce framework réduit le coût d'un correctif manqué.
• Il ne protège pas contre root. Un root local peut désactiver n'importe lequel de ces contrôles ; le framework élève la barre jusqu'à root, pas au-delà.

Prérequis

• Linux ≥ 4.18 (pour la cible kprobe security_socket_create).
• BCC ≥ 0.25 ou libbpf ≥ 1.0, plus les en-têtes du noyau correspondant à uname -r.
• Python 3.10+ sur les hôtes gérés.
• Ansible 2.14+ sur le nœud de contrôle.
• CAP_BPF (ou root) pour charger le traceur ; accès en lecture à /proc/crypto pour l'auditeur (aucun privilège requis pour le lire).

Licence

Apache-2.0. Voir LICENSE.