CVE-2026-31431-mitigation-suite

Marco de defensa en tiempo de ejecución del kernel para vulnerabilidades AF_ALG, con rastreo de sockets eBPF, endurecimiento Ansible y un auditor criptográfico para la detección de desviaciones.

En una implementación empresarial típica:

• Casi ningún espacio de usuario lo requiere. OpenSSL, GnuTLS, libsodium y systemd-cryptsetup usan otras rutas por defecto.
• Los adversarios están interesados en él. Es un pivote recurrente en cadenas de escalada de privilegios (CVE-2019-8912, CVE-2017-13215 y otros) precisamente porque es alcanzable desde contenedores sin privilegios cuando los espacios de nombres de usuario están disponibles.
• Es invisible para la mayoría de los EDR. Las herramientas de endpoint que enganchan connect(), bind() o DNS no ven nada — el tráfico AF_ALG nunca sale del kernel.

Este marco trata cada creación de socket AF_ALG como un evento de alta señal y reduce la superficie que hace explotables esos eventos.

Modelo de amenazas y mapeo Zero Trust

Estructura del repositorio

Componentes

1. Observabilidad en tiempo de ejecución — rastreador eBPF

ebpf/af_alg_tracer.py adjunta un kprobe a security_socket_create. La sonda filtra en family == 38 a nivel del programa BPF para que el verificador elimine creaciones de sockets no relacionadas y la sobrecarga por evento se mantenga en nanosegundos. Emite un registro JSON por intento:

Dirija la salida estándar a Vector, Fluent Bit o journald (vía systemd-cat). Una lista de permitidos por nombre de comm (/etc/af-alg-defense/allow.list) suprime consumidores conocidos y legítimos sin perder la capacidad de detectar desviaciones.

El objetivo del kprobe es el hook LSM, por lo que los eventos se disparan por intención — incluso los intentos que serían denegados por seccomp o RestrictAddressFamilies aún producen un registro. Eso es exactamente lo que un SOC quiere para la línea base de comportamiento.

2. Configuración como Código — rol Ansible + drop-in de systemd

ansible/roles/af_alg_hardening/ aplica dos capas de endurecimiento:

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

• kernel.unprivileged_userns_clone=0 — elimina el pivote userns usado por la mayoría de las cadenas de escalada AF_ALG.
• user.max_user_namespaces=0 — defensa en profundidad portable entre distribuciones.

Drop-in de systemd (/etc/systemd/system/<unit>.d/50-af-alg-restrict.conf): Usa RestrictAddressFamilies como lista de permitidos (no lista de denegados). A la unidad se le permiten AF_UNIX AF_INET AF_INET6 AF_NETLINK; cualquier otra familia — AF_ALG incluida — falla con EAFNOSUPPORT porque systemd lo aplica mediante BPF adjunto a cgroups que la aplicación no puede desactivar. El drop-in también elimina CAP_SYS_ADMIN y aplica ProtectKernel* para cerrar las rutas de escalada más comunes.

Aplicar con:

Para hosts sin Ansible, coloque el archivo independiente en su lugar:

3. Auditor de estado del kernel

auditor/crypto_auditor.py produce un informe JSON de postura de seguridad inspeccionando:

• /proc/crypto — cada cipher / hash / aead registrado, con banderas FIPS y estado de autoprueba.
• /sys/module/ — módulos cargados en el subárbol criptográfico, con banderas de taint y capturas de parámetros.
• /proc/sys/kernel/, /proc/sys/user/ — sysctls que controlan las rutas de ataque AF_ALG.
• /sys/kernel/security/lockdown — modo de bloqueo del kernel.

El informe está indexado por IDs de hallazgos estables (FND-001 a FND-005 actualmente) para que las reglas SIEM puedan suprimir hallazgos individuales sin descartar todo el documento. La detección de deriva compara la postura contra una línea base:

El esquema vive en schemas/audit_report.schema.json (Draft 2020-12) y se valida en CI en cada push.

4. Integración continua

.github/workflows/ci.yml ejecuta cuatro trabajos en cada push y PR:

1. ShellCheck — cada *.sh y script con shebang.
2. Validación de esquema — verifica metaschema de audit_report.schema.json, luego ejecuta el auditor en vivo en el kernel del runner de GH y valida el informe resultante. Los fixtures en tests/fixtures/ también se verifican.
3. Lint de Python (ruff check .).
4. Lint de Ansible en el árbol del rol.

Una verificación de esquema fallida bloquea las fusiones, lo que evita que los analizadores SIEM posteriores se rompan por un campo renombrado silenciosamente.

Guía operativa para SOC

Reglas de detección para superponer

• Cualquier evento af_alg_socket_create de un comm no incluido en la lista de permitidos — paginar en la primera ocurrencia, no agregar.
• Nueva entrada en crypto_modules entre ejecuciones consecutivas del auditor en un host donde la carga de módulos debería estar congelada.
• Cualquier sysctl con hardened=false después de una ejecución del playbook de endurecimiento — indica manipulación manual o deriva de un sistema de configuración paralelo.
• El campo lockdown transiciona de integrity/confidentiality a none — fuerte indicador de manipulación del estado del kernel.

Plan de despliegue (recomendado)

1. Desplegar el rastreador eBPF en modo solo monitoreo durante dos semanas. Usar la línea base resultante para poblar allow.list para consumidores conocidos y legítimos (cryptsetup en el arranque es el habitual).
2. Ejecutar el auditor contra una flota de hosts representativa; capturar la postura como baseline.json firmado.
3. Aplicar el rol Ansible a un grupo canario con af_alg_systemd_services configurado a una unidad de bajo riesgo. Vigilar errores EAFNOSUPPORT en journald.
4. Expandir la lista de servicios iterativamente. systemd-analyze security <unit> debería mostrar que la restricción está aplicada.
5. Conectar el auditor a un cron nocturno con --fail-on-drift y enrutar las salidas no cero a la cola de guardia.

Lo que este marco no hace

• No descarga af_alg si ya está en uso. La descarga de módulos está fuera de alcance porque los consumidores legítimos en el arranque pueden seguir ejecutándose. Use modprobe.blacklist=af_alg en la línea de comandos del kernel si ha confirmado que nada en el host lo necesita.
• No parchea CVEs. Las actualizaciones del kernel del proveedor siguen siendo el control principal; este marco reduce el costo de un parche omitido.
• No protege contra root. Un root local puede desactivar cualquiera de estos controles; el marco eleva el listón hasta root, no más allá.

Requisitos

• Linux ≥ 4.18 (para el objetivo kprobe security_socket_create).
• BCC ≥ 0.25 o libbpf ≥ 1.0, más encabezados del kernel que coincidan con uname -r.
• Python 3.10+ en hosts gestionados.
• Ansible 2.14+ en el nodo de control.
• CAP_BPF (o root) para cargar el rastreador; acceso de lectura a /proc/crypto para el auditor (no se requieren privilegios para leerlo).

Licencia

Apache-2.0. Ver LICENSE.