从今年上半年开始我把自己那台工作站当成了一台“本地 AI 试验台”Ollama、Dify、DeepSeek 蒸馏模型、MinimaxH3、还有几个 Agent 编排框架全塞了进去。服务多起来之后一个现实问题摆在面前我根本说不清到底哪些端口在监听、哪些接口没有鉴权、哪些技能入口可以被任何人调用。于是我把平时用来做安全巡检的一个小工具改造成了 AI 专项版也就是 AI-Infra-Guard。它可以用 Docker 一键拉起对本地和远程的 AI 服务做资产识别和技能扫描帮助我盘点模型 API、MCP 工具入口、Agent 插件注册表这些容易被忽略的暴露面。这篇文章我会从部署开始讲把一次真实的使用过程摊开最后复盘一次让我印象很深的“漏报”案例。1. 整体设计思路为什么 AI 基础设施需要单独做一个扫描器1.1 传统扫描器在 AI 场景下不够用你可能会有疑问Nmap 扫端口、Nuclei 打漏洞还不够吗我的回答是不够。AI 基础设施和传统 Web 应用有个很大的差异——它提供的不只是“页面”和“API”还有模型推理接口、MCP 工具声明、Agent 技能注册表、插件描述文件、向量数据库控制台。Nmap 能探测到某个端口开了 TCP但它不知道这个端口是ollama serve还是dify api更不知道这两个服务暴露出来的调用面分别有什么风险。比如一次扫描中Nmap 告诉我 11434 端口开着我只能确认这是个 HTTP 服务。而 AI-Infra-Guard 会向/api/tags发一个 GET 请求看到返回里带着一堆模型名再检查响应头里有没有鉴权字段然后直接给出结论Ollama 模型仓库未授权访问任何人在局域网内都能拉取模型列表、删除模型、加载自定义模型。这就是“技能扫描”和传统端口扫描的差别。AI-Infra-Guard 的核心思路很简单把“AI 服务协议”内置成一套指纹库然后逐个端点去做轻量级探测。它不追求发现所有 CVE它只回答三个问题这里有什么 AI 相关资产、哪些能力入口是开放的、这些入口有没有做身份校验和访问控制。1.2 技能扫描到底在扫哪些暴露面“技能”这个词在 AI Agent 生态里通常指模型能够调用的工具或能力。技能扫描在 AI-Infra-Guard 里具体对应四类目标第一类是模型推理 API包括 OpenAI 兼容的/v1/chat/completions、/v1/models以及非标准实现里的/generate、/api/chat等路径。这类接口如果开放且没有鉴权意味着任何拿到地址的人都可以白嫖算力、调用模型甚至通过恶意 prompt 尝试越权访问服务端资源。第二类是 MCP Server这是当前 Agent 互操作最火的标准之一像 mcp-neo4j-cypher 这类服务通过 MCP 协议暴露数据库查询能力。如果 MCP 入口不校验来源攻击者可以构造 JSON-RPC 请求逐个调用list_tools、call_tool把 Cypher 查询变成对图数据库的完整控制。第三类是 Agent 技能注册表比如.well-known/ai-plugin.json、/skills、/functions。这类端点通常不会直接产生危害但它们会泄露技能清单、工具描述、可能存在的内部 API 路径。信息泄露在 AI 基础设施场景里往往是第一步。第四类是配套服务向量数据库控制台、模型推理网关、Dify 这类低代码 Agent 平台的管理端。它们不是技能端点但一旦被拿到权限攻击者可以替换知识库、篡改 Agent 的规划逻辑后果比普通 Web 漏洞更隐蔽。1.3 为什么一定要 Docker 一键部署如果你维护过多个本地 AI 服务应该能体会那种“依赖地狱”。Python 版本、CUDA 版本、Node 运行时每个服务都有自己的要求。AI-Infra-Guard 自身的依赖倒不复杂但我刻意把它做成 Docker 镜像分发原因有两点。第一是规则库可以热更新。扫描器本体是稳定的但 AI 框架迭代太快今天 Ollama 加了个新端点明天某个 Agent 框架发布了新的协议路径。把规则库挂载到容器里改完 YAML 刷新页面就能生效不需要重新构建镜像。第二是可移植性。我的真实环境是 Windows 上用 Docker Desktop生产环境是 Ubuntu 服务器未来可能还要跑到 ARM 开发板上。只要 Docker Engine 能跑扫描器就能跑。这也是我强烈建议你把 AI-Infra-Guard 部署在 Docker 里的原因它不是被设计成“装在本机上扫描自己”而是作为独立组件与目标 AI 服务保持网络隔离避免扫描动作本身影响运行中的模型服务。2. 部署实战Docker 一键起来2.1 环境准备与 Docker 安装避坑我用 Docker Desktop 的时间比较早但每次在新机器上装它都会碰到同一个祖传报错Virtualization support not detected Docker Desktop failed to start because Virtualization support was not detected.解决办法很简单BIOS 里打开 Intel VT-x 或者 AMD-V然后在 Windows 功能里启用“虚拟机平台”和“适用于 Linux 的 Windows 子系统”。改完重启Docker Desktop 通常就能正常启动。还有一个更容易让人挠头的报错Failed to connect to the Docker API at npipe:////./pipe/dockerDesktopLinuxEngine如果你是在 Windows 上通过 PowerShell 执行docker version时看到这个多半是 Docker Desktop 还没有完全切到 WSL2 后端。打开 Docker Desktop 设置把默认后端换成 WSL2等右下角图标变绿再重新运行命令。实在不行重启 Docker Desktop 服务。如果你在 Linux 服务器上部署直接用官方脚本装 Docker Engine 就可以curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh sudo systemctl enable --now docker sudo usermod -aG docker $USER装完验证一下docker run --rm hello-world能打印出 Hello from Docker! 说明环境没问题。2.2 编写 compose 文件并启动 AI-Infra-GuardAI-Infra-Guard 的部署非常轻量只有一个 Web 服务容器外加挂载三个目录规则库、报告目录、目标配置文件。我用的是 Docker Compose 管理文件长这样version: 3.8 services: ai-infra-guard: image: registry.example.cn/ai-infra-guard:0.2.0 container_name: ai-infra-guard ports: - 8899:80 volumes: - ./rules:/app/rules - ./reports:/app/reports - ./targets.yaml:/app/targets.yaml environment: - TZAsia/Shanghai - SCAN_INTERVAL3600 extra_hosts: - host.docker.internal:host-gateway restart: unless-stopped注意extra_hosts这一行。扫描器跑在容器里它要访问的是宿主机网络里的 AI 服务比如宿主机的 11434 端口、宿主机的 Dify 容器端口。通过host.docker.internal:host-gateway容器内部可以用host.docker.internal这个域名指向宿主机这样在 targets.yaml 里写地址时就不用猜宿主机的局域网 IP 了。启动命令只有一个docker compose up -d启动后访问http://localhost:8899你应该能看到 Web 控制台。第一次看到界面时扫描任务列表是空的因为还没有配置目标。2.3 配置 targets.yaml告诉扫描器该扫什么AI-Infra-Guard 支持两种资产发现模式。第一种是“显式目标清单”适合扫描已知服务第二种是“Docker Socket 自动发现”扫描器会尝试读取宿主机的 Docker API自动列出所有运行中的容器、端口映射、网络模式。第二种模式很强大但需要把/var/run/docker.sock挂载进容器。考虑到某些人会对挂载 Docker Socket 有安全顾虑我保留了显式清单作为默认方式。我的targets.yaml配置大概是这样的targets: - name: local-ollama address: http://host.docker.internal:11434 type: ollama skills_enabled: true - name: local-dify address: http://host.docker.internal:3000 type: dify skills_enabled: true - name: minimax-h3-web address: http://host.docker.internal:9527 type: minimax_h3 skills_enabled: true - name: neo4j-cypher-mcp address: http://host.docker.internal:8081 type: mcp protocol: json-rpc这里每个目标都有明确的type字段扫描器会按对应类型的指纹库去探测而不是把所有目标当普通 Web 服务处理。skills_enabled控制是否对这个目标执行技能扫描也就是主动去拉取模型列表、技能声明文件、MCP 工具列表等资源。配置好之后点“立即扫描”能看到扫描器按目标逐个发起探测先确认端口可达再做 HTTP 协议识别接着拉取关键路径最后把结果写入报告。3. 技能扫描实操把本地 AI 服务完整盘一遍3.1 搭建一个真实测试环境为了让整个流程更接近实战我在同一台工作机上用 Docker 又拉起了一批模拟目标的等等我把上节的 targets.yaml 里写到的服务实际部署了出来。比较快的一条命令是 Ollama 加 DeepSeek 蒸馏模型docker run -d --name ollama --gpus all -p 11434:11434 ollama/ollama docker exec ollama ollama pull deepseek-r1:7bDify 的部署稍微麻烦一点它自带一套 compose 文件。我从官方仓库拉下来后启动默认会把 API 服务映射到宿主机 3000 端口、Web 端映射到 3001 端口。MinimaxH3 我用了本地推理镜像启动时暴露了 9527 端口WebUI 和模型服务混在一起。这个端口比较特殊后面会提到它和漏报复盘的关系。我还起了 Redis 主从的实验环境services: redis-master: image: redis:7 ports: - 6379:6379 redis-slave: image: redis:7 ports: - 127.0.0.1:16379:6379 command: redis-server --slaveof redis-master 6379以及一个 mcp-neo4j-cypher 的 MCP 服务容器端口映射到 8081。这套环境跑起来之后宿主机上至少同时有 4 类 AI 服务在监听。3.2 跑一次完整扫描看结果在 AI-Infra-Guard 里点击“立即扫描”整个任务完成时间大约 40 秒。扫描结果按风险等级排列我拿到了一份比较典型的报告目标发现项风险等级说明Ollama 11434/api/tags未授权访问高任意用户可列出全部模型并加载新模型Ollama 11434/v1/chat/completions无鉴权高可绕过鉴权直接调用 DeepSeek 模型Dify 3000/api/v1/workspaces可枚举中工作区信息、应用名称存在泄露风险mcp-neo4j-cypher 8081MCPlist_tools可访问高无需握手即可枚举工具列表存在 Cypher 注入面Redis master 6379无密码访问高主实例直接暴露在消费网络可读写键值数据Redis slave 16379无密码访问仅本机低端口绑定在 127.0.0.1暴露面有限当时看到这份报告我第一反应是“还好提前扫了一遍”。Ollama 和 Redis 的未授权访问是最典型的问题很多本地部署教程会让你直接-p 11434:11434却没有提醒你加上--requirepass或者绑定127.0.0.1。MCP 服务的风险更隐蔽因为大家总觉得它是“内部调用”可它在网络层就是一个普通 HTTP/JSON-RPC 端口。3.3 规则是怎么写的一个 YAML 规则实例AI-Infra-Guard 之所以能识别这些 AI 特定风险核心在规则库。每条规则的本质是一个“当路径返回特定内容且没有鉴权时判定为风险”的逻辑。拿 Ollama 未授权访问来举个具体例子规则文件长这样id: SKILL-OLLAMA-001 name: Ollama 模型仓库未授权访问 enabled: true target_types: - ollama - openai-compatible match: - path: /api/tags methods: - GET - path: /v1/models methods: - GET conditions: response_code: in: [200] auth_required: false severity: high description: Ollama 默认未开启鉴权任何网络可达用户可查看、拉取和加载模型。 fix: 在 API 网关层增加 Bearer Token或将 Ollama 监听地址改为 127.0.0.1。 tags: - ai-infra - ollama规则里target_types决定了它只对 Ollama 或 OpenAI 兼容服务生效避免对普通网站误报。auth_required: false这个条件最核心扫描器发送请求如果返回 200 且响应里没有401、403或Authorization: Bearer相关标志就判定为未授权访问。如果你将来想扫描新的 AI 框架只需要照着这个模板加一条 YAML 规则然后刷新规则库即可。这也是我说 AI-Infra-Guard 适合本地 AI 研究者使用的原因——它不怕你遇到新东西它怕的是你没有把新东西登记成规则。3.4 常见修复动作扫描出结果之后修复动作也很有讲究。最粗暴的做法是把所有端口都改成127.0.0.1:端口但这样会破坏很多实际的使用场景比如你确实需要在局域网内从手机访问 Dify 的对话页面。我的建议是分三层处理第一层对模型推理接口设置网关认证。不管是 Ollama 还是 vLLM在服务前面挂一层 Nginx 或者 API 网关统一添加 Bearer Token 校验。第二层对数据类服务做网络隔离。Redis 主从、Postgres、向量数据库这些数据组件不要让它们直接暴露到宿主机的物理网段。用 Docker 自建网络把相关容器收进一个 internal 网络扫描器作为独立容器也只能从网关视角探测这样即使规则漏了也不会酿成大错。第三层对 MCP 这类 Agent 协议服务限制来源 IP 或增加 mutual TLS。MCP 的 JSON-RPC 天然支持鉴权头只不过很多部署教程没提。在 mcp-neo4j-cypher 前面加一层简单代理只允许本地回环地址调用就足以挡住绝大多数误用。4. 那次“漏报”复盘问题排查实录4.1 漏报是怎么发生的扫描报告出来之后我松了一口气开始正常使用这些 AI 服务。差不多过了一周一个偶然场景让我重新审视这次扫描。当时我在外部网络环境测试一个 API 代理随手输入了家里公网 IP 的某个端口结果打开的是一个 one-api 的登录页面——也就是我本地部署的模型网关。但我清楚记得AI-Infra-Guard 这次扫描结果里根本没有 one-api 的条目。问题出在哪里我回到控制台翻看目标清单发现 one-api 并没有出现在 targets.yaml 里。再一查配置原来是我为了模拟某些容器使用 host 网络模式把 one-api 容器设置成了network_mode: host它直接监听了宿主机的 3210 端口。因为 targets.yaml 里只写了 Ollama 的 11434、Dify 的 3000 这些“传统知名端口”根本没有覆盖 3210所以扫描器从头到尾都不知道这个服务存在。4.2 漏报的三层原因这个漏报让我很受触动因为它的成因不是单一 bug而是三个因素叠加。第一是规则库覆盖不足。AI-Infra-Guard 默认从常见端口列表开始探测但 AI 生态里有大量非标准端口。MinimaxH3 的 9527、one-api 的 3210、各种 Agent 编排框架的动态端口都不会出现在任何“常见端口表”里。第二是目标资产清单僵化。手动维护 targets.yaml 的模式天生就漏掉“后来新增的容器”。你部署了一个新服务却忘了把它加进扫描清单那扫描器再强也看不到它。第三是 host 网络模式带来的资产模糊性。当容器使用network_mode: host时它不再有独立的 Docker 端口映射记录扫描器如果只依赖 Docker 端口映射来发现资产就会完全丢失这类目标。4.3 复盘后的针对性改进我整改了三个地方这里逐一说明。首先是规则库。我给 AI-Infra-Guard 新增了一批“AI 配套服务”规则覆盖 one-api 的/login、/api/user路径MinimaxH3 的 WebUI 路径以及各类 Agent 网关的管理端口。规则本身不复杂关键是意识到这些服务也应该出现在扫描视野里。其次是扫描范围。我增加了“全端口兜底扫描”模式。这个模式不会一上来就对全端口爆破而是先用 TCP Connect 扫遍历 1-65535 范围内的开放端口再对每个端口做协议指纹识别。扫描时间变长了但准确率好很多。实测在宿主机上全端口扫描一次大约需要 6 分多钟对比原来 40 秒就能完成的任务这个代价可以接受。最后是资产发现自动化。我放弃“手动维护 targets.yaml”的执念改用 Docker Socket 自动发现模式。AI-Infra-Guard 通过挂载/var/run/docker.sock每分钟读取一次本机容器状态新容器一旦启动且映射了端口就自动触发一轮针对性扫描。4.4 踩坑问题速查表症状可能原因解决办法Docker Desktop 提示 virtualization support 缺失BIOS 没开虚拟化重启进 BIOS 开启 Intel VT-x/AMD-Vnpipe:////./pipe/dockerDesktopLinuxEngine连不上Docker Desktop 后端未切到 WSL2设置中切换 WSL2 后端并重启扫描器能访问宿主机端口但扫不到容器targets.yaml 缺失该目标显式配置目标或开启 Docker Socket 自动发现规则始终不命中规则库未挂载到最新目录确认 /app/rules 挂载路径刷新规则端口开放但识别为 unknown默认指纹库没有该服务类型自定义 YAML 规则指定/或/health路径指纹host 网络模式容器不被发现资产发现只依赖端口映射启用手工全端口扫描 协议指纹识别这个表格是我在实际操作中反复撞出来的经验总结每次部署新环境都会先对照检查一遍。4.5 漏报复盘给我的两点提醒这次漏报让我重新看待“扫描通过”这个结论。扫描通过只代表“在给定的规则库和资产清单范围内没有发现已知风险”它不等于“绝对安全”。AI 基础设施的暴露面是动态的新容器、新端口、新协议随时可能出现。第一点扫描器的作用是加速度计不是安全保险箱。它最大的价值不是替你找出所有问题而是让你在有变动时立刻知道哪里要重新检查。第二点资产台账必须和扫描器联动。如果不知道资产在哪里再多的规则都白搭。这也是我后来坚持使用 Docker Socket 自动发现的原因——它让扫描范围和实际运行环境始终对齐不再依赖人肉维护清单。5. 写在最后的小技巧今天主要分享的是 AI-Infra-Guard 的部署流程、技能扫描原理以及一次让我印象深刻的漏报复盘。如果你想从这次复盘里直接拿走一点能用的东西我可以送你一个自己现在每台机器上都会配置的小脚本思路在 Docker Compose 启动新服务后自动调用 AI-Infra-Guard 的 API 触发一次本轮扫描并把结果通过 Webhook 推到钉钉或者飞书群里。这个脚本只有几十行但它把“部署新服务”和“立即扫描暴露面”绑在了一起。我现在每部署一个 AI 服务扫报告几乎同时就能出现在手机通知里。从那以后类似 one-api 漏报这种事儿再也没发生过。如果你也在本地折腾 Ollama、Dify、MCP 这一套 AI 基础设施真心建议你尽早把这层扫描机制补上别等到外部访问出现了再回头排查。