AF_ALG 防御フレームワーク

Linux AF_ALG（アドレスファミリ・アルゴリズム、ファミリ 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/                 ランタイム可観測性（BCCトレーサー + 許可リスト）
├── ansible/              コードとしての設定（sysctl + systemdドロップイン）
├── systemd/              Ansibleを使用しないホスト向けのスタンドアロンsystemdドロップイン
├── auditor/              カーネル状態監査ツール（Python）
├── schemas/              監査レポート取り込み用JSONスキーマ
├── scripts/              ヘルパーシェルスクリプト（CIでlint実行）
├── tests/                ユニットテスト + レポートフィクスチャ
└── .github/workflows/     CI: shellcheck + JSONスキーマ検証 + lint

コンポーネント

1. ランタイム可観測性 — eBPFトレーサー

ebpf/af_alg_tracer.py は security_socket_create に kprobe をアタッチします。プローブはBPFプログラムレベルで family == 38 をフィルタリングするため、検証器が無関係なソケット作成を刈り込み、イベントあたりのオーバーヘッドはナノ秒単位に保たれます。試行ごとに1つの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 経由）にパイプします。comm名の許可リスト（/etc/af-alg-defense/allow.list）は、既知の正常なコンシューマーを抑制しつつ、逸脱の検出能力を失いません。

kprobeターゲットはLSMフックであるため、イベントは意図に基づいて発生します — seccompや RestrictAddressFamilies によって拒否される試行でもレコードが生成されます。これはまさにSOCが行動ベースライン作成のために求めるものです。

2. コードとしての設定 — Ansibleロール + systemdドロップイン

ansible/roles/af_alg_hardening/ は2つのハードニング層を適用します：

Sysctlドロップイン（/etc/sysctl.d/90-af-alg-defense.conf）：

• kernel.unprivileged_userns_clone=0 — ほとんどの AF_ALG 権限昇格チェーンで使用されるusernsピボットを除去します。
• user.max_user_namespaces=0 — ディストリビューション間で移植可能な多層防御。

Systemdドロップイン（/etc/systemd/system/<unit>.d/50-af-alg-restrict.conf）： RestrictAddressFamilies を許可リスト（拒否リストではなく）として使用します。ユニットには AF_UNIX AF_INET AF_INET6 AF_NETLINK が許可され、AF_ALG を含む他のファミリは、systemdがcgroupにアタッチされたBPFを通じて強制するため、アプリケーションが無効化できない EAFNOSUPPORT で失敗します。ドロップインはまた CAP_SYS_ADMIN を剥奪し、ProtectKernel* を適用して最も一般的な権限昇格パスを閉じます。

適用方法：

ansible-playbook -i inventory ansible/site.yml --check --diff   # プレビュー
ansible-playbook -i inventory ansible/site.yml                  # 適用

Ansibleを使用しないホストの場合は、スタンドアロンファイルを配置します：

sudo ./scripts/deploy_dropin.sh nginx.service

3. カーネル状態監査ツール

auditor/crypto_auditor.py は以下を検査してJSONセキュリティ状態レポートを生成します：

• /proc/crypto — FIPSフラグとセルフテストステータスを含む、登録済みのすべての暗号 / ハッシュ / aead。
• /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

スキーマは schemas/audit_report.schema.json（Draft 2020-12）にあり、プッシュのたびにCIで検証されます。

4. 継続的インテグレーション

.github/workflows/ci.yml はプッシュとPRのたびに4つのジョブを実行します：

1. ShellCheck — すべての *.sh およびシバン付きスクリプト。
2. スキーマ検証 — audit_report.schema.json をメタスキーマチェックし、GHランナーカーネル上で監査ツールをライブ実行して結果のレポートを検証します。tests/fixtures/ 内のフィクスチャもチェックされます。
3. Python lint（ruff check .）。
4. Ansible lint — ロールツリーに対して実行。

スキーマチェックの失敗はマージをブロックし、サイレントに名前変更されたフィールドによってダウンストリームのSIEMパーサーが壊れるのを防ぎます。

SOC向け運用ガイダンス

上に重ねる検出ルール

• 許可リストにないcommからの任意の af_alg_socket_create イベント — 初回発生時にページングし、集約しない。
• モジュールロードが凍結されるべきホストで、連続する監査実行間の crypto_modules の新しいエントリ。
• ハードニングプレイブック実行後の hardened=false のsysctl — 手動改ざんまたは並行設定システムからのドリフトを示します。
• lockdown フィールドが integrity/confidentiality から none に遷移 — カーネル状態改ざんの強い指標。

ロールアウト計画（推奨）

1. eBPFトレーサーをモニター専用モードで2週間デプロイします。結果のベースラインを使用して、既知の正常なコンシューマー（通常は起動時のcryptsetup）の allow.list を設定します。
2. 代表的なホストフリートに対して監査ツールを実行し、状態を署名付き baseline.json として取得します。
3. af_alg_systemd_services を1つの低リスクユニットに設定して、カナリアグループにAnsibleロールを適用します。journaldで EAFNOSUPPORT エラーを監視します。
4. サービスリストを反復的に拡張します。systemd-analyze security <unit> で制限が適用されていることを確認します。
5. 監査ツールを --fail-on-drift 付きの夜間cronに組み込み、非ゼロ終了をオンコールキューにルーティングします。

このフレームワークが行わないこと

• すでに使用中の af_alg をアンロードしません。正当な起動時コンシューマーがまだ実行中である可能性があるため、モジュールアンロードは対象外です。ホスト上で何も必要としないことを確認した場合は、カーネルコマンドラインで modprobe.blacklist=af_alg を使用してください。
• CVEにパッチを適用しません。ベンダーカーネルアップデートが引き続き主要な制御手段です。このフレームワークはパッチ漏れのコストを削減します。
• 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 を参照してください。