hidemi-k/maf-ebpf-sase

# 基于 eBPF 与多 Agent 的自主 AI-SASE 框架 所有 AI 编排均统一在 **Microsoft Agent Framework (MAF)** 之上。 ## 📺 演示 ### ZTNA — 自主威胁阻断（60 秒） https://github.com/user-attachments/assets/9774ace3-6f57-48ba-8968-17508a5c07c0 ### IPS — 人工介入执法（53 秒） https://github.com/user-attachments/assets/7928db18-4297-4fdc-bc64-0882d5dfc21b ## 🏗 架构 ``` [ Threats / Traffic ] │ ┌──────▼──────────────────────────────────────────────────────────┐ │ Data Plane: Rust + eBPF/XDP │ │ Tetragon (kernel syscall monitor) │ └──────┬────────────────────────────────────┬─────────────────────┘ │ stats / XDP maps │ security events ┌──────▼──────────────┐ ┌───────────────▼────────────────────────┐ │ Control Plane (Go) │◄────│ MAF Orchestration │ │ REST API │ │ ┌──────────────┐ ┌────────────────┐ │ │ X-API-Key auth │ │ │ Admin agent │ │ SASE agent │ │ └─────────────────────┘ │ ├──────────────┤ ├────────────────┤ │ │ │ Tetragon mon │ │ Ticket/Policy │ │ ┌─────────────────────┐ │ │ Rate monitor │ │ management │ │ │ Infra: Containerlab│ │ └──────────────┘ └────────────────┘ │ │ VPP + Juniper cRPD │ │ │ GPT-OSS-120B via Groq API │ └─────────────────────┘ └─────────┴──────────────────────────────┘ │ ┌──────────▼──────────────────────────────┐ │ A2A Protocol (next phase) │ │ a2a-ceos-core: Arista │ └─────────────────────────────────────────┘ ``` ## 🧠 为什么选择 Microsoft Agent Framework (MAF)？ 所有 AI 编排均统一在 **MAF** (`agent_framework`) 之下： - **原生工具调度**：MAF 会根据函数签名和 docstring 自动调用工具。 - **会话与历史记录管理**：对话历史记录和 token 限制均委托给 MAF 会话层处理。 - **统一的 LLM 接口**：通过兼容 OpenAI 的 API 与 Groq 托管的模型无缝协作。 - **一致的错误处理**：速率限制、错误请求和重试均由 MAF 层处理。 所有模块（从底层的 XDP 安全执行到高层的网络配置管理）均采用了相同的基于 MAF 的 Agent 模式。 ## 🛠 技术栈 | 层级 | 技术 | |---|---| | **AI 编排** | Microsoft Agent Framework (MAF) | | **LLM 后端** | openai/gpt-oss-120b（通过 Groq API，兼容 OpenAI） | | **数据平面** | Rust + eBPF/XDP — 线速数据包过滤 | | **控制平面** | Go — XDP map 管理与策略 REST API | | **内核监控** | Tetragon（基于 eBPF 的 syscall 追踪） | | **基础设施** | Containerlab + VPP + Juniper cRPD/vevo | | **多供应商（下一步）** | A2A Protocol — Arista cEOS / Cisco / Junos | ## 📁 目录结构 ``` my-sase-project/ ├── config.ini.example # API key template (copy to config.ini) ├── infra/ │ └── containerlab/ │ └── vpp.clab.yml # Containerlab topology definition ├── ips-maf/ # IPS module — human-in-the-loop enforcement (MAF) │ ├── go-control-plane/ │ │ ├── go.mod │ │ └── main.go │ ├── python-agents/ │ │ ├── api_spec.py │ │ └── sase_agent.py │ └── xdp-ebpf/ │ ├── Cargo.toml │ └── main.rs ├── netmiko-maf/ # Network fault diagnosis via Netmiko + MAF (Jupyter) │ └── network_diagnostic_agent.ipynb # 5-agent diagnostic pipeline (L2/L3/Self-Correction) ├── LICENSE ├── README.md └── ztna-tetragon-maf/ # ZTNA module — autonomous blocking (MAF) ├── go-control-plane/ │ ├── go.mod │ └── main.go # REST API + XDP map management ├── python-agents/ │ ├── admin_agent_maf.py # Security admin agent (MAF) │ ├── api_spec.py │ └── sase_agent_maf.py # User-facing SASE agent (MAF) ├── tetragon/ │ └── block-shadow-access.template.yaml # Tetragon policy: blocks shadow /etc/passwd access └── xdp-ebpf/ ├── Cargo.toml └── main.rs # Rust/XDP line-rate packet filter ``` ### Tetragon 策略 `ztna-tetragon-maf/tetragon/block-shadow-access.template.yaml` 是一个 [Tetragon](https://tetragon.io/) `TracingPolicy`，它通过 eBPF 在内核级别检测并阻断对 `/etc/shadow` 和 `/etc/passwd` 的未授权访问。 当 Tetragon 触发 `KPROBE_ACTION_SIGKILL` 事件时，**admin agent (MAF)** 会捕获该事件，将其流式传输到 **Elasticsearch** 以进行证据留存，对威胁进行推理，并指示 Go 控制平面撤销 ZTNA 会话并将攻击者列入黑名单 —— 无需人工干预。 ## 🔬 编排：多层诊断 ### [`netmiko-maf/`](./netmiko-maf/) — 跨供应商的多层故障诊断 | Agent | 角色 | |---|---| | 命令选择器 | 根据症状描述选择正确的命令集 | | L2 分析师 | 检测接口和 MAC 级别的异常 | | L3 分析师 | 识别路由和 ARP 问题 | | 一致性检查器 | 交叉验证 L2/L3 状态，应用 Self-Correction | | 报告生成器 | 生成带有证据引用的结构化调查结果 | - **天然支持多供应商**：`VENDOR_KEY` 将 SSH 驱动程序与命令字典解耦 —— 添加新设备类型仅需一个 YAML 条目。 - **Mock 模式**：所有 Agent 均可针对 mock 数据运行，无需物理设备，从而实现利于 CI/CD 的测试。 ## 🔗 A2A 迁移（下一阶段） NETCONF RAG notebook 已被弃用。替代方案是在 [`a2a-ceos-core`](https://github.com/hidemi-k/a2a-ceos-core) 中实现的基于 **A2A (Agent-to-Agent) protocol** 的架构： ## 🏁 入门指南 ### 前置条件 | 工具 | 版本 | 链接 | |---|---|---| | Microsoft Agent Framework | 最新版 | `pip install agent-framework` | | Groq API Key | — | [console.groq.com](https://console.groq.com) | | Go | 1.21+ | [go.dev](https://go.dev/dl/) | | Rust + cargo | stable | [rustup.rs](https://rustup.rs) | | Containerlab | 最新版 | [containerlab.dev](https://containerlab.dev) | ### 设置 1. **部署拓扑**： sudo containerlab deploy -t infra/containerlab/vpp.clab.yml 2. **设置 API 密钥**： cp config.ini.example config.ini # 编辑 config.ini 并设置 GROQ_API_KEY 可选 — 启用写入 API 身份验证： export AGENT_API_KEY=$(openssl rand -hex 32) 3. **构建并启动 Go 控制平面**： cd ztna-tetragon-maf/xdp-ebpf cargo build --release cp target/bpfel-unknown-none/release/xdp-ebpf ../go-control-plane/main.o cd ../go-control-plane sudo nsenter -t $PID -n ./sase-agent -iface eth3 -xdp-mode generic 4. **运行 MAF Agents**： python3 ztna-tetragon-maf/python-agents/admin_agent_maf.py python3 ztna-tetragon-maf/python-agents/sase_agent_maf.py python3 ips-maf/python-agents/sase_agent.py 5. **探索 Notebooks**： - [`netmiko-maf/`](./netmiko-maf/) — 由 MAF agents 驱动的网络诊断 ## ⚠️ 已知局限性 ### MAF：同步线程中的 asyncio ContextVar 当通过 `asyncio.run()` 从同步线程调用 `Agent.run()` 时，MAF 可能会抛出： ``` ContextVar was created in a different Context ``` 本项目通过将非交互式 LLM 调用（`AdminNarrator`、`FWAnalyst`）中的 `asyncio.run(Agent.run())` 替换为直接的 `requests.post()` 到 Groq API 来绕过此问题。交互式聊天（`sase_agent_maf.py`）使用 `asyncio.run(chat_loop())` → `await agent.run()`，因此不受影响。 ### MAF 原生 HITL：开放模型的工具调用不稳定性 IPS 模块使用自定义的 `[EXEC:]` 标签解析方法来实现人工介入 (HITL)，而不是 MAF 原生的 `approval_mode="always_require"` API。 通过 Groq 提供的 `llama-3.3-70b-versatile` 无法在 MAF 的 HITL 上下文中稳定生成工具调用 JSON。MAF 的 HITL 机制设计是正确的；局限性在于模型本身。使用 MAF 原生的 HITL 需要一个具备稳定工具调用支持的模型，例如 Claude。 ## 📄 许可证 [MIT License](./LICENSE) © 2026 hidemi-k

标签：DNS 反向解析, Go, IP 地址批量处理, Ruby工具, Rust, Sysdig, 人工智能, 可视化界面, 日志审计, 用户模式Hook绕过, 网络安全, 网络流量审计, 自动化运维, 逆向工具, 隐私保护