mahdi13830510/cve-2026-31431-mitigation-suiteKernel-Runtime-Verteidigungsframework für AF_ALG-Schwachstellen, mit eBPF-Socket-Tracing, Ansible-Härtung und einem Krypto-Auditor zur Drift-Erkennung.
Ein Kernel-Runtime-Verteidigungsframework für das Linux-AF_ALG-Subsystem (Address Family Algorithm, Familie 38). Entwickelt für Security Operations Centers, die Enterprise-Linux-Flotten betreiben, in denen Zero Trust in den Kernel hineinreichen muss und nicht an der Netzwerkgrenze endet.
AF_ALG stellt die Kernel-Krypto-API über eine Socket-Schnittstelle (socket(AF_ALG, SOCK_SEQPACKET, 0)) für den Userspace bereit. Ursprünglich wurde es für eingebettete Systeme ohne /dev/crypto hinzugefügt und hat seitdem einen unverhältnismäßigen Anteil an Kernel-CVEs angehäuft, weil es Kernel-Mode-Krypto-Code für unprivilegierte Aufrufer bereitstellt – eine klassische Fehlanpassung der Angriffsfläche.
In einem typischen Enterprise-Build:
connect(), bind() oder DNS hooken, sehen nichts – AF_ALG-Verkehr verlässt den Kernel nie.Dieses Framework behandelt jede AF_ALG-Socket-Erstellung als Ereignis mit hoher Signalstärke und reduziert die Angriffsfläche, die solche Ereignisse ausnutzbar macht.
| Zero-Trust-Prinzip | Kontrolle in diesem Framework |
|---|---|
| Niemals vertrauen, immer verifizieren | eBPF-Tracer protokolliert jeden AF_ALG-Socket-Erstellungsversuch mit pid/uid/comm |
| Angriff annehmen | Krypto-Auditor vergleicht den Kernel-Zustand mit einer signierten Baseline |
| Minimale Rechte | systemd RestrictAddressFamilies + Capability-Bounding auf verwalteten Units |
| Mikrosegmentierung (Kernel-Seite) | unprivileged_userns_clone=0 entfernt den userns-Pivot, den Exploits nutzen |
| Kontinuierliche Validierung | CI validiert Audit-Berichte bei jeder Änderung gegen ein versioniertes Schema |
.
├── ebpf/ Laufzeit-Beobachtbarkeit (BCC-Tracer + Allowlist)
├── ansible/ Configuration-as-Code (sysctl + systemd-Drop-ins)
├── systemd/ Eigenständiges systemd-Drop-in für Nicht-Ansible-Hosts
├── auditor/ Kernel-Zustands-Auditor (Python)
├── schemas/ JSON-Schema für die Audit-Berichts-Erfassung
├── scripts/ Hilfsshell-Skripte (von CI gelintet)
├── tests/ Unit-Tests + Berichts-Fixtures
└── .github/workflows/ CI: shellcheck + JSON-Schema-Validierung + Lint
ebpf/af_alg_tracer.py hängt einen kprobe an security_socket_create. Der Probe filtert auf family == 38 auf BPF-Programmebene, sodass der Verifier nicht zusammenhängende Socket-Erstellungen entfernt und der Overhead pro Ereignis im Nanosekundenbereich bleibt. Er gibt einen JSON-Datensatz pro Versuch aus:
{
"@timestamp": "2026-05-02T09:14:11.412041+00:00",
"event": {"category": "kernel", "action": "af_alg_socket_create", "severity": "high"},
"process": {"pid": 1394, "tgid": 1394, "comm": "suspicious_bin"},
"user": {"uid": 1000, "gid": 1000},
"socket": {"family": 38, "family_name": "AF_ALG", "type": 5, "protocol": 0},
"host": {"name": "web-prod-04"}
}
Leiten Sie stdout an Vector, Fluent Bit oder journald (über systemd-cat) weiter. Eine Comm-Namen-Allowlist (/etc/af-alg-defense/allow.list) unterdrückt bekannte, legitime Konsumenten, ohne die Fähigkeit zu verlieren, Abweichungen zu erkennen.
Das kprobe-Ziel ist der LSM-Hook, sodass Ereignisse auf Absicht ausgelöst werden – selbst Versuche, die von seccomp oder RestrictAddressFamilies abgelehnt würden, erzeugen weiterhin einen Datensatz. Genau das möchte ein SOC für die Verhaltens-Baseline.
ansible/roles/af_alg_hardening/ wendet zwei Härtungsebenen an:
Sysctl-Drop-in (/etc/sysctl.d/90-af-alg-defense.conf):
kernel.unprivileged_userns_clone=0 – entfernt den userns-Pivot, den die meisten AF_ALG-Escalation-Ketten nutzen.user.max_user_namespaces=0 – distro-portable Defence-in-Depth.Systemd-Drop-in (/etc/systemd/system/<unit>.d/50-af-alg-restrict.conf):
Verwendet RestrictAddressFamilies als Allowlist (nicht Denylist). Der Unit sind AF_UNIX AF_INET AF_INET6 AF_NETLINK erlaubt; jede andere Familie – einschließlich AF_ALG – schlägt mit EAFNOSUPPORT fehl, da systemd dies über cgroup-gebundenes BPF durchsetzt, das die Anwendung nicht deaktivieren kann. Das Drop-in entfernt außerdem CAP_SYS_ADMIN und wendet ProtectKernel* an, um die häufigsten Escalation-Pfade zu schließen.
Anwenden mit:
ansible-playbook -i inventory ansible/site.yml --check --diff # Vorschau
ansible-playbook -i inventory ansible/site.yml # durchsetzen
Für Hosts ohne Ansible die eigenständige Datei an Ort und Stelle ablegen:
sudo ./scripts/deploy_dropin.sh nginx.service
auditor/crypto_auditor.py erzeugt einen JSON-Sicherheitszustandsbericht durch Prüfung von:
/proc/crypto – jede registrierte Chiffre / Hash / aead, mit FIPS-Flags und Selbsttest-Status./sys/module/ – geladene Module im Krypto-Unterbaum, mit Taint-Flags und Parameter-Snapshots./proc/sys/kernel/, /proc/sys/user/ – Sysctls, die AF_ALG-Angriffspfade steuern./sys/kernel/security/lockdown – Kernel-Lockdown-Modus.Der Bericht ist nach stabilen Finding-IDs (FND-001 bis FND-005 derzeit) schlüsselt, sodass SIEM-Regeln einzelne Findings unterdrücken können, ohne das gesamte Dokument zu verwerfen. Die Drift-Erkennung vergleicht den Zustand mit einer Baseline:
sudo ./auditor/crypto_auditor.py --output /var/log/af-alg-defense/today.json
sudo ./auditor/crypto_auditor.py \
--baseline /var/log/af-alg-defense/baseline.json \
--fail-on-drift
Das Schema liegt in schemas/audit_report.schema.json (Draft 2020-12) und wird bei jedem Push in der CI validiert.
.github/workflows/ci.yml führt bei jedem Push und PR vier Jobs aus:
*.sh- und Shebang-tragende Skript.audit_report.schema.json, dann Live-Ausführung des Auditors auf dem GH-Runner-Kernel und Validierung des resultierenden Berichts. Fixtures in tests/fixtures/ werden ebenfalls geprüft.ruff check .).Ein fehlgeschlagener Schema-Check blockiert Merges, was verhindert, dass nachgelagerte SIEM-Parser durch ein stillschweigend umbenanntes Feld brechen.
af_alg_socket_create-Ereignis von einem nicht-allowlisteten Comm – beim ersten Auftreten alarmieren, nicht aggregieren.crypto_modules zwischen aufeinanderfolgenden Auditor-Läufen auf einem Host, auf dem das Laden von Modulen eingefroren sein sollte.hardened=false nach einem Härtungs-Playbook-Lauf – deutet auf manuelle Manipulation oder Drift von einem parallelen Konfigurationssystem hin.lockdown-Feld wechselt von integrity/confidentiality zu none – starkes Indiz für Kernel-Zustands-Manipulation.allow.list für bekannte, legitime Konsumenten zu befüllen (cryptsetup beim Boot ist der übliche).baseline.json erfassen.af_alg_systemd_services auf eine Unit mit geringem Risiko gesetzt ist. Auf EAFNOSUPPORT-Fehler in journald achten.systemd-analyze security <unit> sollte zeigen, dass die Einschränkung durchgesetzt wird.--fail-on-drift einbinden und Nicht-Null-Exit-Codes in die Bereitschafts-Warteschlange leiten.af_alg nicht, wenn es bereits in Verwendung ist. Das Entladen von Modulen ist außerhalb des Rahmens, da legitime Boot-Zeit-Konsumenten möglicherweise noch laufen. Verwenden Sie modprobe.blacklist=af_alg auf der Kernel-Befehlszeile, wenn Sie bestätigt haben, dass nichts auf dem Host es benötigt.security_socket_create-kprobe-Ziel).uname -r.CAP_BPF (oder Root) zum Laden des Tracers; Lesezugriff auf /proc/crypto für den Auditor (keine Berechtigungen zum Lesen erforderlich).Apache-2.0. Siehe LICENSE.