mahdi13830510/CVE-2026-31431-mitigation-suite
GitHub: mahdi13830510/CVE-2026-31431-mitigation-suite
针对 Linux 内核 AF_ALG 子系统的运行时防御框架，通过 eBPF 实时监控、Ansible 自动化加固和内核状态审计，为企业 Linux 环境构建内核侧零信任防护能力。
Stars: 4 | Forks: 0
# AF_ALG 防御框架
[](./.github/workflows/ci.yml)
[](./LICENSE)
一个针对 Linux `AF_ALG`（Address Family Algorithm，协议族 `38`）子系统的内核运行时防御框架。专为运行企业级 Linux 集群的安全运营中心 (SOC) 构建，在这些环境中，零信任必须延伸*至*内核内部，而不是止步于网络边缘。
## 为什么 AF_ALG 对 SOC 至关重要
`AF_ALG` 通过套接字接口 (`socket(AF_ALG, SOCK_SEQPACKET, 0)`) 将内核加密 API 暴露给用户空间。它最初是为没有 `/dev/crypto` 的嵌入式系统添加的，此后却积累了不成比例的大量内核 CVE，因为它将内核态加密代码呈现给了非特权调用者——这是一种典型的攻击面错配。
在典型的企业级构建中：
- **几乎没有用户空间程序需要它。** OpenSSL、GnuTLS、libsodium 和 systemd-cryptsetup 默认都使用其他路径。
- **攻击者对其非常感兴趣。** 它是提权链中反复出现的跳板（CVE-2019-8912、CVE-2017-13215 等），这恰恰是因为当用户命名空间可用时，从非特权容器即可触达它。
- **它对大多数 EDR 是不可见的。** 挂钩 `connect()`、`bind()` 或 DNS 的端点工具什么也看不到——`AF_ALG` 流量永远不会离开内核。
该框架将每一次 `AF_ALG` 套接字创建都视为高信号事件，并缩小了使这些事件可被利用的攻击面。
## 威胁模型与零信任映射
| 零信任原则 | 本框架中的控制措施 |
|--------------------------------|----------------------------------------------------------------------------|
| 永不信任，始终验证 | eBPF 跟踪器记录每一次 `AF_ALG` 套接字创建尝试，包含 `pid/uid/comm` |
| 假设已被入侵 | 加密审计器将内核安全态势与已签名的基线进行比对 |
| 最小权限 | 在受管单元上应用 systemd `RestrictAddressFamilies` + capability bounding |
| 微隔离 (内核侧)| `unprivileged_userns_clone=0` 移除了漏洞利用所使用的 userns 跳板 |
| 持续验证 | CI 在每次变更时，根据版本化 schema 验证审计报告 |
## 仓库布局
```
.
├── ebpf/ Runtime observability (BCC tracer + allowlist)
├── ansible/ Configuration-as-Code (sysctl + systemd drop-ins)
├── systemd/ Standalone systemd drop-in for non-Ansible hosts
├── auditor/ Kernel state auditor (Python)
├── schemas/ JSON Schema for audit-report ingestion
├── scripts/ Helper shell scripts (linted by CI)
├── tests/ Unit tests + report fixtures
└── .github/workflows/ CI: shellcheck + JSON schema validation + lint
```
## 组件
### 1. 运行时可观测性 — eBPF 跟踪器
`ebpf/af_alg_tracer.py` 将一个 `kprobe` 附加到 `security_socket_create` 上。
探针在 BPF 程序层面对 `family == 38` 进行过滤，因此验证器会修剪掉不相关的套接字创建操作，且每次事件的系统开销保持在纳秒级别。它为每次尝试生成一条 JSON 记录：
```
{
"@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"}
}
```
通过管道将 stdout 输出至 Vector、Fluent Bit 或 `journald`（通过 `systemd-cat`）。
一个进程名白名单 (`/etc/af-alg-defense/allow.list`) 会抑制已知合法的消费者，同时不丧失检测异常偏差的能力。
kprobe 的目标是 LSM 钩子，因此事件是基于**意图**触发的——
即使是被 seccomp 或 `RestrictAddressFamilies` 拒绝的尝试
也会生成一条记录。这正是 SOC 进行行为基线化所期望的。
### 2. 配置即代码 — Ansible role + systemd drop-in
`ansible/roles/af_alg_hardening/` 应用两层加固：
**Sysctl drop-in** (`/etc/sysctl.d/90-af-alg-defense.conf`)：
- `kernel.unprivileged_userns_clone=0` — 移除大多数 `AF_ALG` 提权链使用的 userns 跳板。
- `user.max_user_namespaces=0` — 跨发行版的纵深防御。
**Systemd drop-in** (`/etc/systemd/system/.d/50-af-alg-restrict.conf`)：
将 `RestrictAddressFamilies` 用作**白名单**（而非黑名单）。该
单元仅被允许使用 `AF_UNIX AF_INET AF_INET6 AF_NETLINK`；任何其他
协议族——包括 `AF_ALG`——都会因 `EAFNOSUPPORT` 而失败，因为 systemd
通过应用程序无法禁用的、附加到 cgroup 的 BPF 来强制执行此限制。该 drop-in 还会剥离 `CAP_SYS_ADMIN` 并应用
`ProtectKernel*`，以封堵最常见的提权路径。
应用方式：
```
ansible-playbook -i inventory ansible/site.yml --check --diff # preview
ansible-playbook -i inventory ansible/site.yml # enforce
```
对于没有 Ansible 的主机，可直接将独立文件放置到位：
```
sudo ./scripts/deploy_dropin.sh nginx.service
```
### 3. 内核状态审计器
`auditor/crypto_auditor.py` 通过检查以下内容来生成 JSON 安全态势报告：
- `/proc/crypto` — 每个已注册的 cipher / hash / aead，包括
FIPS 标志和自检状态。
- `/sys/module/` — 加密子树中已加载的模块，包括污染标志
和参数快照。
- `/proc/sys/kernel/`、`/proc/sys/user/` — 阻断 AF_ALG
攻击路径的 sysctl。
- `/sys/kernel/security/lockdown` — 内核锁定模式。
该报告通过稳定的发现 ID（当前为 `FND-001` 至 `FND-005`）进行索引，
因此 SIEM 规则可以抑制个别发现而不会丢弃整个文档。偏移检测会将安全态势与基线进行对比：
```
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
```
schema 存在于 `schemas/audit_report.schema.json`（Draft 2020-12）中，
并在每次推送时在 CI 中进行验证。
### 4. 持续集成
`.github/workflows/ci.yml` 在每次推送和 PR 时运行四个作业：
1. **ShellCheck** — 检查每一个 `*.sh` 和包含 shebang 的脚本。
2. **Schema 验证** — 对 `audit_report.schema.json` 进行元模式检查，
然后在 GH runner 内核上实时运行审计器并验证生成的报告。`tests/fixtures/` 中的固件也会被检查。
3. **Python lint** (`ruff check .`)。
4. 对 role 树进行 **Ansible lint**。
失败的 schema 检查会阻止合并，这可以防止下游 SIEM
解析器因字段被静默重命名而中断。
## SOC 运营指南
### 需叠加的检测规则
- 来自非白名单进程的**任何** `af_alg_socket_create` 事件 — 在首次出现时立即告警，不聚合。
- 在应冻结模块加载的主机上，连续两次审计器运行之间出现 `crypto_modules` 的新条目。
- 运行加固 playbook 后，任何 `hardened=false` 的 sysctl —
表明发生了手动篡改或来自并行配置系统的偏移。
- `lockdown` 字段从 `integrity`/`confidentiality` 转换为 `none` — 内核状态被篡改的强烈指标。
### 推出计划 (推荐)
1. 以**仅监控**模式部署 eBPF 跟踪器两周。使用生成的基线为已知合法的消费者（通常是启动时的 cryptsetup）填充 `allow.list`。
2. 在具有代表性的主机集群上运行审计器；将该安全态势捕获为已签名的 `baseline.json`。
3. 将 Ansible role 应用到一个金丝雀组，并将 `af_alg_systemd_services` 设置为一个低风险单元。观察 journald 中是否出现 `EAFNOSUPPORT` 错误。
4. 迭代扩展服务列表。`systemd-analyze security ` 应显示该限制已被强制执行。
5. 将审计器通过 `--fail-on-drift` 接入夜间 cron 任务，并将非零退出码路由至待命队列。
## 本框架*不*做什么
- 它不会卸载正在使用的 `af_alg`。模块卸载超出了范围，因为合法的启动时消费者可能仍在运行。如果您已确认主机上没有任何程序需要它，请在内核命令行上使用 `modprobe.blacklist=af_alg`。
- 它不修补 CVE。供应商内核更新仍然是主要的控制手段；本框架降低了遗漏补丁带来的风险。
- 它不能防御 root。本地 root 可以禁用所有这些控制措施；本框架提高了获取 root 的门槛，但并不能超越 root 权限。
## 系统要求
- Linux ≥ 4.18（用于 `security_socket_create` kprobe 目标）。
- BCC ≥ 0.25 或 libbpf ≥ 1.0，以及与 `uname -r` 匹配的内核头文件。
- 受管主机上安装 Python 3.10+。
- 控制节点上安装 Ansible 2.14+。
- 加载跟踪器需要 `CAP_BPF`（或 root）；审计器需要 `/proc/crypto` 的读取权限（读取它不需要任何特权）。
## 许可证
Apache-2.0。详见 [LICENSE](./LICENSE)。
标签：AF_ALG, AMSI绕过, API接口, Auditd, CISA项目, Cutter, CVE-2026-31431, Docker镜像, EDR, JSONLines, Linux内核安全, nftables, TLS, Web截图, Web报告查看器, 内核漏洞, 威胁检测, 安全运营中心, 容器安全, 模块黑名单, 漏洞缓解, 特权提升, 用户命名空间, 端点检测与响应, 系统提示词, 网络安全, 网络映射, 脆弱性评估, 脱壳工具, 自动化部署, 行为探测, 逆向工具, 防御工具, 隐私保护, 零信任